Hi,
> I think the best way to make them work is to keep the individual
> payload length less than 64k, but QSKE (or whatever the new payload is
> called) so that it can provide separate pieces of actual KE payload.
That's exactly what I suggested in
https://mailarchive.ietf.org/arch/msg/ipsec/ja
Garcia-Morchon O, Oscar writes:
> From this point, I think that if the requirements (>64k) of those
> schemes need to be taken into account, then those should be taken
> into account now.
I think the best way to make them work is to keep the individual
payload length less than 64k, but QSKE (or wh
March 25, 2018 7:36 PM
To: IPsecme WG (ipsec@ietf.org)
Subject: [IPsec] Clarification on my comments during the WG about possible KE
payloads > 64k
During the WG meeting in London, somebody (I forget who) asked me whether KE
payloads larger than 64k. I thought I ought to clarify matters (as th
Hi Yoav,
just for clarification:
That was me. When they started talking about about PQC a decade ago, they
mentioned algorithms like McEliece with public keys around 1MB.
Not that this is a deal-killer. If necessary, we would come up with an IKE
extension to have “jumbo-sized payloa
Hi, Scott.
That was me. When they started talking about about PQC a decade ago, they
mentioned algorithms like McEliece with public keys around 1MB.
Not that this is a deal-killer. If necessary, we would come up with an IKE
extension to have “jumbo-sized payloads” that had 24-bit lengths. IKE o
During the WG meeting in London, somebody (I forget who) asked me whether KE
payloads larger than 64k. I thought I ought to clarify matters (as they are
more complex than the brief answer I gave indicated).
Of the proposed postquantum key exchange (and public key encryption algorithms,
which c
