<?xml-model href="rfc7991bis.rnc"?>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-miller-sshm-composite-sigs-01"
  ipr="trust200902"
  obsoletes=""
  updates=""
  consensus="true"
  submissionType="IETF"
  xml:lang="en"
  version="3">

<front>
	<title abbrev="SSH PQ Composite Signatures">Post-Quantum Composite Signatures in SSH</title>
	<seriesInfo name="Internet-Draft" value="draft-miller-sshm-composite-sigs-01"/>
	<author fullname="Damien Miller" initials="D." surname="Miller">
		<organization>OpenSSH</organization>
		<address>
			<email>djm@openssh.com</email>
			<uri>https://www.openssh.com/</uri>
		</address>
	</author>
	<date />
	<area>Security</area>
	<workgroup>Secure Shell (SSHM)</workgroup>
	<keyword>ssh</keyword>
	<keyword>mldsa</keyword>
	<keyword>ed25519</keyword>
	<keyword>hybrid</keyword>
	<keyword>post-quantum</keyword>
	<abstract>
		<t>
		This document specifies the integration of two
		composite post-quantum signature schemes
		into the Secure Shell (SSH) protocol.
		These schemes combine the post-quantum Module-Lattice
		Digital Signature Algorithm (ML-DSA) with Elliptic Curve
		signature algorithms (Ed25519 and ECDSA, respectively)
		to provide security against both quantum and classical
		adversaries.
		</t>
	</abstract>
</front>

<middle>
<section><name>Introduction</name>
	<t>
	The Secure Shell (SSH) protocol <xref target="RFC4251" /> is
	a protocol for secure remote login and other secure network
	services over an untrusted network.
	</t>
	<t>
	The expected arrival of quantum computing poses a threat to
	traditional asymmetric cryptography. Post-quantum algorithms
	such as ML-DSA <xref target="FIPS204" /> have been developed
	to remain secure against a quantum computer-equipped
	adversary.
	However, given the relative novelty of the post-quantum
	algorithms, it is desirable to use composite schemes that
	combine post-quantum and classical algorithms to protect
	against quantum attacks while ensuring the composite scheme
	remains at least as secure as the chosen classical
	algorithm alone, should a vulnerability be discovered in
	the post-quantum algorithm or its implementation.
	</t>
	<t>
	This document specifies two composite signature schemes for SSH,
	mapping the COMPSIG-MLDSA44-Ed25519-SHA512 and
	COMPSIG-MLDSA87-ECDSA-P384-SHA512 schemes defined in
	<xref target="I-D.ietf-lamps-pq-composite-sigs" /> to the SSH
	protocol <xref target="RFC4253" /> using the SSH
	algorithm identifiers ssh-mldsa44-ed25519 and
	ssh-mldsa87-p384 respectively.
	</t>
</section>

<section anchor="requirements"><name>Requirements Language</name>
	<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
	are to be interpreted as described in BCP 14
	<xref target="RFC2119"/> <xref target="RFC8174"/> when,
	and only when, they appear in all capitals, as shown here.
	</t>
</section>

<section><name>Terminology</name>
	<t>
	All encoding data types ("byte", "string", etc.) are
	as specified in <xref target="RFC4251" section="5" />.
<!--
	Additionally, the type "byte[]" without a specified length
	within the square brackets indicates an unadorned sequence of
	zero or more bytes where the length is determined by context.
-->
	</t>
	<t>
	All length units are given in bytes unless otherwise specified.
	</t>
</section>

<section><name>Algorithm specifications</name>
	<t>
	For both the ssh-mldsa44-ed25519 and
	ssh-mldsa87-p384 algorithms, the underlying key
	generation, signing and verification primitives are as
	specified in
	<xref target="I-D.ietf-lamps-pq-composite-sigs" />, but are
	also described briefly below.
	</t>
	<section><name>Key generation</name>
		<t>
		Keys are generated using the process specified in
		<xref target="I-D.ietf-lamps-pq-composite-sigs" section="3.1" />.
		ML-DSA and Elliptic Curve keys are generated separately and the
		results from each are combined to form the composite key.
		Public key concatenation follows
		<xref target="I-D.ietf-lamps-pq-composite-sigs" section="4.1" />.
		The private keys are also concatenated together, where
		the ML-DSA and EdDSA private keys are represented by their
		seeds, but the ECDSA private key is the private key integer.
		Private key concatenation follows
		<xref target="I-D.ietf-lamps-pq-composite-sigs" section="4.2" />.
		</t>
		<t>
		ML-DSA key generation uses the ML-DSA.KeyGen_internal algorithm
		defined in <xref target="FIPS204" /> section 6.1 and not the
		ML-DSA.KeyGen algorithm, as only the former allows the
		private key seed to be emitted.
		</t>
		<section><name>ssh-mldsa44-ed25519</name>
			<t>
			For the ssh-mldsa44-ed25519 algorithm,
			Ed25519 key generation is described in
			<xref target="RFC8032" section="5.1.5" />.
			</t>
			<section anchor="pubkey-ed"><name>Composite raw public key</name>
				<t>
				The public keys from the ML-DSA and Ed25519 key
				generation algorithms are combined by simple
				concatenation to form the composite public key.
				The composite public key consists of the
				raw ML-DSA-44 public key (1312 bytes)
				and the Ed25519 public key (32 bytes):
				</t>
				<sourcecode>
    byte[1312] mldsa_pk
    byte[32]   ed25519_pk
				</sourcecode>
				<t>
				This 1344-byte combination is referred to as
				"composite_mldsa44_ed25519_public_key"
				henceforth in this document.
				</t>
			</section>
			<section anchor="privkey-ed"><name>Composite raw private key</name>
				<t>
				The composite private key is a concatenation
				of the private key seeds from the respective
				key generation algorithms.
				Each seed is 32 bytes:
				</t>
				<sourcecode>
    byte[32]  mldsa_seed
    byte[32]  ed25519_seed
				</sourcecode>
				<t>
				This 64-byte combination is referred to as
				"composite_mldsa44_ed25519_private_key"
				henceforth in this document.
				</t>
			</section>
		</section>
		<section><name>ssh-mldsa87-p384</name>
			<t>
			For the ssh-mldsa87-p384 algorithm, ECDSA key generation
			is described in <xref target="FIPS.186-5"/>
			Appendix A.2 using the Curve P-384 domain parameters
			from <xref target="SP.800-186"/> section G.1.3.
			</t>

			<section anchor="pubkey-ec"><name>Composite raw public key</name>
				<t>
				The public keys from the ML-DSA and ECDSA
				key generation algorithms are combined by
				simple concatenation to form the composite
				public key.
				It consists of the raw ML-DSA-87 public
				key (2592 bytes) and the uncompressed
				ECDSA public key "Q":
				</t>
				<sourcecode>
    byte[2592] mldsa_pk
    string     Q
				</sourcecode>
				<t>
				This combination is referred to as
				"composite_mldsa87_p384_public_key" henceforth
				in this document.
				</t>
			</section>
			<section anchor="privkey-ec"><name>Composite raw private key</name>
				<t>
				The composite private key is a concatenation of the
				ML-DSA seed (32 bytes) and the ECDSA private key "d".
				</t>
				<sourcecode>
    byte[32]  mldsa_seed
    mpint     d
				</sourcecode>
				<t>
				This combination is referred to as
				"composite_mldsa87_p384_private_key"
				henceforth in this document.
				</t>
			</section>
		</section>
		<section><name>SSH Public Key Format</name>
			<t>
			In the SSH protocol, both the "ssh-mldsa44-ed25519" and
			"ssh-mldsa87-p384" public key types share the following
			wire format:
			</t>
			<sourcecode>
    string    key_type_name
    string    composite_public_key
			</sourcecode>
			<t>
			Where "key_type_name" is either
			"ssh-mldsa44-ed25519" or
			"ssh-mldsa87-p384" and
			"composite_public_key"
			is the corresponding
			"composite_mldsa44_ed25519_public_key"
			(<xref target="pubkey-ed" />) or
			"composite_mldsa87_p384_public_key"
			(<xref target="pubkey-ec" />).
			</t>
		</section>
		<section><name>SSH Private Key Format</name>
			<t>
			When adding a key to an agent
			<xref target="I-D.ietf-sshm-ssh-agent" />
			using the SSH_AGENTC_ADD_IDENTITY or
			SSH_AGENTC_ADD_ID_CONSTRAINED
			messages, the key data MUST have the following
			format:
			</t>
			<sourcecode>
    string    key_type_name
    string    composite_public_key
    string    composite_private_key
			</sourcecode>
			<t>
			Where "key_type_name" is either
			"ssh-mldsa44-ed25519" or
			"ssh-mldsa87-p384".
			</t>
			<t>
			The "composite_public_key" is the corresponding
			"composite_mldsa44_ed25519_public_key"
			(<xref target="pubkey-ed" />) or
			"composite_mldsa87_p384_public_key"
			(<xref target="pubkey-ec" />).
			</t>
			<t>
			The "composite_private_key" is the corresponding
			"composite_mldsa44_ed25519_private_key"
			(<xref target="privkey-ed" />) or
			"composite_mldsa87_p384_private_key"
			(<xref target="privkey-ec" />).
			</t>
			<t>
			This private key serialisation may also be used as
			the basis of on-disk key formats, though these are
			beyond the scope of this document.
			</t>
		</section>
	</section>

	<section><name>Signatures</name>
		<section><name>Signature contexts</name>
			<t>
			The <xref target="I-D.ietf-lamps-pq-composite-sigs" />
			composite signature scheme used here, like its
			underlying ML-DSA component, accepts a Context
			parameter that is used to domain separate signatures.
			</t>
			<t>
			In all cases in the SSH protocol, this
			context value MUST be the empty string.
			</t>
		</section>
		<section anchor="sig"><name>Signature Generation</name>
			<t>
			To sign a message M, the signer first constructs a message
			representative M' as follows:
			</t>
			<sourcecode>
    M' = Prefix || Label || len(ctx) || ctx || SHA512(M)
			</sourcecode>
			<t>
			Where:
			</t>
			<ul>
				<li>
				Prefix: The ASCII string
				"CompositeAlgorithmSignatures2025"
			        [43 6F 6D 70 6F 73 69 74 65 41 6C 67
				6F 72 69 74 68 6D 53 69 67 6E 61 74
				75 72 65 73 32 30 32 35].
				</li>
				<li>
				Label: The ASCII algorithm label specific
				to the signature algorithm.
				</li>
				<li>
				len(ctx): A single unsigned byte representing
				the length of the context string.
				</li>
				<li>
				ctx: The context string.
				</li>
				<li>
				SHA512(M): The SHA-512 hash of the
				original message M.
				</li>
			</ul>
			<t>
			The signer computes and combines the ML-DSA and
			Elliptic Curve signatures.
			Below, mldsa_sk, ed25519_sk, and ecdsa_sk are the
			private signing keys derived from or represented by
			mldsa_seed, ed25519_seed, and d, respectively.
			</t>
			<section anchor="sig-ed"><name>ssh-mldsa44-ed25519</name>
				<t>
				This algorithm uses the ASCII string
				"COMPSIG-MLDSA44-Ed25519-SHA512"
			        [43 4F 4D 50 53 49 47 2D 4D 4C 44 53
				41 34 34 2D 45 64 32 35 35 31 39 2D
				53 48 41 35 31 32] as the Label when
				creating the M' message to be signed.
				</t>
				<t>
				The ML-DSA and Ed25519 signatures are
				calculated as:
				</t>
				<ul>
				<li>
				mldsa_sig = ML-DSA-44.Sign(mldsa_sk, M', ctx=Label)
				</li>
				<li>
				ed25519_sig = Ed25519.Sign(ed25519_sk, M')
				</li>
				</ul>
				<t>
				The final composite signature is the
				concatenation of mldsa_sig and ed25519_sig
				in this order.
				</t>
				<sourcecode>
    byte[2420] mldsa_sig
    byte[64]   ed25519_sig
				</sourcecode>
				<t>
				This 2484-byte combination is henceforth
				referred to as
				"composite_mldsa44_ed25519_signature".
				</t>
			</section>
			<section anchor="sig-ec"><name>ssh-mldsa87-p384</name>
				<t>
				This algorithm uses the ASCII string
				"COMPSIG-MLDSA87-ECDSA-P384-SHA512"
			        [43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 38 37
				2D 45 43 44 53 41 2D 50 33 38 34 2D 53 48
				41 35 31 32] as the Label when creating
				the M' message to be signed.
				</t>
				<t>
				The ML-DSA and ECDSA signatures are
				calculated as:
				</t>
				<ul>
				<li>
				mldsa_sig = ML-DSA-87.Sign(mldsa_sk, M', ctx=Label)
				</li>
				<li>
				r, s = ECDSA-P384.Sign(ecdsa_sk, M')
				</li>
				</ul>
				<t>
				The final composite signature is the concatenation of
				mldsa_sig, r, and s in this order.
				</t>
				<sourcecode>
    byte[4896] mldsa_sig
    mpint      r
    mpint      s
				</sourcecode>
				<t>
				This combination is henceforth referred to as
				"composite_mldsa87_p384_signature".
				</t>
			</section>
			<section><name>SSH Signature Format</name>
				<t>
				Signatures are represented in SSH using
				the following format:
				</t>
				<sourcecode>
    string    signature_type_name
    string    composite_signature
				</sourcecode>
				<t>
				Where "signature_type_name" is either
				"ssh-mldsa44-ed25519" or
				"ssh-mldsa87-p384" and
				"composite_signature"
				is the corresponding
				"composite_mldsa44_ed25519_signature"
				(<xref target="sig-ed" />) or
				"composite_mldsa87_p384_signature"
				(<xref target="sig-ec" />).
				</t>
			</section>
			<section><name>Signature Verification</name>
				<t>
				To verify a signature, the verifier
				reconstructs M' using the same process as
				defined for signature generation and verifies
				the ML-DSA and Elliptic Curve signatures.
				</t>
				<t>
				Both ML-DSA and Elliptic Curve verification
				operations MUST return success for the
				composite signature to verify successfully.
				Failure of either verification
				operation MUST cause the composite signature
				verification to fail.
				</t>
				<section><name>ssh-mldsa44-ed25519</name>
				<t>
				To verify an ssh-mldsa44-ed25519
				signature, the verifier performs:
				</t>
				<ul>
					<li>
					ML-DSA-44.Verify(mldsa_pk, M', mldsa_sig, ctx=Label)
					</li>
					<li>
					Ed25519.Verify(ed25519_pk, M', ed25519_sig)
					</li>
				</ul>
				<t>
				Both signatures must verify for the composite
				signature to verify.
				</t>
				</section>
				<section><name>ssh-mldsa87-p384</name>
				<t>
				To verify an ssh-mldsa87-p384
				signature, the verifier performs:
				</t>
				<ul>
					<li>
					ML-DSA-87.Verify(mldsa_pk, M', mldsa_sig, ctx=Label)
					</li>
					<li>
					ECDSA-P384.Verify(Q, M', r, s)
					</li>
				</ul>
				<t>
				Both signatures must verify for the composite
				signature to verify.
				</t>
				</section>
			</section>
		</section>
	</section>
</section>

<section><name>Security Considerations</name>
	<t>
	The security considerations of
	<xref target="I-D.ietf-lamps-pq-composite-sigs" /> apply here.
	</t>
	<t>
	The security of this composite scheme depends on the security of both
	component algorithms.
	An adversary must forge both ML-DSA and Elliptic Curve
	signatures in order to forge a composite signature.
	</t>
	<t>
	Implementations MUST NOT reuse component key material between
	composite and non-composite keys, or between multiple composite
	keys. See
	<xref target="I-D.ietf-lamps-pq-composite-sigs" /> section 9.3.
	</t>
	<t>
	If neither of the component algorithms are broken, both
	ssh-mldsa44-ed25519 and ssh-mldsa87-p384 are Existentially Unforgeable
	under Chosen-Message Attack (EUF-CMA), since ML-DSA, Ed25519, and ECDSA
	are all EUF-CMA and SHA-512 is collision-resistant.
	This property will be degraded against particular adversary classes
	if either of of the constituent signature algorithms is broken.
	If ML-DSA is broken then the composite will not be
	EUF-CMA against quantum adversaries.
	Similarly, if the classical signature scheme is broken then the
	composite will not be EUF-CMA against classical adversaries.
	See
	<xref target="I-D.ietf-lamps-pq-composite-sigs" /> section 9.2.1.
	</t>
	<t>
	This composite scheme is not Strongly Unforgeable under Chosen-Message
	Attack (SUF-CMA). Systems that rely on this property SHOULD NOT use this
	scheme.
	</t>
	<t>
	This composite scheme provides Weak Non-Separability (WNS) for both
	components due to evidence of the composite in the Prefix in `M'`. See
	<xref target="I-D.ietf-lamps-pq-composite-sigs" /> section 9.2.3.
	</t>
</section>

<section><name>IANA Considerations</name>
	<t>
	IANA is requested to register the algorithm names
	"ssh-mldsa44-ed25519" and "ssh-mldsa87-p384" in the
	"Public Key Algorithm Names" registry (<xref target="IANA-PUBKEYS" />).
	</t>
</section>

</middle>

<back>
	<references><name>References</name>
		<references><name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml" />
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml" />
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml" />
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lamps-pq-composite-sigs-19.xml" />

		<reference anchor="FIPS204">
			<front>
				<title>Module-lattice-based digital signature standard</title>
				<author><organization/></author>
				<date month="August" year="2024"/>
			</front>
			<seriesInfo name="FIPS" value="204" />
			<seriesInfo name="DOI" value="10.6028/nist.fips.204"/>
			<refcontent>National Institute of Standards and Technology (U.S.)</refcontent>
		</reference>
		<reference anchor="FIPS.186-5">                   
			<front>                                          
				<title>Digital Signature Standard (DSS)</title>
				<author>                   
					<organization> 
						National Institute of    
						Standards and Technology   
					</organization>                     
				</author>                              
				<date month="February" year="2023" />      
			</front>                                
			<refcontent>FIPS PUB 186-5</refcontent>
			<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
		</reference>
		<reference anchor="SP.800-186">                   
			<front>                                          
				<title>Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</title>
				<author>                   
					<organization> 
						National Institute of    
						Standards and Technology   
					</organization>                     
				</author>                              
				<date month="February" year="2023" />      
			</front>                                
			<refcontent>SP 800-186</refcontent>
			<seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
		</reference>
		</references>

		<references><name>Informative References</name>
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-sshm-ssh-agent-15.xml" />
			<reference anchor="IANA-PUBKEYS" target="https://www.iana.org/assignments/ssh-parameters/" quoteTitle="true" derivedAnchor="IANA-PUBKEYS">
				<front>
					<title>Public Key Algorithm Names</title>
					<author><organization showOnFrontPage="true">IANA</organization></author>
				</front>
			</reference>
		</references>
	</references>

<section anchor="Acknowledgements" numbered="false"><name>Acknowledgements</name>
	<t>
	Cindy Lin offered valuable feedback on this document.
	</t>
</section>

</back>
</rfc>
