Hi everyone,
Quoting Tobias Guggemos <gugge...@nm.ifi.lmu.de>:
> #4 Big Keys (e.G. Classic McEliece)
> In general there was consensus that we should find a way to
enable the use of McEliece keys.
> 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.
Nothing to be corrected here. I'd like to stress that some parties
who participated in the discussion yesterday or in personal
conversations have told about the demand for using a rather secure
version even if it means more work on extending the protocol. Though
there's a few quantum-resistant algorithms that I personally like
still McEliece is the one cryptographers are most confident to be secure.
There's several use cases relevant to companies and agencies where
using McEliece (even this in combination with other algorithms) is the
way to go and therefore this should definitely be considered for IKEv2.
Kind Regards,
Stefan Gazdag
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
