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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
