Re: [IPsec] New Version Notification for draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt

[Vukasin Karadzic <[e-mail]>]

Hello all,

I'd like to add a couple of remarks.

1. There is one more code-based proposal based on Goppa codes and somewhat
on McEliece and that is NTS-KEM, I would suppose one of those two will be
one of the final standardized algorithms. NTS-KEM has three sets of
parameters, one for each of the security 'levels' that NIST proposed, and
the first and second set of parameters (for Level 1 and Level 3 security)
have significantly smaller keys (though they are still one of the biggest).
There is even a document published by Classic McEliece team that compares
all important aspects of the proposal (
https://classic.mceliece.org/nist/vsntskem-20180629.pdf) (there is also a
response from NTS-KEM team addressing all points from that document).

2. All NIST proposals are K(ey)E(ncapsulation)M(echanism)s. I don't know if
it's possible or if it makes sense,
but in some use cases (eg. small client - server) it may be useful for a
server to store public key from client, so that client doesn't need to each
time (eg. for a rekey) calculate a new public key (and send it?), because
key generation can be expensive, in case of Classic McEliece key generation
in software takes billions (4-6) of cycles, about 2 seconds in
~6,000,000,000 case on a 'Intel Xeon E3-1220 v3 (Haswell) running at
3.10GHz with 32GB of RAM' platform. Maybe that point can be also addressed
in the draft.
One more remark regarding KEMs, in case of Classic McEliece/NTS-KEM, the
initiator would send MBs (eg, 1357824 bytes) of KE payload, while in the
other direction the responder would need to send only couple of hundred of
bytes (240 bytes) which contain encapsulated secret key.

Regards,
Vukasin Karadzic