Hi,
I think IKEv2 should register code points for FrodoKEM and BIKE/HQC (depending
on which one NIST standardizes). I think it is important with backups to
ML-KEM. The importance of cryptographic agility has been emphasized by several
US agencies. A necessity for cryptographic agility is to hav
On Wed, Jan 22, 2025 at 5:07 AM John Mattsson
wrote:
>
> Hi,
>
>
>
> I think IKEv2 should register code points for FrodoKEM and BIKE/HQC
> (depending on which one NIST standardizes). I think it is important with
> backups to ML-KEM. The importance of cryptographic agility has been
> emphasized
Thanks. I can also see that Classic Mceliece was also deemed as "acceptable".
Projects using it include Rosenpass, MullvadVPN, and my understanding
is that Ericsson is also planning to adopt it ?
Simon started working on an I-D for Classic MCeliece.
On Wed, 22 Jan 2025 at 23:37, Michael Osborne
On Wed, 22 Jan 2025 at 17:05, John Mattsson
wrote:
>
> Hi,
>
>
>
> I think IKEv2 should register code points for FrodoKEM and BIKE/HQC
> (depending on which one NIST standardizes). I think it is important with
> backups to ML-KEM. The importance of cryptographic agility has been
> emphasized by
Hi John
You want to check this statement " Many European governments are planning to
use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral
key exchange"
The Netherlands have already updated guidance such that ML-KEM is recommended
and FrodoKEM is acceptable.
https://pu
Mahesh Jethanandani has entered the following ballot position for
charter-ietf-ipsecme-13-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document
There exist standards for FrodoKEM now, so you could point to those documents
(or does IANA insist they be IETF documents?)
On the other hand, it is far too early for BIKE or HQC. For one, we don't know
which NIST would select. And, even when they do, they may very well make
tweaks between no
Do we know which transform IDs will be used for the pre-standard PQCs
(FrodoKEM, BIKE, HQC)?
Thanks
Phil
On Wed, Jan 22, 2025 at 10:46 AM Watson Ladd wrote:
> On Wed, Jan 22, 2025 at 5:07 AM John Mattsson
> wrote:
> >
> > Hi,
> >
> >
> >
> > I think IKEv2 should register code points for FrodoK
Murray Kucherawy has entered the following ballot position for
charter-ietf-ipsecme-13-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
The document, a
>There exist standards for FrodoKEM now, so you could point to those documents
>(or does IANA insist they be IETF documents?)
I do not think IETF should normatively refer to paywalled ISO crypto standards,
they don’t even fulfill specification required. Paywalls significantly
discourage security
On Thu, 23 Jan 2025 at 10:11, John Mattsson
wrote:
>
> >There exist standards for FrodoKEM now, so you could point to those
> >documents (or does IANA insist they be IETF documents?)
> I do not think IETF should normatively refer to paywalled ISO crypto
> standards, they don’t even fulfill speci
Yes,
Classic McEliece has properties that makes it the best choice in many different
applications. Classic McEliece is the most conservative KEM and Classic
McEliece category 5 is the best option for protecting various other keys
(ML-KEM, ML-DSA, SLH-DSA, FN-DSA, LMS, XMSS, etc.) in transit and
ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their list
of recommended algorithms, which I very much welcome, but I have not seen any
indication that they would stop recommending FrodoKEM. My current understanding
is that many European governments are planning to use Frodo
13 matches
Mail list logo
