On Sun, Dec 15, 2024 at 11:47 PM John Mattsson wrote:
> Angela Robinson from NIST recently summarized the situation as.
> "The key-derivation methods described in NIST SP 800-56C are currently
> only applicable to shared secrets established during a key establishment
> scheme as specified in NIST
I would like to see adoption of all four documents and
https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/ which was left
out. I assume the latter was merely an oversight.
I think draft-reddy-tls-composite-mldsa (or more
precisely draft-ietf-lamps-pq-composite-sigs) needs a lot of work. I
>
> (C) within the PQ part, providing alternatives that are less likely
> to fail in the first place.`
>
I think there is some more to say about what would make a good alternative
KEM.
Let's consider Saber. There are differences between ML-KEM and Saber. A
simple implementation of Sab
> I think that if we pursue an alternative structured lattice KEM, it should
> bring at least another advantage to the table. From a performance
> perspective BAT ( https://eprint.iacr.org/2022/031 ) improves
> considerably over ML-KEM in certain use cases: its ciphertexts and public
> keys are sma
I prefer 2.
On Thu, Dec 12, 2024 at 6:37 PM Joseph Salowey wrote:
> Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of ephemeral
> keys. This was the consensus of the working group during the development
> of TLS 1.3. There has been more recent discussion on the list to forbid
> re
y show that the web metric suffers much
> less than the handshake mainly because web pages usually spend more time on
> doing other things like downloading and rendering large sums of data like
> html, css, javascript, images, json etc than on TLS handshakes.
>
>
>
>
>
>
>
Do the chairs have an update to share on this thread?
I'm asking explicitly as your recent message [1] could be interpreted as
one.
Best,
Bas
[1] https://mailarchive.ietf.org/arch/msg/tls/yufDcbR8yXQUuAtldXLWTax5z8c/
On Mon, Dec 16, 2024 at 11:01 PM Sean Turner wrote:
> Note that there ar
I support prohibiting key reuse, and a quick search shows several threads
where this has been discussed before.
But concerning the issue at hand, I would love to hear about the
application where amortization is worthwhile.
It puzzles me that this is worthwhile. The thing is that ML-KEM keygen is
On Wed, Apr 16, 2025 at 10:15 AM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > That’s easy to answer: “many of our members have very
> hardware-constrained PoS devices.” Is that okay?
>
> Some context:
>
> Kyber requires several KB of RAM space according to [1], figure 1:
>
On Tue, Apr 15, 2025 at 9:06 PM Bas Westerbaan wrote:
> This working group has wisely focussed its efforts on post-quantum key
> agreements for the last five years. It's basically done. I have no doubt
> that if any unforeseen issues might arise in the final stretch, we'll ris
On Wed, Apr 16, 2025 at 10:38 AM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> > This is misleading. There are many implementations of Kyber that
> require
> > much less memory. See eg [1] from 2019 where Kyber-512 only requires
> 2736
> > bytes.
>
> Thank you. Somehow I misse
This working group has wisely focussed its efforts on post-quantum key
agreements for the last five years. It's basically done. I have no doubt
that if any unforeseen issues might arise in the final stretch, we'll rise
to the occasion.
I suppose adoption of the draft.
Best,
Bas
On Tue, Apr 15,
For everyone's convenience:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/RsQbm_AQfzs/m/19o76lsyCwAJ
On Tue, Apr 15, 2025 at 11:55 AM D. J. Bernstein wrote:
> A message has just appeared on pqc-forum claiming yet another attack
> improvement against lattices---improving what are calle
This is indeed fantastic—congratulations!
Will X25519MLKEM768 be enabled by default?
On Thu, Mar 6, 2025 at 2:32 PM John Mattsson wrote:
> Great that X25519MLKEM768 and MLKEM1024 will be in the 3.5 LTS release
> https://openssl-library.org/post/2025-02-04-release-announcement-3.5/
>
> Also grea
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
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav
Hi Ryan,
Thanks for the review.
On Fri, May 23, 2025 at 11:46 PM Appel, Ryan wrote:
> Hello all,
>
>
>
> Apologies if there’s any emails that have already gone out for these
> editorial items or if you all already had plans to fix them. I was going
> through the draft today and didn’t see any o
I'd prefer marking non-PQ kexes as "D"; marking X25519MLKEM768 as "Y" and
leaving pure ML-KEM as "N".
On Fri, Jun 6, 2025 at 12:16 PM Bellebaum, Thomas <
thomas.belleb...@aisec.fraunhofer.de> wrote:
> Hello together,
>
> I have just opened a pull request related to the hybrid vs. non-hybrid
> dis
Presently all post-quantum *key agreements* registered for TLS are
(essentially) ML-KEM. If ML-KEM is broken, then a TLS connection even using
SLH-DSA can be decrypted passively and can also be actively MitMed. From a
security standpoint, I see little value in using SLH-DSA over (hybrid)
ML-DSA unl
On Wed, Jul 16, 2025 at 11:15 PM D. J. Bernstein wrote:
> Bas Westerbaan writes:
> > From a security standpoint, I see little value in using SLH-DSA over
> > (hybrid) ML-DSA unless you also use a different key agreement.
>
> Sorry, can you please clarify the rationale here?
Sidestepping hybrid standardisation is an advantage, but I'm not yet ready
to admit failure there.
On Sun, Jul 27, 2025 at 12:08 PM John Mattsson wrote:
> I would like to use SLH-DSA for CertificateVerify in use cases where the
> performance of SLH-DSA is acceptable. There are simple no other so
Hi TLS,
At 123 we sent the updated version of Merkle Tree Certificates (aka
photosynthesis) to offset large post-quantum signatures in the WebPKI to
DISPATCH [1]. The result is the PLANTS (PKI, Logs, And Tree Signatures)
list pla...@ietf.org. Scope and draft charter are the first step, which
we're
101 - 121 of 121 matches
Mail list logo
