I support those choices, but would also add P256+Kyber512.
* (1) same reason as below (by Scott)
* (2) to be able to declare security of generated keys in FIPS-mode for
_both_ - classical and post-quantum schemes (once Kyber is standardized).
After double-checking with NIST today, currently
On 22/08/2022 14:24, Bas Westerbaan wrote:
Here they're speaking about adding non-FIPS PQ to a non-PQ FIPS kex,[2] but
the other way around is also ok — what am I missing?
Let's assume Kyber is FIPS-approved. Indeed, you'll be able to have
a FIPS library with Z generated by Kyber and T generat
On 23/08/2022 01:39, Martin Thomson wrote:
On Tue, Aug 23, 2022, at 00:11, Kris Kwiatkowski wrote:
As X25519 is not FIPS-approved, the lab won't be able to test it,
OK, hypothetical question, but maybe an important one.
Why would a certification lab care? We compose secrets with non-se
Hello,
The codepoint for P-256+Kyber768 has been just assigned by IANA. The value is
0x639A.
Thanks Rich for pointing to the request form.
Kind regards,
Kris
On 18/05/2023 22:00, Christopher Wood wrote:
Thanks, Rich!
On May 17, 2023, at 3:44 PM, Salz, Rich wrote:
* Can we get anothe
However, the difference is stated to be UncompressedPointRepresentation
for P256 from TLS 1.3. AFACIT, that is 65 bytes (1 legacy_form byte,
32 bytes for x, 32 bytes for y).
Right, one byte for the legacy_form is missing. Let me fix it.___
TLS mailing
So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186 does
not impact the curves permitted under SP 800-56Arev3. Curves that are included
in SP 800-186 but not included in SP 800-56Arev3 are not approved for key
agreement. E.g., the ECDH X25519 and X448 key agreement schemes
cryptosystem, introduced already in 2010.
* There is a cost of 2-step migration (to hybrid and then pure PQ), I don’t
believe it’s good to force you to pay the cost.
Additionally, I think I would also get a codepoint for MLKEM-512.
--
Kris Kwiatkowski
Cryptography Dev
Hi Andrei,
We’re working on a codepoint for P256+MLEKM.
--
Kris Kwiatkowski
Cryptography Dev
> On 13 Aug 2024, at 16:37, Andrei Popov
> wrote:
>
> I think it would make sense to get new code points for hybrids based on the
> final ML-KEM spec, so that implementers don’t
Sweet!
Does this migration includes also cloudflare->origin (egress) connections or
just eyeballs->cloudflare?
Cheers,
Kris
On 06/09/2024 12:02, Bas Westerbaan wrote:
Hi all,
We are planning to replace X25519Kyber768Draft00 (0x6399)
with X25519MLKEM768 (0x11ec) [1], a hybrid of ML-KEM-768 a
+1. No need for x448.
On 09/09/2024 14:29, Filippo Valsorda wrote:
If P-386+ML-KEM-1024 is there for CNSA compliance, I see no need to provide
an Edwards counterpart to it: there is no Edwards National Security
Algorithm Suite. Also, isn't X448 TLS deployment nearly non-existent?
2024-09-09 1
> On 10 Sep 2024, at 00:17, Andrei Popov wrote:
>
> This makes sense, however shouldn’t draft-kwiatkowski-tls-ecdhe-mlkem-01 be
> on the Standards track?
> Also, what is the thinking behind “Recommended: N” for the code points?
The draft-ietf-tls-hybrid-design draft is on the Informational tra
> On 10 Sep 2024, at 16:05, Salz, Rich wrote:
>
> • I assume draft-ietf-tls-hybrid-design will remove all mentioning of
> Kyber and only refer to the final standardized ML-KEM. I don't think TLS WG
> should publish anything with Kyber.
> In fact, the current unified draft has IANA instruc
Hello,
All changes regarding error handling and input validation merged.
Thank you for your contribution.
--
Kris Kwiatkowski
Cryptography Dev
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
-56Cr2, so that it allows to
> use combination of two shared secrets where one was generated by FIPS-approved
> technique, BUT concatenated in any order.
On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski wrote:
Indeed, that would be good inside.
Additionally, is there a plan to change
Yes, we switched the order. We want MLKEM before X25519, as that presumably
can be FIPS-certified.
According to
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf,
section 2,
the shared secret from the FIPS-approved algorithm must precede the one that
is not approved. X
certified SecP2561r1 crypto backend and not yet certified MLKEM?
This is precisely the problem we want to address with P-256.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
n Thu, 17 Oct 2024 at 08:58, Kris Kwiatkowski wrote:
Yes, we switched the order. We want MLKEM before X25519, as that
presumably can be FIPS-certified.
According to
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf,
section 2,
to register Secp384r1MLKEM1024, but I believe this
should only be done once we reach a consensus regarding
point 2.
Thank you!
--
Kris Kwiatkowski
Cryptography Dev
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
I support the adoption. I also think we will end up standardizing pure ML-DSA
anyway.
Modify the TLS protocol to rely on multiple certificates (one of which might
be a traditional RSA certificate and one an ML-KEM only certificate)?
+1. Composite signatures are also interesting, but since TLS a
Sure, but for the record the same applies to SecP3841MLKEM1024
I think the main motivation for ECDH/P-384 is CNSA compliance, so I don't
think it is "the same applies". Yes,
it is slower than x25519 or ECDH/p256.___
TLS mailing list -- tls@ietf.org
To
On 06/01/2025 06:18, Viktor Dukhovni wrote:
it would be very unlikey to get
used.
The addition of that codepoint was previously discussed on this mailing list,
and as Victor says,
it is unlikely to be used.___
TLS mailing list -- tls@ietf.org
To unsub
Hello,
1. **Alignment of NamedGroup X25519MLKEM768** with the order of shared
secrets, as per Section 3.2 of draft-ietf-tls-hybrid-design.
- I suggest updating the name to mlkem768_x25519, while keeping the
codepoint unchanged (if that is acceptable). If
this change is made, I also re
I also think it would be good to adopt MLKEM drafts (hybrid and pure).
No opinion on drafts for signature schemes.
On 16/12/2024 23:13, Russ Housley wrote:
+1. There are people that want to implement both hybrid and pure key exchange.
This action would allow a path to RECOMMENDED = Y for both
I would like to see adoption of all four documents
andhttps://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/ which was left
out. I assume the latter was merely an oversight.
Yes, it was an oversight on my part.
I support adoption of draft-tls-westerbaan-mldsa._
Hello,
The code point for SecP384r1MLKEM1024 has been registered.
Please see
https://www.iana.org/assignments/tls-parameters
Happy New Year,
Kris
On December 11, 2024 2:38:59 PM GMT+01:00, Bas Westerbaan
wrote:
>Following the feedback from the last TLS meeting at IETF@121, I have
Perfect!
Thank you Sean!
On 26/02/2025 14:59, Bas Westerbaan wrote:
Thank you Sean!
On Wed, Feb 26, 2025 at 3:41 PM Sean Turner wrote:
Hi! Just in case you missed it [0], your draft is up first in the PQ
wg-call-for-adoption-o-rama. I should have the message out later today.
spt
Thanks.
Sounds real good.
On 07/03/2025 10:22, Tim Hudson wrote:
On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski wrote:
May I know if you have a plan for FIPS certificaton for PQC after release?
Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation
in April once
Indeed, that's very nice. I'm actually running OpenSSL built from a branch
vduc/hybrids on my server
and X25519MLKEM768 seems to work alright.
May I know if you have a plan for FIPS certificaton for PQC after release?
Cheers,
Kris
On 07/03/2025 04:02, Viktor Dukhovni wrote:
On Thu, Mar 06, 20
Yes, it should be the case once SP800-56C is updated (which is a plan). See
this message:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0/m/hFlrkW1CCgAJ
On 27/02/2025 19:05, Salz, Rich wrote:
I thought that I remember (sic) that NIST said that hybrid key exchange,
where on
t; https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/issues/34
> Cheers,
> John
> On 2024-12-25, 07:08, "internet-dra...@ietf.org"
> wrote:
> Internet-Draft draft-kwiatkowski-tls-ecdhe-mlkem-03.txt is now available.
> Title: Post-quantum h
Perfect!
Thanks Sean. We will come back to chairs shortly.
- Kris
On March 20, 2025 5:01:31 PM GMT+07:00, Sean Turner wrote:
>Hi! It looks like we have consensus to adopt this draft as a working group
>item. Couple of things to note:
>
>1. Authors, please submit the draft named as: draft-ietf-
I support adoption.
Cheers,
Kris
> On 1 Apr 2025, at 16:53, Yaroslav Rosomakho
> wrote:
>
> I strongly support adoption of this document.
>
> Best Regards,
> Yaroslav
>
> On Tue, Apr 1, 2025 at 2:00 PM Sean Turner wrote:
> We are continuing with our pre-announced tranche of WG adoption c
32 matches
Mail list logo
