Re: sntrup761 key size

--B05AVef/ce8jT3+M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Note that there's a newer [email protected] 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.

--B05AVef/ce8jT3+M
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3QolqQXydru4e4ITsMANTjsOVFkFAmn4ZS8ACgkQsMANTjsO
VFlKSA/+NizqllhazbeL43J8TpzWFfP7sCiP8MC/K8noaL4xc7cDmYItqXoC6Thg
wVYplVyOYxO+OAs9q9HbS90b/DFOh9UiJZNZT1P/a2D6DehVol2/cTcEkn42f4iq
zDu9nguC2rRMjcVAi1dWGNwqv6Uvshn9HbbT1aUC/M6CJY+UulvLms9TtCzAJ4Eq
J8TbV8W9tXkC9+uAyC+QpaKqTRuz86k11ztXqY4I87bmn/XxswxRkXldyd1818nN
O+6mDHDB0wAZAVECFA2hVJRv/ZT08aMisgrzztGryAum1G0PJH0RAVf4KbzAJHuH
XiJ8dQuPPlgL++TOak8C0+qNYdaAO3umvVUm3n0mXfDUBkKhDXk2MJHnCezdjMRs
OYEsvmC9plmpUCUHNYqAy9lSKB/YkSdRHPuH0/vJZf0ljh6JbMXFatyv7i4UB2Ds
CKVVCtfc4EH8WSf3IyBVwKubI7Cs7/eQadPBkSAfaagIDlY+QofUAPKgk4vhwsZO
ktaVf0K5l/Up0/0qzJ9sb0HLRAHbOrakApuXqdLkWFaPdY50ouNd0v2ul6Pgb2+m
3EIzeHtobC4iJR2qCHrDZMJy4OApnR92i/jmGivFZSQsVQTl5kLsRUZvnsMaVOED
V/2K3bvvgBWy+qE9GtA80YqRM986Rk1toutnd0GX9J+tWur+pRY=
=BYCu
-----END PGP SIGNATURE-----

--B05AVef/ce8jT3+M--