Hi, > > > The problem is that McEliece keys are >1MB in size and thus can not > > > fit into the KE payload (which has a 16 bit size field). > > Exchanging such big keys would unnecessarily slow down IKEv2 to a crawl. > There are multiple candidates in the NIST PQ Project that offer pk+ct sizes > of a > few kilobytes. It is likely that some will be standardized. Classic McEliece > performance seems much slower than other candidates as well. > > Sorry I missed it, but why was it decided that supporting Classic McEliece > > is a > must? > > There is no decision made on this, at the end this is a question to be > discussed > and agreed on in the WG. > However, with McEliece being the proposal which is most trusted in the crypto > community, there will be people wanting to support it (let it be governmental > institutions with strict security requirements). > We had "consensus" on: > 1) that the draft should support the possibility to exchange McEliece keys > without "breaking" the protocol again. > 2) we all hope that we won't need it! =) > > Correct me if I'm wrong.
That was my impression too. In other words - make it possible to handle such extremely long keys in probably suboptimal way, but with minimal possible changes to the protocol. So that those who need them could use them, but no promises that protocol will optimized for them. Regards, Valery. > > Panos > > Cheers Tobias _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
