IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sntrup761 key size



Note that there's a newer ssh%ietf.org@localhost list for the active SSHM WG. I
wouldn't hazard a guess as to whether the old list or the new list has
more ssh implementors.

Simon Tatham writes:
> But in the SSH usage of NTRU Prime (and indeed all other PQ KEMs so
> far), there's no real need to use the prescribed byte encoding of secret
> keys in any case, since a key pair is generated, used for one exchange
> and discarded all within the same process, so you might as well just
> leave it in whatever internal data structure your implementation finds
> most useful. Encoding it to a byte string is for people who need to keep
> it long-term and maybe share it between multiple implementations.

On the other hand, if you stick to the specified encoding of secret
keys, then you can plug the software into the SUPERCOP test framework
to check against other implementations using that encoding. SUPERCOP's
tests go beyond typical tests and have a long history of catching bugs
that weren't caught by typical tests.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", provides a
modification right "unless explicitly disallowed in the notices
contained in a Contribution (in the form specified by the Legend
Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

Rationale: I'm fine with redistribution of copies of this document. The
issue is with modification, such as (1) IESG's May 2025 posting of an
IESG-mangled version of an appeal that I had filed and (2) IETF
management selling IETF mailing-list text to AI companies.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index