<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC8152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8152.xml"> <!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml"> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions -->"rfc2629-xhtml.ent"> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-atkins-suit-cose-walnutdsa-07"ipr="trust200902"> <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER ***** -->number="9021" ipr="trust200902" obsoletes="" updates="" submissionType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="WalnutDSA COSE Sigs">Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) </title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="9021"/> <author fullname="Derek Atkins"initials="D.A."initials="D" surname="Atkins"> <organization>Veridify Security</organization> <address> <postal> <street>100 Beard Sawmill Rd, Suite 350</street><!-- Reorder these if your country does things differently --><city>Shelton</city> <region>CT</region> <code>06484</code><country>US</country><country>United States of America</country> </postal> <phone>+1 617 623 3745</phone> <email>datkins@veridify.com</email><!-- uri and facsimile elements may also be added --></address> </author> <datemonth="January" year="2021" /> <!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. --> <!-- Meta-data Declarations -->month="May" year="2021"/> <area>Security</area> <workgroup>Internet Engineering Task Force</workgroup><!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. --><keyword>COSE</keyword> <keyword>WalnutDSA</keyword><!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --><abstract> <t>This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic Cryptography<!-- (see <xref target="WALNUTDSA" /> and <xref target="WALNUTSPEC" />) -->with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.</t> <t>The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties of WalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF. </t><t>WalnutDSA(TM)<t>WalnutDSA and the Walnut Digital SignatureAlgorithm(TM)Algorithm are trademarks of Veridify SecurityInc..</t>Inc.</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) <xref target="WALNUTDSA"/>format="default"/> for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax <xref target="RFC8152"/> syntax.format="default"/>. WalnutDSA is aGroup-Theoretic <xref target="GTC" />Group Theoretic signature scheme <xref target="GTC" format="default"/> where signature validation is bothcomputationally-computationally andspace-efficient,space efficient, even on very small processors. Unlike many hash-based signatures, there is no state required and no limit on the number of signatures that can be made. WalnutDSA private and public keys are relatively small; however, the signatures are larger than RSA andECC,Elliptic Curve Cryptography (ECC), but still smaller than most all other quantum-resistant schemes (including all hash-based schemes).</t> <t>COSE provides a lightweight method to encode structured data. WalnutDSA is a lightweight, quantum-resistant digital signature algorithm. The goal of this specification is to document a method to leverage WalnutDSA in COSE in a way that would allow multiple developers to build compatible implementations.</t> <t>As with all cryptosystems, the initial versions of WalnutDSA underwent significant cryptanalysis,andand, in some cases, identified potential issues. For more discussion on this topic, a summary of all published cryptanalysis can be found inSection 5.2.<xref target="meth_sec"/>. Validated issues were addressed by reparameterization in updated versions of WalnutDSA. Although the IETF has neither evaluated the security properties of WalnutDSA norhas the IETFendorsed WalnutDSA as of this publication, this document provides a method to use WalnutDSA in conjunction with IETF protocols. As always, users of any security algorithm are advised to research the security properties of the algorithm and make their own judgment about the risks involved.</t> <sectiontitle="Motivation">numbered="true" toc="default"> <name>Motivation</name> <t>Recent advances in cryptanalysis <xref target="BH2013"/>format="default"/> and progress in the development of quantum computers <xref target="NAS2019"/>format="default"/> pose a threat to widely deployed digital signature algorithms. As a result, there is a need to prepare for a day that cryptosystems such as RSA andDSA thatDSA, which depend on discrete logarithm andfactoringfactoring, cannot be depended upon.</t> <t>If large-scale quantum computers are ever built, these computers will be able to break many of thepublic-keypublic key cryptosystems currently in use. A post-quantum cryptosystem <xref target="PQC"/>format="default"/> is a system that is secure against quantum computers that have more than a trivial number of quantum bits (qubits). It is open to conjecture when it will be feasible to build such computers; however, RSA, DSA,ECDSA,the Elliptic Curve Digital Signature Algorithm (ECDSA), andEdDSAthe Edwards-Curve Digital Signature Algorithm (EdDSA) are all vulnerable if large-scale quantum computers come to pass.</t> <t>WalnutDSA does not depend on the difficulty of discretelogarithmlogarithms or factoring. As aresultresult, this algorithm is considered to be resistant to post-quantum attacks.</t> <t>Today, RSA and ECDSA are often used to digitally sign software updates. Unfortunately, implementations of RSA and ECDSA can be relatively large, and verification can take a significant amount of time on some very small processors. Therefore, we desire a digital signature scheme that verifies faster with less code. Moreover, in preparation for a day when RSA, DSA, and ECDSA cannot be depended upon, a digital signature algorithm is needed that will remain secure even if there are significantcryptoanalyticcryptanalytic advances or a large-scale quantum computer is invented. WalnutDSA, specified in <xref target="WALNUTSPEC"/>,format="default"/>, is a quantum-resistant algorithm that addresses these requirements.</t> </section> <sectiontitle="Trademark Notice"> <t>WalnutDSA(TM)numbered="true" toc="default"> <name>Trademark Notice</name> <t>WalnutDSA and the Walnut Digital SignatureAlgorithm(TM)Algorithm are trademarks of Veridify SecurityInc..</t>Inc.</t> </section> </section> <sectiontitle="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" />target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="WalnutDSAanchor="alg_overview" numbered="true" toc="default"> <name>WalnutDSA AlgorithmOverview" anchor="alg_overview">Overview</name> <t>This specification makes use of WalnutDSA signatures as described in <xref target="WALNUTDSA"/>format="default"/> and more concretely specified in <xref target="WALNUTSPEC"/>.format="default"/>. WalnutDSA is aGroup-TheoreticGroup Theoretic cryptographic signature scheme that leverages infinite group theory as the basis of its security and maps that to a one-way evaluation of a series of matrices over small finite fields with permuted multiplicants based on the group input. WalnutDSA leverages the SHA2-256 and SHA2-512 one-way hash algorithms <xref target="SHA2"/>format="default"/> in a hash-then-sign process.</t> <t>WalnutDSA is based on a one-way function,E-Multiplication,E-multiplication, which is an action on the infinite group. A singleE-MultiplicationE-multiplication step takes as input a matrix and permutation, a generator in the group, and a set of T-values (entries in the finite field) and outputs a new matrix and permutation. To process a long string of generators (like a WalnutDSA signature),E-MultiplicationE-multiplication is iterated over each generator. Due to its structure,E-MultiplicationE-multiplication is extremely easy to implement.</t> <t>In addition to beingquantum-resistant,quantum resistant, the two main benefits of using WalnutDSA are that the verification implementation is very small and WalnutDSA signature verification is extremely fast, even on very small processors (including 16- and even 8-bitMCUs).microcontrollers). This lends it well to use in constrained and/or time-sensitive environments.</t> <t>WalnutDSA has several parameters required to process a signature. The main parameters are N and q. The parameter N defines the size of the group by defining the number of strands inuse,use and implies working in an NxN matrix. The parameter q defines the number of elements in the finite field. Signature verification also requires a set of T-values, which is an ordered list of N entries in the finite field F_q.</t> <t>A WalnutDSA signature is just a string of generators in the infinite group, packed into a byte string.</t> </section> <sectiontitle="WalnutDSAanchor="alg_ids" numbered="true" toc="default"> <name>WalnutDSA AlgorithmIdentifiers" anchor="alg_ids">Identifiers</name> <t>The CBOR Object Signing and Encryption (COSE) syntax <xref target="RFC8152"/>format="default"/> supports two signature algorithm schemes. This specification makes use of the signature with appendix scheme for WalnutDSA signatures.</t> <t>The signature value is a large byte string. The byte string is designed for easy parsing, and it includes a length (number of generators) and type codes that indirectly provide all of the information that is needed to parse the byte string during signature validation.</t> <t>When using a COSE key for this algorithm, the following checks are made:</t><t><list style="symbols"> <t>The 'kty'<ul spacing="normal"> <li>The "kty" fieldMUST<bcp14>MUST</bcp14> be present, and itMUST<bcp14>MUST</bcp14> be'WalnutDSA'.</t> <t>If"WalnutDSA".</li> <li>If the'alg'"alg" field is present,anditMUST<bcp14>MUST</bcp14> be'WalnutDSA'.</t> <t>If"WalnutDSA".</li> <li>If the'key_ops'"key_ops" field is present, itMUST<bcp14>MUST</bcp14> include'sign'"sign" when creating a WalnutDSAsignature.</t> <t>Ifsignature.</li> <li>If the'key_ops'"key_ops" field is present, itMUST<bcp14>MUST</bcp14> include'verify'"verify" when verifying a WalnutDSAsignature.</t> <t>Ifsignature.</li> <li>If the'kid'"kid" field is present, itMAY<bcp14>MAY</bcp14> be used to identify the WalnutDSAKey.</t> </list></t>Key.</li> </ul> </section> <sectiontitle="Security Considerations" anchor="sec_consider"> <section title="Implementationanchor="sec_consider" numbered="true" toc="default"> <name>Security Considerations</name> <section numbered="true" toc="default"> <name>Implementation SecurityConsiderations">Considerations</name> <t>ImplementationsMUST<bcp14>MUST</bcp14> protect the private keys. Use of a hardware security module (HSM) is one way to protect the private keys.Compromise ofCompromising the private keys may result in the ability to forge signatures. As a result, when a private key is stored on non-volatile media or stored in a virtual machine environment, care must be taken to preserve confidentiality and integrity.</t> <t>The generation of private keys relies on random numbers. The use of inadequatepseudo-randompseudorandom number generators (PRNGs) to generate these values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult, and <xref target="RFC4086"/>format="default"/> offers important guidance in this area.</t> <t>The generation of WalnutDSA signatures also depends on random numbers. While the consequences of an inadequatepseudo-random number generator (PRNG)PRNG to generate these valuesisare much less severe than the generation of private keys, the guidance in <xref target="RFC4086"/>format="default"/> remains important.</t> </section> <sectiontitle="Methodnumbered="true" toc="default" anchor="meth_sec"> <name>Method SecurityConsiderations">Considerations</name> <t>The Walnut Digital Signature Algorithm has undergone significant cryptanalysis since it was first introduced, and several weaknesses were found in early versions of the method, resulting in the description of several attacks with exponential computational complexity. A full writeup of all the analysis can be found in <xref target="WalnutDSAAnalysis"/>.format="default"/>. In summary, the original suggested parameters (N=8, q=32) were too small, leading to many of these exponential-growth attacks being practical. However, current parameters render these attacks impractical. The following paragraphs summarize the analysis and how the current parameters defeat all the previous attacks.</t> <t>First, the team of Hart etalal. found a universal forgery attack based on agroup factoringgroup-factoring problem that runs inO(q^((N-1)/2))O(q<sup>(N-1)/2</sup>) with a memory complexity of log_2(q)N^2 q^((N-1)/2).N<sup>2</sup> q<sup>(N-1)/2</sup>. With parameters N=10 and q=M31 (the Mersenne prime2^312<sup>31</sup> - 1), the runtime is2^1392<sup>139</sup> and memory complexity is2^151. W. Beullens2<sup>151</sup>. W. Beullens found a modification of this attack but its runtime is even longer.</t> <t>Next, Beullens and Blackburn found several issues with the original method and parameters.FirstFirst, they used a Pollard-Rho attack and discovered the original public key space was too small.SpecificallySpecifically, they require thatq^(N(N-1)-1) > 2^(2*Security Level).q<sup>N(N-1)-1</sup> > 2<sup>2*Security Level</sup>. One can clearly see thatN=10, q=M31(N=10, q=M31) provides 128-bit security andN=10, q=M61(N=10, q=M61) provides 256-bit security.</t> <t>Beullens and Blackburn also found two issues with the original message encoder of WalnutDSA. First, the original encoder was non-injective, which reduced the available signature space. This was repaired in an update. Second, they pointed out that the dimension of the vector space generated by the encoder was too small. Specifically, they require thatq^dimension > 2^(2*Security Level).q<sup>dimension</sup> > 2<sup>(2*Security Level)</sup>. With N=10, the current encoder produces a dimension of6666, which clearly provides sufficient security with q=M31 or q=M61.</t> <t>The final issue discovered by Beullens and Blackburn was a process to theoretically "reverse"E-Multiplication.E-multiplication. First, their process requires knowing the initial matrix and permutation (whichisare known for WalnutDSA). But more importantly, their process runs atO(q^((N-1)/2)) which,O(q<sup>((N-1)/2)</sup>), which forN=10, q=M31(N=10, q=M31) is greater than2^128.</t>2<sup>128</sup>.</t> <t>A team at Steven's Institute leveraged a length-shortening attack that enabled them to remove the cloaking elements and then solve a conjugacy search problem to derive the private keys. Their attack requires both knowledge of the permutation being cloaked and also that the cloaking elements themselves are conjugates. By adding additional concealed cloakingelementselements, the attack requires an N! search for each cloaking element. By inserting k concealed cloaking elements, this requires the attacker to perform(N!)^k(N!)<sup>k</sup> work. This allows k to be set to meet the desired security level.</t> <t>Finally, Merz and Petit discovered that using a Garside Normal Form of a WalnutDSA signature enabled them to find commonalities with the Garside Normal Form of the encoded message. Using thosecommonalitiescommonalities, they were able to splice into a signature and create forgeries. Increasing the number of cloaking elements, specifically within the encoded message, sufficiently obscures the commonalities and blocks this attack.</t> <t>In summary, most of these attacks are exponential inrun timeruntime and it can be shown that current parameters put the runtime beyond the desired security level. The final two attacks are also sufficiently blocked to the desired security level.</t> </section> </section><!-- Possibly a 'Contributors' section ... --><section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>IANAis requested to addhas added entries for WalnutDSA signatures in the "COSE Algorithms" registry and WalnutDSA public keys in the "COSE Key Types" and "COSE Key Type Parameters" registries.</t> <sectiontitle="COSEnumbered="true" toc="default"> <name>COSE Algorithms RegistryEntry">Entry</name> <t>The following new entry has been registered in the "COSE Algorithms"registry has the following columns:</t> <t><list> <t>Name: WalnutDSA</t> <t>Value: TBD1 (Value between -65536 to -257 or 256-65535 to be assigned by IANA)</t> <t>Description: WalnutDSA signature</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> <t>Recommended: No</t> </list></t> </section> <section title="COSEregistry:</t> <dl> <dt>Name: </dt> <dd>WalnutDSA </dd> <dt>Value: </dt> <dd>-260 </dd> <dt>Description: </dt> <dd>WalnutDSA signature </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> <dt>Recommended: </dt> <dd>No </dd> </dl> </section> <section numbered="true" toc="default"> <name>COSE Key Types RegistryEntry">Entry</name> <t>The following new entry has been registered in the "COSE Key Types"registry has the following columns:</t> <t><list> <t>Name: WalnutDSA</t> <t>Value: TBD2 (Value to be assigned by IANA)</t> <t>Description: WalnutDSAregistry:</t> <dl> <dt>Name: </dt> <dd>WalnutDSA </dd> <dt>Value: </dt> <dd>6 </dd> <dt>Description: </dt> <dd>WalnutDSA publickey</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>key </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="COSEnumbered="true" toc="default"> <name>COSE Key TypeParameterParameters RegistryEntries">Entries</name> <t>The following sections detail the additions to the "COSE Key Type Parameters" registry.</t> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter:N">N</name> <t>The newentry Nentry, N, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: N</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>N </dd> <dt>Label: </dt> <dd>-1 </dd> <dt>CBOR Type:uint</t> <t>Description: Group</dt> <dd>uint </dd> <dt>Description: </dt> <dd>Group and Matrix (NxN)size</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>size </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter:q">q</name> <t>The newentry qentry, q, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: q</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>q </dd> <dt>Label: </dt> <dd>-2 </dd> <dt>CBOR Type:uint</t> <t>Description: Finite</dt> <dd>uint </dd> <dt>Description: </dt> <dd>Finite fieldF_q</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>F_q </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter:t-values">t-values</name> <t>The newentry t-valuesentry, t-values, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: t-values</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>t-values </dd> <dt>Label: </dt> <dd>-3 </dd> <dt>CBOR Type:array</dt> <dd>array (ofuint)</t> <t>Description: Listuint) </dd> <dt>Description: </dt> <dd>List of T-values,entiesentries inF_q</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>F_q </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter: matrix1">1</name> <t>The newentryentry, matrix11, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: matrix 1</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>matrix 1 </dd> <dt>Label: </dt> <dd>-4 </dd> <dt>CBOR Type:array</dt> <dd>array (of array ofuint)</t> <t>Description: NxNuint) </dd> <dt>Description: </dt> <dd>NxN Matrix ofentiesentries in F_q in column-majorform</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>form </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter: permutation1">1</name> <t>The newentryentry, permutation11, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: permutation 1</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>permutation 1 </dd> <dt>Label: </dt> <dd>-5 </dd> <dt>CBOR Type:array</dt> <dd>array (ofuint)</t> <t>Description: Permutationuint) </dd> <dt>Description: </dt> <dd>Permutation associated with matrix1</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>1 </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> <sectiontitle="WalnutDSAnumbered="true" toc="default"> <name>WalnutDSA Parameter: matrix2">2</name> <t>The newentryentry, matrix22, has been registered in the "COSE Key Type Parameters" registryhas the following columns:</t> <t><list> <t>Keyas follows:</t> <dl> <dt>Key Type:TBD2 (Value assigned by IANA above)</t> <t>Name: matrix 2</t> <t>Label: TBD (Value to be assigned by IANA)</t> <t>CBOR</dt> <dd>6 </dd> <dt>Name: </dt> <dd>matrix 2 </dd> <dt>Label: </dt> <dd>-6 </dd> <dt>CBOR Type:array</dt> <dd>array (of array ofuint)</t> <t>Description: NxNuint) </dd> <dt>Description: </dt> <dd>NxN Matrix ofentiesentries in F_q in column-majorform</t> <t>Reference: This document (Number to be assigned by RFC Editor)</t> </list></t>form </dd> <dt>Reference: </dt> <dd>RFC 9021 </dd> </dl> </section> </section> </section> </middle><!-- *****BACK MATTER ***** --><back><references title="Normative References"> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> &RFC2119; &RFC8174; &RFC8152;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/> <reference anchor="SHA2"> <front><title>FIPS Publication 180-3: Secure<title>Secure HashStandard</title>Standard (SHS)</title> <author initials="" surname="" fullname=""> <organization>National Institute of Standards and Technology (NIST)</organization> </author> <datemonth="October" year="2008" />month="August" year="2015"/> </front> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/> </reference> <referenceanchor="WALNUTDSA" target="https://doi.org/10.1080/23799927.2020.1831613">anchor="WALNUTDSA"> <front> <title>WalnutDSA(TM): Agroup-theoreticgroup theoretic digital signature algorithm</title> <authorinitials="I.A."initials="I" surname="Anshel" fullname="Iris Anshel"><organization /><organization/> </author> <authorinitials="D.A."initials="D" surname="Atkins" fullname="Derek Atkins"><organization /><organization/> </author> <authorinitials="D.G."initials="D" surname="Goldfeld" fullname="Dorian Goldfeld"><organization /><organization/> </author> <authorinitials="P.G."initials="P" surname="Gunnells" fullname="PaulEE. Gunnells"><organization /><organization/> </author> <date month="November"year="2020" />year="2020"/> </front> <seriesInfo name="DOI" value="10.1080/23799927.2020.1831613"/> </reference> </references><references title="Informative References"> <!-- Here we use entities that we defined at the beginning. --> <!-- A reference written by by an organization not a person. --><references> <name>Informative References</name> <reference anchor="WALNUTSPEC" target="https://csrc.nist.gov/projects/post-quantum-cryptography/round-1-submissions"> <front> <title>The Walnut Digital Signature Algorithm Specification</title> <authorinitials="I.A."initials="I" surname="Anshel" fullname="Iris Anshel"><organization /><organization/> </author> <authorinitials="D.A."initials="D" surname="Atkins" fullname="Derek Atkins"><organization /><organization/> </author> <authorinitials="D.G."initials="D" surname="Goldfeld" fullname="Dorian Goldfeld"><organization /><organization/> </author> <authorinitials="P.G."initials="P" surname="Gunnells" fullname="PaulEGunnells"><organization /><organization/> </author> <date month="November"year="2018" />year="2018"/> </front> <refcontent>Post-Quantum Cryptography</refcontent> </reference> <reference anchor="GTC" target="https://www.crcpress.com/Group-Theoretic-Cryptography/Vasco-Steinwandt/p/book/9781584888369"> <front> <title>Group Theoretic Cryptography</title> <authorinitials="M.I.G.V."initials="M" surname="Vasco" fullname="Maria Isabel Gonzalez Vasco"><organization /><organization/> </author> <authorinitials="R.S."initials="R" surname="Steinwandt" fullname="Rainer Steinwandt"><organization /><organization/> </author> <date month="April"year="2015" />year="2015"/> </front> <seriesInfo name="ISBN" value="9781584888369"/> </reference> <reference anchor="WalnutDSAAnalysis" target="https://eprint.iacr.org/2019/472"> <front> <title>Defeating the Hart et al, Beullens-Blackburn, Kotov-Menshov-Ushakov, and Merz-Petit Attacks on WalnutDSA(TM)</title> <authorinitials="I.A."initials="I" surname="Anshel" fullname="Iris Anshel"><organization /><organization/> </author> <authorinitials="D.A."initials="D" surname="Atkins" fullname="Derek Atkins"><organization /><organization/> </author> <authorinitials="D.G."initials="D" surname="Goldfeld" fullname="Dorian Goldfeld"><organization /><organization/> </author> <authorinitials="P.G."initials="P" surname="Gunnells" fullname="Paul E Gunnells"><organization /><organization/> </author> <date month="May"year="2019" />year="2019"/> </front> </reference>&RFC4086;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <reference anchor="BH2013"target="https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf">target="https://www.slideshare.net/astamos/bh-slides"> <front> <title>The Factoring Dead: Preparing for the Cryptopocalypse</title> <authorinitials="T.P."initials="T" surname="Ptacek"fullname=""> <organization />fullname="Thomas Ptacek"> <organization/> </author> <authorinitials="J.R."initials="J" surname="Ritter"fullname=""> <organization />fullname="Tom Ritter, "> <organization/> </author> <authorinitials="J.S."initials="J" surname="Samuel"fullname=""> <organization />fullname="Javed Samue"> <organization/> </author> <authorinitials="A.S."initials="A" surname="Stamos"fullname=""> <organization />fullname="Alex Stamos"> <organization/> </author> <date month="August"year="2013" />year="2013"/> </front> </reference> <referenceanchor="NAS2019" target="http://dx.doi.org/10.17226/25196">anchor="NAS2019"> <front> <title>Quantum Computing: Progress and Prospects</title><author ><author> <organization>National Academies of Sciences, Engineering, and Medicine</organization> </author> <dateyear="2019" />year="2019"/> </front> <seriesInfo name="DOI" value="10.17226/25196"/> </reference> <referenceanchor="PQC" target="http://www.pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf">anchor="PQC"> <front> <title>Introduction to post-quantum cryptography</title> <authorinitials="D.B." surname="Bernstein"> <organization /> </author> <date month="" year="2009" /> </front> </reference> <!-- <reference anchor="S1997" target="http://dx.doi.org/10.1137/S0097539795293172"> <front> <title>Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer</title> <author initials="P.S." surname="Shor" fullname="Peter Shor"> <organization />initials="D" surname="Bernstein" fullname="Daniel J. Bernstein"> <organization/> </author> <dateyear="1997" />year="2009"/> </front> <seriesInfoname="SIAM Journal on Computing 26(5)," value="1484-26"/>name="DOI" value="10.1007/978-3-540-88702-7"/> </reference>--></references> </references> <section anchor="Acknowledgments"title="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>A big thank you toRuss Housley<contact fullname="Russ Housley"/> for his input on the concepts and text of this document.</t> </section><!-- <section anchor="app-additional" title="Additional Stuff"> <t>This becomes an Appendix.</t> </section> --> <!-- Change Log v00 2019-03-20 DA Initial version v01 2019-11-04 DA Convert to Informational Edits to be more in line with the Hash-Sig draft v02 2019-12-20 DA Incorporated suggestions from reviews (ISE, etc) v03 2020-06-15 DA Refresh document v04 2020-07-08 DA Suggested changes from Adrian v05 2020-11-05 DA More suggestions from Adrian and fixing references v06 2021-01-26 DA Changes from IESG --></back> </rfc>