rfc9941xml2.original.xml   rfc9941.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
ensus="true" docName="draft-ietf-sshm-ntruprime-ssh-06" indexInclude="true" ipr=
"trust200902" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRe
fs="true" tocDepth="4" tocInclude="true" xml:lang="en">
<front>
<title abbrev="NTRUPrime+X25519 for SSH"> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
ensus="true" docName="draft-ietf-sshm-ntruprime-ssh-06" number="9941" indexInclu
de="true" ipr="trust200902" updates="" obsoletes="" sortRefs="true" submissionTy
pe="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
<!-- [rfced] FYI - We updated the abbreviated title as follows. The
abbreviated title appears in the center of the running header at the top
of each page in the PDF output.
Original:
NTRUPrime+X25519 for SSH
Updated:
NTRUPrime and X25519 for SSH
-->
<front>
<title abbrev="NTRUPrime and X25519 for SSH">
Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined
NTRU Prime sntrup761 and X25519 with SHA-512: NTRU Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512 sntrup761x25519-sha512
</title> </title>
<seriesInfo name="RFC" value="9941"/>
<author initials="M." surname="Friedl" fullname="Markus Friedl"> <author initials="M." surname="Friedl" fullname="Markus Friedl">
<organization>OpenSSH</organization> <organization>OpenSSH</organization>
<address> <address>
<email>markus@openbsd.org</email> <email>markus@openbsd.org</email>
</address> </address>
</author> </author>
<author initials="J." surname="Mojzis" fullname="Jan Mojzis"> <author initials="J." surname="Mojzis" fullname="Jan Mojzis">
<organization>TinySSH</organization> <organization>TinySSH</organization>
<address> <address>
skipping to change at line 32 skipping to change at line 51
</address> </address>
</author> </author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson"> <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<address> <address>
<email>simon@josefsson.org</email> <email>simon@josefsson.org</email>
<uri>https://blog.josefsson.org/</uri> <uri>https://blog.josefsson.org/</uri>
</address> </address>
</author> </author>
<date/> <date month="March" year="2026"/>
<workgroup>Internet Engineering Task Force</workgroup> <area>SEC</area>
<workgroup>sshm</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t> <t>
This document describes a widely deployed hybrid key exchange This document describes a widely deployed hybrid key exchange
method in the Secure Shell (SSH) protocol that is based on method in the Secure Shell (SSH) protocol that is based on
Streamlined NTRU Prime sntrup761 and X25519 with SHA-512. Streamlined NTRU Prime sntrup761 and X25519 with SHA-512.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <!-- [rfced] In the text below, may we either update to use complete titles of
the RFCs or use just the citation? Note that other instances in the
document use just the citation, as does similar text in RFC 8731.
a) From Introduction
Original:
Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The
key exchange protocol described in SSH transport layer [RFC4253]
supports an extensible set of methods. Elliptic Curve Algorithms in
SSH [RFC5656] defines how elliptic curves are integrated into the
extensible SSH framework, and SSH KEX Using Curve25519 and Curve448
[RFC8731] adds curve25519-sha256 to support the pre-quantum elliptic-
curve Diffie-Hellman X25519 function [RFC7748].
...
This document was derived from SSH KEX Using Curve25519 and Curve448
[RFC8731].
Perhaps A (full titles):
"The Secure Shell (SSH) Protocol Architecture" [RFC4251] is a secure
remote login protocol. The key exchange protocol described in "The
Secure Shell (SSH) Transport Layer Protocol" [RFC4253] supports an
extensible set of methods. The "Elliptic Curve Algorithm Integration
in the Secure Shell Transport Layer" [RFC5656] defines how elliptic
curves are integrated into the extensible SSH framework, and the
"Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448"
[RFC8731] adds curve25519-sha256 to support the pre-quantum Elliptic
Curve Diffie-Hellman (ECDH) X25519 function [RFC7748].
...
This document was derived from "Secure Shell (SSH) Key Exchange Method
Using Curve25519 and Curve448" [RFC8731].
Perhaps B (just citations):
Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The
key exchange protocol described in [RFC4253]
supports an extensible set of methods.
[RFC5656] defines how elliptic curves are integrated into the
extensible SSH framework, and
[RFC8731] adds curve25519-sha256 to support the pre-quantum Elliptic
Curve Diffie-Hellman (ECDH) X25519 function [RFC7748].
...
This document was derived from [RFC8731].
b) From Section 3
Original:
For consistency with ECC in SSH [RFC5656], which define the packet
syntax, we use those names in the rest of this document.
Perhaps A (full titles):
For consistency with "Elliptic Curve Algorithm Integration in the
Secure Shell Transport Layer" [RFC5656], which defines the packet
syntax, we use those names in the rest of this document.
Perhaps B (just citations):
For consistency with [RFC5656], which defines the packet
syntax, we use those names in the rest of this document.
c) From Security Considerations
Original:
The security considerations of the SSH Protocol [RFC4251], ECC for
SSH [RFC5656], Elliptic Curves for Security [RFC7748], and SSH KEX
Using Curve25519 and Curve448 [RFC8731] are inherited.
Perhaps A (full titles):
The security considerations of the following are inherited:
* "The Secure Shell (SSH) Protocol Architecture" [RFC4251]
* "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer"
[RFC5656]
* "Elliptic Curves for Security" [RFC7748]
* "Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448" [RF
C8731]
Perhaps B (just citations):
The security considerations in [RFC4251], [RFC5656], [RFC7748], and
[RFC8731] are inherited.
-->
<name>Introduction</name>
<t> <t>
Secure Shell (SSH) <xref target="RFC4251" format="default" Secure Shell (SSH)
sectionFormat="of" derivedContent="RFC4251"/> is a secure <xref target="RFC4251"/>
remote login protocol. The key exchange protocol described in is a secure remote login protocol. The key exchange protocol described in
SSH transport layer <xref target="RFC4253" format="default" SSH transport layer
sectionFormat="of" derivedContent="RFC4253"/> supports an <xref target="RFC4253"/>
extensible set of methods. Elliptic Curve Algorithms in SSH supports an extensible set of methods. Elliptic Curve Algorithms in SSH
<xref target="RFC5656" format="default" sectionFormat="of" <xref target="RFC5656"/>
derivedContent="RFC5656"/> defines how elliptic curves are defines how elliptic curves are integrated into the extensible SSH framew
integrated into the extensible SSH framework, and SSH KEX ork, and SSH KEX Using Curve25519 and Curve448
Using Curve25519 and Curve448 <xref target="RFC8731"/> adds <xref target="RFC8731"/>
curve25519-sha256 to support the pre-quantum elliptic-curve adds curve25519-sha256 to support the pre-quantum Elliptic Curve Diffie-H
Diffie-Hellman X25519 function <xref target="RFC7748"/>. ellman (ECDH) X25519 function
<xref target="RFC7748"/>.
</t> </t>
<t> <t>
Streamlined NTRU Prime <xref target="NTRUPrimePQCS"/> <xref Streamlined NTRU Prime <xref target="NTRUPrimePQCS"/> <xref target="NTRU
target="NTRUPrime"/> <xref target="NTRUPrimeWeb"/> provides Prime"/> <xref target="NTRUPrimeWeb"/> provides
post-quantum small lattice-based key-encapsulation mechanisms. post-quantum small lattice-based key-encapsulation mechanisms.
The sntrup761 instance has been implemented widely. The sntrup761 instance has been implemented widely.
</t> </t>
<t> <t>
This document specifies a hybrid construction using both This document specifies a hybrid construction using both
sntrup761 and X25519, in the intention that a hybrid would be sntrup761 and X25519, in the intention that a hybrid would be
secure if either algorithms is secure. secure if either algorithms is secure.
</t> </t>
<t> <t>
This document describes how to implement key exchange based on This document also describes how to implement key exchange based on
a hybrid between Streamlined NTRU Prime sntrup761 and X25519 a hybrid between Streamlined NTRU Prime sntrup761 and X25519
with SHA-512 <xref target="RFC6234" format="default" with SHA-512 <xref target="RFC6234"/> in SSH.
sectionFormat="of" derivedContent="RFC6234"/> in SSH.
</t> </t>
<t> <t>
This document was derived from SSH KEX Using Curve25519 and This document was derived from SSH KEX Using Curve25519 and
Curve448 <xref target="RFC8731" format="default" Curve448 <xref target="RFC8731"/>.
sectionFormat="of" derivedContent="RFC8731"/>.
</t> </t>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT be interpreted as
RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
"<bcp14>OPTIONAL</bcp14>" in this document are to be when, and only when, they appear in all capitals, as shown here.
interpreted as described in BCP 14 <xref target="RFC2119" </t>
format="default" sectionFormat="of" derivedContent="RFC2119"/>
<xref target="RFC8174" format="default" sectionFormat="of"
derivedContent="RFC8174"/> when, and only when, they appear in
all capitals, as shown here.
</t>
</section> </section>
<section> <section>
<name>Key Exchange Method: sntrup761x25519-sha512</name> <name>Key Exchange Method: sntrup761x25519-sha512</name>
<t> <t>
The key-agreement is done by the X25519 Diffie-Hellman The key agreement is done by the X25519 Diffie-Hellman
protocol as described in section <xref target="RFC8731" protocol as described in Section <xref target="RFC8731" sectionFormat="b
sectionFormat="bare" section="3" format="default" are" section="3">"Key Exchange Methods"</xref> of <xref target="RFC8731"/> and b
derivedLink="https://rfc-editor.org/rfc/rfc8731#section-3" y the key encapsulation method described
derivedContent="RFC8731">Key Exchange Methods</xref> of <xref
target="RFC8731"/>, and the key encapsulation method described
in <xref target="NTRUPrimePQCS"/>. in <xref target="NTRUPrimePQCS"/>.
</t> </t>
<t> <t>
The key exchange procedure re-uses the Elliptic Curve The key exchange procedure reuses the
Diffie-Hellman (ECDH) key exchange defined in section <xref ECDH key exchange defined in Sections <xref target="RFC5656" sectionForm
target="RFC5656" sectionFormat="bare" section="4" at="bare" section="4">"ECDH Key Exchange"</xref> and
format="default" <xref target="RFC5656" sectionFormat="bare" section="7.1">"ECDH Message
derivedLink="https://rfc-editor.org/rfc/rfc5656#section-4" Numbers"</xref> of <xref target="RFC5656"/>.
derivedContent="RFC5656">ECDH Key Exchange</xref> and section
<xref target="RFC5656" sectionFormat="bare" section="7.1"
format="default"
derivedLink="https://rfc-editor.org/rfc/rfc5656#section-7.1"
derivedContent="RFC5656">ECDH Message Numbers</xref> of <xref
target="RFC5656" format="default" sectionFormat="of"
derivedContent="RFC5656"/>.
</t> </t>
<t> <t>
The protocol flow and the SSH_MSG_KEX_ECDH_INIT and The protocol flow and the SSH_MSG_KEX_ECDH_INIT and
SSH_MSG_KEX_ECDH_REPLY messages are identical, except that we SSH_MSG_KEX_ECDH_REPLY messages are identical, except that we
use different ephemeral public values Q_C and Q_S and shared use different ephemeral public values Q_C and Q_S and shared
secret K as described below. secret K as described below.
</t> </t>
<t> <t>
Implementations MAY use names SSH_MSG_KEX_HYBRID_INIT where Implementations <bcp14>MAY</bcp14> use the name SSH_MSG_KEX_HYBRID_INIT
SSH_MSG_KEX_ECDH_INIT is used, and SSH_MSG_KEX_HYBRID_REPLY where
SSH_MSG_KEX_ECDH_INIT is used and the name SSH_MSG_KEX_HYBRID_REPLY
where SSH_MSG_KEX_ECDH_REPLY is used, as long as the encoding where SSH_MSG_KEX_ECDH_REPLY is used, as long as the encoding
on the wire is identical. These symbolic names do not appear on the wire is identical. These symbolic names do not appear
on the wire, they are merely used in specifications to refer on the wire; they are merely used in specifications to refer
to particular byte values. For consistency with ECC in SSH to particular byte values. For consistency with Elliptic Curve Cryptogr
<xref target="RFC5656"/>, which define the packet syntax, we aphy (ECC) in SSH
<xref target="RFC5656"/>, which defines the packet syntax, we
use those names in the rest of this document. use those names in the rest of this document.
</t> </t>
<t> <t>
The SSH_MSG_KEX_ECDH_INIT's value Q_C that holds the client's The SSH_MSG_KEX_ECDH_INIT's value Q_C that holds the client's
ephemeral public key MUST be constructed by concatenating the ephemeral public key <bcp14>MUST</bcp14> be constructed by concatenating
1158 byte public key output from the key generator of the
sntrup761 with the 32 byte K_A = X25519(a, 9) as described in 1158-byte public key output from the key generator of
sntrup761 with the 32-byte K_A = X25519(a, 9) as described in
<xref target="NTRUPrimePQCS"/> and <xref target="RFC8731"/>. <xref target="NTRUPrimePQCS"/> and <xref target="RFC8731"/>.
The Q_C value is thus 1190 bytes. The Q_C value is thus 1190 bytes.
</t> </t>
<t> <t>
The SSH_MSG_KEX_ECDH_REPLY's value Q_S that holds the server's The SSH_MSG_KEX_ECDH_REPLY's value Q_S that holds the server's
ephemeral public key MUST be constructed by concatenating the ephemeral public key <bcp14>MUST</bcp14> be constructed by concatenating
1039 byte ciphertext output from the key encapsulation the
mechanism of sntrup761 with the 32 byte K_B = X25519(b, 9) as 1039-byte ciphertext output from the key encapsulation
described in <xref target="NTRUPrimePQCS"/> and <xref mechanism of sntrup761 with the 32-byte K_B = X25519(b, 9) as
target="RFC8731"/>. The Q_S value is thus 1071 bytes. described in <xref target="NTRUPrimePQCS"/> and <xref target="RFC8731"/>
. The Q_S value is thus 1071 bytes.
</t> </t>
<t> <t>
Clients and servers <bcp14>MUST</bcp14> abort if the length of Clients and servers <bcp14>MUST</bcp14> abort if the length of
the received public keys Q_C or Q_S are not the expected the received public keys Q_C or Q_S are not the expected
lengths. An abort for these purposes is defined as a lengths. An abort for these purposes is defined as a
disconnect (SSH_MSG_DISCONNECT) of the session and disconnect (SSH_MSG_DISCONNECT) of the session and
<bcp14>SHOULD</bcp14> use the <bcp14>SHOULD</bcp14> use the
SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message, see SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message; see
section <xref target="RFC4253" sectionFormat="bare" Section <xref target="RFC4253" sectionFormat="bare" section="11.1">"Disc
section="11.1" format="default" onnection Message"</xref> of <xref target="RFC4253"/>. No further validation is
derivedLink="https://rfc-editor.org/rfc/rfc4253#section-11.1" required
derivedContent="RFC4253">Disconnection Message</xref> of <xref beyond what is described in <xref target="RFC7748"/>, <xref target="RFC8
target="RFC4253" format="default" sectionFormat="of" 731"/>, and <xref target="NTRUPrimePQCS"/>.
derivedContent="RFC4253"/>. No further validation is required
beyond what is described in <xref target="RFC7748"/>, <xref
target="RFC8731"/> and <xref target="NTRUPrimePQCS"/>.
</t> </t>
<t> <t>
The SSH_MSG_KEX_ECDH_REPLY's signature value is computed as The SSH_MSG_KEX_ECDH_REPLY's signature value is computed as
described in ECC for SSH <xref target="RFC5656"/> with the described in ECC for SSH <xref target="RFC5656"/> with the
following changes. Instead of encoding the shared secret K as following changes. Instead of encoding the shared secret K as
'mpint', it MUST be encoded as 'string'. The shared secret K "mpint", it <bcp14>MUST</bcp14> be encoded as "string". The shared secr
value MUST be the 64-byte output octet string of the SHA-512 et K
value <bcp14>MUST</bcp14> be the 64-byte output octet string of the SHA-
512
hash computed with the input as the 32-byte octet string key hash computed with the input as the 32-byte octet string key
output from the key encapsulation mechanism of sntrup761 output from the key encapsulation mechanism of sntrup761
concatenated with the 32-byte octet string of X25519(a, concatenated with the 32-byte octet string of X25519(a,
X25519(b, 9)) = X25519(b, X25519(a, 9)). X25519(b, 9)) = X25519(b, X25519(a, 9)).
</t> </t>
<t> <t>
Some earlier implementations may implement this protocol only Some earlier implementations may implement this protocol only
through the sntrup761x25519-sha512@openssh.com name, and through the name sntrup761x25519-sha512@openssh.com;
therefore it is RECOMMENDED to announce and accept that name therefore, it is <bcp14>RECOMMENDED</bcp14> to announce and accept that
as an alias of this protocol, to increase chances for name
as an alias of this protocol to increase chances for
successfully negotiating the protocol. successfully negotiating the protocol.
</t> </t>
</section> </section>
<section> <section>
<name>Acknowledgements</name>
<t>
Jan Mojzis added "sntrup4591761x25519-sha512@tinyssh.org" to
<xref target="TinySSH">TinySSH</xref> in 2018 and Markus
Friedl implemented it for <xref
target="OpenSSH">OpenSSH</xref> during 2019. During 2020
Damien Miller replaced sntrup4591761 with sntrup761 in
OpenSSH, to create "sntrup761x25519-sha512@openssh.com".
TinySSH added support for it during 2021. It became the
default key exchange algorithm in OpenSSH during 2022. That
is identical to the "sntrup761x25519-sha512" mechanism
described in this document.
</t>
<t>
Thanks to the following people for review and comments: Roman
Danyliw, Loganaden Velvindron, Panos Kampanakis, Mark Baushke,
Theo de Raadt, Tero Kivinen, Deb Cooley, Paul Wouters, Damien
Miller, Mike Bishop, Éric Vyncke, D. J. Bernstein, and Gorry
Fairhurst.
</t>
</section>
<section>
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The security considerations of the SSH Protocol <xref The security considerations of the SSH Protocol <xref target="RFC4251"/>
target="RFC4251" format="default" sectionFormat="of" , ECC for SSH <xref target="RFC5656"/>, Elliptic Curves for Security <xref targe
derivedContent="RFC4251"/>, ECC for SSH <xref target="RFC5656" t="RFC7748"/>, and SSH KEX Using Curve25519 and
format="default" sectionFormat="of"
derivedContent="RFC5656"/>, Elliptic Curves for Security <xref
target="RFC7748" format="default" sectionFormat="of"
derivedContent="RFC7748"/>, and SSH KEX Using Curve25519 and
Curve448 <xref target="RFC8731"/> are inherited. Curve448 <xref target="RFC8731"/> are inherited.
</t> </t>
<t> <t>
Streamlined NTRU Prime sntrup761 is aiming for the standard Streamlined NTRU Prime sntrup761 aims for the standard
goal of IND-CCA2 security, is widely implemented with good goal of IND-CCA2 security, is widely implemented with good
performance on a wide range of architectures, and has been performance on a wide range of architectures, and has been
studied by researchers for several years. However new studied by researchers for several years. However, new
cryptographic primitives should be introduced and trusted cryptographic primitives should be introduced and trusted
conservatively, and new research findings may be published at conservatively, and new research findings may be published at
any time that may warrant implementation reconsiderations. any time that may warrant implementation reconsideration.
The method described here to combine Curve25519 with sntrup761 The method described here to combine Curve25519 with sntrup761
(i.e., SHA-512 hashing the concatenated outputs) is also (i.e., SHA-512 hashing the concatenated outputs) is also
available for the same kind of cryptographic scrutiny. available for the same kind of cryptographic scrutiny.
</t> </t>
<t> <t>
The increase in communication size and computational The increase in communication size and computational
requirements may be a concern for restricted computational requirements may be a concern for restricted computational
devices, which would then not be able to take advantage of the devices, which would then not be able to take advantage of the
improved security properties offered by this work. improved security properties offered by this work.
</t> </t>
<t> <t>
Since sntrup761x25519-sha512 is expected to offer no reduction Since sntrup761x25519-sha512 is expected to offer no reduction
of security compared to curve25519-sha256, it is recommended of security compared to curve25519-sha256, it is recommended
that it is used and preferred whenever curve25519-sha256 is that it is used and preferred whenever curve25519-sha256 is
used today, when the extra communication size and used today, if the extra communication size and
computational requirements are acceptable. computational requirements are acceptable.
</t> </t>
<!-- [rfced] Please review the following phrases in the sentence below and
consider how to update for clarity.
- "security considerations of Curve25519-sha256 [RFC8731]"
- "is used bignum-encoded"
- "hash-processing time side-channel"
Original:
As discussed in the security considerations of Curve25519-sha256
[RFC8731], the X25519 shared secret K is used bignum-encoded in that
document, and this raise a potential for a hash-processing time side-
channel that could leak one bit of the secret due to different length
of the bignum sign pad.
Perhaps:
As discussed in the security considerations of
[RFC8731], the X25519 shared secret K is bignum-encoded in that
document, and this raises the potential for a side-
channel attack that could leak one bit of the secret due to the different len
gth
of the bignum sign pad.
-->
<t> <t>
As discussed in the security considerations of As discussed in the security considerations of
Curve25519-sha256 <xref target="RFC8731"/>, the X25519 shared curve25519-sha256 <xref target="RFC8731"/>, the X25519 shared
secret K is used bignum-encoded in that document, and this secret K is used bignum-encoded in that document, and this
raise a potential for a hash-processing time side-channel that raises the potential for a hash-processing time side-channel that
could leak one bit of the secret due to different length of could leak one bit of the secret due to the different length of
the bignum sign pad. This document resolve that problem by the bignum sign pad. This document resolves that problem by
using string-encoding instead of bignum-encoding. using string encoding instead of bignum encoding.
</t> </t>
<t> <t>
The security properties of the protocol in this document, SSH The security properties of the protocol in this document, SSH
itself, and the cryptographic algorithms used (including itself, and the cryptographic algorithms used (including
Streamlined NTRU Prime), all depends on the availability and Streamlined NTRU Prime) depend on the availability and
proper use of cryptographically secure random data. proper use of cryptographically secure random data.
</t> </t>
</section> </section>
<section> <section>
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
IANA is requested to add a new "Method Name" of IANA has added the following entry to the
"sntrup761x25519-sha512" to the "Key Exchange Method Names" "Key Exchange Method Names"
registry for Secure Shell (SSH) Protocol Parameters <xref registry within the "Secure Shell (SSH) Protocol Parameters" registry gr
target="IANA-KEX" format="default" sectionFormat="of" oup <xref target="IANA-KEX"/>:
derivedContent="IANA-KEX"/> with a "reference" field to this
RFC and the "OK to implement" field of "SHOULD".
</t> </t>
<table anchor="method-name-iana-table">
<name></name>
<thead>
<tr>
<th>Method Name</th>
<th>Reference</th>
<th>OK to Implement</th>
</tr>
</thead>
<tbody>
<tr>
<td>sntrup761x25519-sha512</td>
<td>RFC 9941</td>
<td>SHOULD</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"/> 119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4251.xml"/> 251.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4253.xml"/> 253.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5656.xml"/> 656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
FC.6234.xml"/> 234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7748.xml"/> 748.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8174.xml"/> 174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8731.xml"/> 731.xml"/>
<reference anchor="NTRUPrimePQCS"> <reference anchor="NTRUPrimePQCS" target="https://ntruprime.cr.yp.to/nis t/ntruprime-20201007.pdf">
<front> <front>
<title>NTRU Prime: round 3</title> <title>NTRU Prime: round 3</title>
<author initials="D.J." surname="Bernstein" fullname="D.J. Bernstein "/> <author initials="D.J." surname="Bernstein" fullname="D.J. Bernstein "/>
<author fullname="Billy Bob Brumley"/> <author fullname="Billy Bob Brumley"/>
<author fullname="Ming-Shing Chen,"/> <author fullname="Ming-Shing Chen,"/>
<author fullname="Chitchanok Chuengsatiansup"/> <author fullname="Chitchanok Chuengsatiansup"/>
<author fullname="Tanja Lange"/> <author fullname="Tanja Lange"/>
<author fullname="Adrian Marotzke"/> <author fullname="Adrian Marotzke"/>
<author fullname="Bo-Yuan Peng"/> <author fullname="Bo-Yuan Peng"/>
<author fullname="Nicola Tuveri"/> <author fullname="Nicola Tuveri"/>
<author fullname="Christine van Vredendaal"/> <author fullname="Christine van Vredendaal"/>
<author fullname="Bo-Yin Yang"/> <author fullname="Bo-Yin Yang"/>
<date month="October" year="2020" /> <date month="October" year="2020"/>
</front> </front>
<seriesInfo name="WWW" <seriesInfo name="DOI" value="10.5281/zenodo.13983972"/>
value="https://ntruprime.cr.yp.to/nist/ntruprime-20201007.
pdf" />
<seriesInfo name="DOI" value="10.5281/zenodo.13983972" />
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA-KEX" target="https://www.iana.org/assignments/ss <reference anchor="IANA-KEX" target="https://www.iana.org/assignments/ss
h-parameters/#ssh-parameters-16" h-parameters" quoteTitle="true">
quoteTitle="true" derivedAnchor="IANA-KEX">
<front> <front>
<title>Secure Shell (SSH) Protocol Parameters: Key Exchange Method N ames</title> <title>Key Exchange Method Names</title>
<author> <author>
<organization showOnFrontPage="true">IANA</organization> <organization showOnFrontPage="true">IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="NTRUPrime"> <reference anchor="NTRUPrime" target="https://ntruprime.cr.yp.to/ntrupri me-20170816.pdf">
<front> <front>
<title>NTRU Prime: reducing attack surface at low cost</title> <title>NTRU Prime: reducing attack surface at low cost</title>
<author initials="D.J." surname="Bernstein" fullname="D.J. Bernstein "/> <author initials="D.J." surname="Bernstein" fullname="D.J. Bernstein "/>
<author initials="C." surname="Chuengsatiansup" fullname="Chitchanok Chuengsatiansup"/> <author initials="C." surname="Chuengsatiansup" fullname="Chitchanok Chuengsatiansup"/>
<author initials="T." surname="Lange" fullname="Tanja Lange"/> <author initials="T." surname="Lange" fullname="Tanja Lange"/>
<author initials="C." surname="van Vredendaal" fullname="Christine v an Vredendaal"/> <author initials="C." surname="van Vredendaal" fullname="Christine v an Vredendaal"/>
<date month="August" year="2017" /> <date month="August" year="2017"/>
</front> </front>
<seriesInfo name="WWW"
value="https://ntruprime.cr.yp.to/ntruprime-20170816.pdf"
/>
</reference> </reference>
<reference anchor="NTRUPrimeWeb" target="https://ntruprime.cr.yp.to/" qu oteTitle="true" derivedAnchor="NTRU Prime"> <reference anchor="NTRUPrimeWeb" target="https://ntruprime.cr.yp.to/" qu oteTitle="true">
<front> <front>
<title>Webpage of NTRU Prime project</title> <title>NTRU Prime</title>
<author> <author>
<organization showOnFrontPage="true">NTRU Prime</organization> <organization showOnFrontPage="true">NTRU Prime</organization>
</author> </author>
<date month="" year=""/> <date month="" year=""/>
</front> </front>
</reference> </reference>
<reference anchor="TinySSH" target="https://www.tinyssh.org/" quoteTitle ="true" derivedAnchor="TinySSH"> <reference anchor="TinySSH" target="https://tinyssh.org/" quoteTitle="tr ue">
<front> <front>
<title>TinySSH</title> <title>TinySSH</title>
<author> <author>
<organization showOnFrontPage="true">TinySSH</organization> <organization showOnFrontPage="true">TinySSH</organization>
</author> </author>
<date month="" year=""/> <date month="" year=""/>
</front> </front>
</reference> </reference>
<reference anchor="OpenSSH" target="https://www.openssh.com/" quoteTitle ="true" derivedAnchor="OpenSSH"> <reference anchor="OpenSSH" target="https://www.openssh.com/" quoteTitle ="true">
<front> <front>
<title>OpenSSH</title> <title>OpenSSH</title>
<author> <author>
<organization showOnFrontPage="true">OpenSSH</organization> <organization showOnFrontPage="true">OpenSSH</organization>
</author> </author>
<date month="" year=""/> <date month="" year=""/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<section title="Test vectors"> <section>
<name>Test Vectors</name>
<figure> <!-- [rfced] Artwork/sourcecode
<artwork><![CDATA[
a) We updated the <artwork> in Appendix A to <sourcecode
type="test-vectors">. Please confirm that the value "test-vectors" is
correct. The current list of preferred values for "type" is available here:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. If this list
does not contain an applicable type, then feel free to suggest a new one.
Also, it is acceptable to leave the "type" attribute not set.
b) The lines in the figure in Appendix A are too long for the TXT output. For
sourcecode, the maximum line length is 69 characters (the current is 71
characters). Please let us know how to update to fit this requirement.
-->
<figure>
<sourcecode type="test-vectors"><![CDATA[
SSH2_MSG_KEX_ECDH_INIT SSH2_MSG_KEX_ECDH_INIT
client public key sntrup761: client public key sntrup761:
0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f ]....01v.......O 0000: 5d b3 a9 d3 93 30 31 76 0e 8a f5 87 f7 b2 8c 4f ]....01v.......O
0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 ..t.ko......2.a. 0016: 97 a1 74 0e 6b 6f cf 1a d9 d9 99 8a 32 a5 61 e5 ..t.ko......2.a.
0032: 9e 4d 93 67 e2 66 18 f0 0a f5 54 f4 48 65 0c 60 .M.g.f....T.He.` 0032: 9e 4d 93 67 e2 66 18 f0 0a f5 54 f4 48 65 0c 60 .M.g.f....T.He.`
0048: d1 12 92 c2 aa a9 e4 7c ea 32 a3 f5 86 cb c4 c3 .......|.2...... 0048: d1 12 92 c2 aa a9 e4 7c ea 32 a3 f5 86 cb c4 c3 .......|.2......
0064: d5 c2 6f 34 5e 7f d3 57 51 d3 e3 d9 cc 1c e4 49 ..o4^..WQ......I 0064: d5 c2 6f 34 5e 7f d3 57 51 d3 e3 d9 cc 1c e4 49 ..o4^..WQ......I
0080: bb ea 3e 2e 58 5e ac ba 0a b8 22 00 7c 77 a4 e0 ..>.X^....".|w.. 0080: bb ea 3e 2e 58 5e ac ba 0a b8 22 00 7c 77 a4 e0 ..>.X^....".|w..
0096: bd 16 5c 3a f7 b3 25 08 c1 81 fd 0d 9f 99 a3 be ..\:..%......... 0096: bd 16 5c 3a f7 b3 25 08 c1 81 fd 0d 9f 99 a3 be ..\:..%.........
skipping to change at line 601 skipping to change at line 687
0016: 10 82 38 36 40 be 2d 66 08 02 b8 17 cf eb b9 be ..86@.-f........ 0016: 10 82 38 36 40 be 2d 66 08 02 b8 17 cf eb b9 be ..86@.-f........
0032: 9b 73 7d 41 d6 cf bb 12 56 c5 8c ad 0a 6a e2 c9 .s}A....V....j.. 0032: 9b 73 7d 41 d6 cf bb 12 56 c5 8c ad 0a 6a e2 c9 .s}A....V....j..
0048: bf 84 a9 0a 72 91 eb 52 e4 c1 81 c8 d2 44 7b 56 ....r..R.....D{V 0048: bf 84 a9 0a 72 91 eb 52 e4 c1 81 c8 d2 44 7b 56 ....r..R.....D{V
encoded shared secret: encoded shared secret:
0000: 00 00 00 40 42 54 58 44 6f 22 75 63 04 de d7 5a ...@BTXDo"uc...Z 0000: 00 00 00 40 42 54 58 44 6f 22 75 63 04 de d7 5a ...@BTXDo"uc...Z
0016: 1f 23 fe f9 b1 8b 36 eb e0 e6 e2 60 c3 00 12 63 .#....6....`...c 0016: 1f 23 fe f9 b1 8b 36 eb e0 e6 e2 60 c3 00 12 63 .#....6....`...c
0032: b0 18 3f 42 49 07 e6 d8 22 b3 b7 6c 6c 38 37 b5 ..?BI..."..ll87. 0032: b0 18 3f 42 49 07 e6 d8 22 b3 b7 6c 6c 38 37 b5 ..?BI..."..ll87.
0048: b4 1f b0 d0 76 35 c7 57 e6 5e fb ef cb 5b c3 8a ....v5.W.^...[.. 0048: b4 1f b0 d0 76 35 c7 57 e6 5e fb ef cb 5b c3 8a ....v5.W.^...[..
0064: 1a 15 a9 6d ...m 0064: 1a 15 a9 6d ...m
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section numbered="false">
<name>Acknowledgements</name>
<t>
<contact fullname="Jan Mojzis"/> added
"sntrup4591761x25519-sha512@tinyssh.org" to <xref
target="TinySSH">TinySSH</xref> in 2018, and <contact fullname="Markus
Friedl"/> implemented it for <xref target="OpenSSH">OpenSSH</xref>
in 2019. In 2020, <contact fullname="Damien Miller"/> replaced
sntrup4591761 with sntrup761 in OpenSSH to create
"sntrup761x25519-sha512@openssh.com". TinySSH added support for it
in 2021. It became the default key exchange algorithm in OpenSSH
in 2022. That is identical to the "sntrup761x25519-sha512"
mechanism described in this document.
</t>
<t>
Thanks to the following people for review and comments: <contact
fullname="Roman Danyliw"/>, <contact fullname="Loganaden
Velvindron"/>, <contact fullname="Panos Kampanakis"/>, <contact
fullname="Mark Baushke"/>, <contact fullname="Theo de Raadt"/>,
<contact fullname="Tero Kivinen"/>, <contact fullname="Deb Cooley"/>,
<contact fullname="Paul Wouters"/>, <contact fullname="Damien
Miller"/>, <contact fullname="Mike Bishop"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="D. J. Bernstein"/>, and <contact
fullname="Gorry Fairhurst"/>.
</t>
</section>
</back> </back>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 51 change blocks. 
179 lines changed or deleted 331 lines changed or added

This html diff was produced by rfcdiff 1.48.