One document matched: draft-merkle-tls-brainpool-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
XML2RFC offers an include feature described in the XML2RFC README
file. That syntax, however, contradicts the DTD requirements to
have <reference> elements within the <references> element, so an
XML parser is likely to find your XML file invalid. It may be
possible that XML2RFC will change their DTD so that the XML file
remains valid when their style of include is used.
In the meantime therefore, we use an alternative valid-XML approach
to includes, which unfortunately require that define your includes
at the beginning of the file. Since the biggest benefit of includes
is for references, this requires that your references be defined in
ENTITY clauses here before being "included" and cited elsewhere in
the file.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<!--
This template is for authors of IETF specifications containing MIB
modules. This template can be used as a starting point to produce
specifications that comply with the Operations & Management Area
guidelines for MIB module documents.
-->
<!--
Throughout this template, the marker "<xref target='TODO' />" is used to indicate an
element or text that requires replacement or removal.
-->
<!-- Intellectual Property section -->
<!--
The Intellectual Property section will be generated automatically by
XML2RFC, based on the ipr attribute in the rfc element.
-->
<!--
<xref target='TODO' />For Internet-drafts, indicate which intellectual property notice
to use per the rules of RFC3978.
Specify this in the ipr attribute. The value can be:
full3978 -
noModification3978 -
noDerivatives3978 -
<xref target='TODO' /> Specify the category attribute per RFC2026
options are info, std, bcp, or exp.
<xref target='TODO' /> if this document updates an RFC, specify the RFC in the
"updates" attribute
-->
<rfc category="info" updates="4492" submissionType="IETF" consensus="no" ipr="trust200902" docName="draft-merkle-tls-brainpool-04" >
<front>
<title abbrev="ECC Brainpool Curves for TLS">ECC Brainpool Curves for Transport Layer Security (TLS)</title>
<!-- see RFC2223 for guidelines regarding author names -->
<author fullname="Johannes Merkle" initials="J.M."
surname="Merkle">
<organization>secunet Security Networks</organization>
<address>
<postal>
<street>Mergenthaler Allee 77</street>
<city>65760 Eschborn</city>
<country>Germany</country>
</postal>
<phone>+49 201 5454 3091</phone>
<email>johannes.merkle@secunet.com</email>
</address>
</author>
<author fullname="Manfred Lochter" initials="M.L."
surname="Lochter">
<organization>Bundesamt fuer Sicherheit in der Informationstechnik (BSI)</organization>
<address>
<postal>
<street>Postfach 200363</street>
<city>53133 Bonn</city>
<country>Germany</country>
</postal>
<phone>+49 228 9582 5643</phone>
<email>manfred.lochter@bsi.bund.de</email>
</address>
</author>
<!-- <xref target='TODO' />: month and day will be generated automatically by XML2RFC;
be sure the year is current.
-->
<date year="2013" />
<workgroup></workgroup>
<keyword>TLS, Elliptic Curve Cryptography</keyword>
<abstract>
<t>This document specifies the use of several ECC Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In <xref target='RFC5639' />, a new set of elliptic curve groups over
finite prime fields for use in cryptographic applications was specified. These groups, denoted as ECC Brainpool curves, were generated in a verifiably pseudo-random way and comply with the security requirements of relevant standards from ISO <xref target='ISO1' /> <xref target='ISO2' />, ANSI <xref target='ANSI1' />, NIST <xref target='FIPS' />, and SecG <xref target='SEC2' />. </t>
<t><xref target='RFC4492' /> defines the usage of elliptic curves for authentication and key agreement in TLS 1.0 and TLS 1.1, and these mechanisms are also applicable to TLS 1.2 <xref target='RFC5246' />. While the ASN.1 object identifiers defined in <xref target='RFC5639' /> already allow usage of the ECC Brainpool curves for TLS (client or server) authentication through reference in X.509 certificates according to <xref target='RFC3279' /> and <xref target='RFC5480' /> , their negotiation for key exchange according to <xref target='RFC4492' /> requires the definition and assignment of additional NamedCurve IDs. This document specifies such values for three curves from <xref target='RFC5639' />.</t>
</section>
<!-- <section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref target='RFC2119' /> </t>.
</section>
-->
<section anchor="Main" title="Brainpool NamedCurve Types">
<t>According to <xref target='RFC4492' />, the name space NamedCurve is used for the negotiation of elliptic curve groups for key exchange during a handshake starting a new TLS session. This document adds new NamedCurve types to three elliptic curves defined in <xref target='RFC5639' /> as follows.</t>
<figure>
<artwork><![CDATA[
enum {
brainpoolP256r1(TBD1),
brainpoolP384r1(TBD2),
brainpoolP512r1(TBD3)
} NamedCurve;
]]></artwork>
</figure>
<t>These curves are suitable for use with DTLS <xref target='RFC6347' />.</t>
<t>Test vectors for a Diffie-Hellman key exchange using these elliptic curves are provided in <xref target='test_vectors' /></t>
</section>
<section title="IANA Considerations">
<t> IANA is requested to assign numbers for the ECC Brainpool curves listed in <xref target='Main' /> to the Transport Layer Security
(TLS) Parameters registry EC Named Curve <xref target='IANA-TLS' /> as follows. </t>
<texttable anchor='namedCurves'>
<preamble></preamble>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>TBD1</c>
<c>brainpoolP256r1</c>
<c>Y</c>
<c>This doc</c>
<c>TBD2</c>
<c>brainpoolP384r1</c>
<c>Y</c>
<c>This doc</c>
<c>TBD3</c>
<c>brainpoolP512r1</c>
<c>Y</c>
<c>This doc</c>
<postamble></postamble>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations of <xref target='RFC5246' /> apply accordingly. </t>
<t>The confidentiality, authenticity and integrity of the TLS communication is limited by the weakest cryptographic primitive applied. In order to achieve a maximum security level when using one of the elliptic curves from <xref target='namedCurves' /> for authentication and / or key exchange in TLS, the key derivation function, the algorithms and key lengths of symmetric encryption and message authentication as well as the algorithm, bit length and hash function used for signature generation should be chosen according to the recommendations of <xref target="NIST800-57"/> and <xref target="RFC5639"/>. Furthermore, the private Diffie-Hellman keys should be selected with the same bit length as the order of the group generated by the base point G and with approximately maximum entropy.</t>
<t>Implementations of elliptic curve cryptography for TLS may be susceptible to side-channel attacks. Particular care should be taken for implementations that internally transform curve points to points on the corresponding "twisted curve", using the map (x',y') = (x*Z^2, y*Z^3) with the coefficient Z specified for that curve in <xref target='RFC5639' />, in order to take advantage of an an efficient arithmetic based on the twisted curve's special parameters (A = -3): although the twisted curve itself offers the same level of security as the corresponding random curve (through mathematical equivalence), an arithmetic based on small curve parameters may be harder to protect against side-channel attacks. General guidance on resistence of elliptic curve cryptography implementations against side-channel-attacks is given in <xref target='BSI1' /> and <xref target="HMV"/>.</t>
</section>
<!-- The Author's Addresses section will be generated automatically by XML2RFC from the front information -->
</middle>
<back>
<!-- References Section -->
<!-- Section 4.7f of <xref target='RFC2223bis' /> specifies the requirements for the
references sections. In particular, there MUST be separate lists of
normative and informative references, each in a separate section.
The style SHOULD follow that of recently published RFCs.
The standard MIB boilerplate available at
http://www.ops.ietf.org/mib-boilerplate.html includes lists of
normative and informative references that MUST appear in all IETF
specifications that contain MIB modules. If items from other MIB
modules appear in an IMPORTS statement in the Definitions section,
then the specifications containing those MIB modules MUST be included
in the list of normative references. When items are imported from an
IANA-maintained MIB module the corresponding normative reference
SHALL point to the on-line version of that MIB module. It is the
policy of the RFC Editor that all references must be cited in the
text; such citations MUST appear in the overview section where
documents containing imported definitions (other those already
mentioned in the MIB boilerplate) are required to be mentioned (cf.
Section 3.2).
In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->
<references title="Normative References">
<reference anchor="IANA-TLS" target="http://www.iana.org/assignments/tls-parameters/tls-parameters.xml">
<front>
<title>Transport Layer Security (TLS) Parameters</title>
<author>
<organization>Internet Assigned Numbers Authority</organization>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC4492'>
<front>
<title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)</title>
<author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'>
<organization /></author>
<author initials='N.' surname='Bolyard' fullname='N. Bolyard'>
<organization /></author>
<author initials='V.' surname='Gupta' fullname='V. Gupta'>
<organization /></author>
<author initials='C.' surname='Hawk' fullname='C. Hawk'>
<organization /></author>
<author initials='B.' surname='Moeller' fullname='B. Moeller'>
<organization /></author>
<date year='2006' month='May' />
<abstract>
<t>This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4492' />
<format type='TXT' octets='72231' target='http://www.rfc-editor.org/rfc/rfc4492.txt' />
</reference>
<reference anchor='RFC5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>
<reference anchor='RFC5639'>
<front>
<title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation</title>
<author initials='M.' surname='Lochter' fullname='M. Lochter'>
<organization /></author>
<author initials='J.' surname='Merkle' fullname='J. Merkle'>
<organization /></author>
<date year='2010' month='March' />
<abstract>
<t>This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5639' />
<format type='TXT' octets='50566' target='http://www.rfc-editor.org/rfc/rfc5639.txt' />
</reference>
<reference anchor='RFC6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2012' month='January' />
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6347' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor="ANSI1">
<front>
<title>
Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)
</title>
<author>
<organization>American National Standards Institute</organization>
</author>
<date month="" year="2005"/>
</front>
<seriesInfo name="ANSI" value="X9.62"/>
</reference>
<reference anchor="BSI1">
<front>
<title>Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations
</title>
<author>
<organization>Bundesamt fuer Sicherheit in der Informationstechnik</organization>
</author>
<date month="July" year="2011"/>
</front>
</reference>
<reference anchor="FIPS">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="December" year="1998" />
</front>
<seriesInfo name="FIPS" value="PUB 186-2" />
</reference>
<reference anchor="HMV">
<front>
<title>
Guide to Elliptic Curve Cryptography
</title>
<author initials="D" surname="Hankerson">
<organization>
</organization>
</author>
<author initials="A" surname="Menezes">
<organization>
</organization>
</author>
<author initials="S" surname="Vanstone">
<organization>
</organization>
</author>
<date month="" year="2004"/>
</front>
<seriesInfo name="Springer" value="Verlag"/>
</reference>
<reference anchor="ISO1">
<front>
<title>
Information Technology - Security Techniques - Digital Signatures with Appendix - Part 3: Discrete Logarithm Based Mechanisms
</title>
<author>
<organization>International Organization for Standardization </organization>
</author>
<date month="" year="2006"/>
</front>
<seriesInfo name="ISO/IEC" value="14888-3"/>
</reference>
<reference anchor="ISO2">
<front>
<title>
Information Technology - Security Techniques - Cryptographic Techniques Based on Elliptic Curves - Part 2: Digital signatures
</title>
<author>
<organization>International Organization for Standardization </organization>
</author>
<date month="" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="15946-2"/>
</reference>
<reference anchor="NIST800-57">
<front>
<title>
Recommendation for Key Management - Part 1: General (Revised)
</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-57"/>
</reference>
<reference anchor='RFC3279'>
<front>
<title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='L.' surname='Bassham' fullname='L. Bassham'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<date year='2002' month='April' />
<abstract>
<t>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='3279' />
<format type='TXT' octets='53833' target='http://www.rfc-editor.org/rfc/rfc3279.txt' />
</reference>
<reference anchor='RFC5480'>
<front>
<title>Elliptic Curve Cryptography Subject Public Key Information</title>
<author initials='S.' surname='Turner' fullname='S. Turner'>
<organization /></author>
<author initials='D.' surname='Brown' fullname='D. Brown'>
<organization /></author>
<author initials='K.' surname='Yiu' fullname='K. Yiu'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='T.' surname='Polk' fullname='T. Polk'>
<organization /></author>
<date year='2009' month='March' />
<abstract>
<t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5480' />
<format type='TXT' octets='36209' target='http://www.rfc-editor.org/rfc/rfc5480.txt' />
</reference>
<reference anchor='RFC6090'>
<front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'>
<organization /></author>
<author initials='K.' surname='Igoe' fullname='K. Igoe'>
<organization /></author>
<author initials='M.' surname='Salter' fullname='M. Salter'>
<organization /></author>
<date year='2011' month='February' />
<abstract>
<t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='6090' />
<format type='TXT' octets='75993' target='http://www.rfc-editor.org/rfc/rfc6090.txt' />
</reference>
<reference anchor="SEC1">
<front>
<title>
Elliptic Curve Cryptography
</title>
<author>
<organization>Certicom Research
</organization>
</author>
<date month="September" year="2000"/>
</front>
<seriesInfo name="Standards for Efficient Cryptography (SEC)" value="1"/>
</reference>
<reference anchor="SEC2">
<front>
<title>
Recommended Elliptic Curve Domain Parameters
</title>
<author>
<organization>Certicom Research
</organization>
</author>
<date month="September" year="2000"/>
</front>
<seriesInfo name="Standards for Efficient Cryptography (SEC)" value="2"/>
</reference>
</references>
<section anchor="test_vectors" title="Test Vectors">
<t>This section provides some test vectors for example Diffie-Hellman
key exchanges using each of the curves defined in <xref target="namedCurves" /> . In all
of the following sections the following notation is used:
<list>
<t> d_A: the secret key of party A </t>
<t> x_qA: the x-coordinate of the public key of party A </t>
<t> y_qA: the y-coordinate of the public key of party A </t>
<t> d_B: the secret key of party B </t>
<t> x_qB: the x-coordinate of the public key of party B </t>
<t> y_qB: the y-coordinate of the public key of party B </t>
<t> x_Z: the x-coordinate of the shared secret that results from
completion of the Diffie-Hellman computation, i.e. the hex representation of the pre-master secret</t>
<t> y_Z: the y-coordinate of the shared secret that results from
completion of the Diffie-Hellman computation </t>
</list>
The field elements x_qA, y_qA, x_qB, y_qB, x_Z, y_Z are represented as hexadecimal values using the FieldElement-to-OctetString conversion method specified in <xref target='SEC1' />.
</t>
<section title="256 Bit Curve">
<t>Curve brainpoolP256r1
<list>
<t>dA = 81DB1EE100150FF2EA338D708271BE38300CB54241D79950F77B063039804F1D </t>
<t>x_qA = 44106E913F92BC02A1705D9953A8414DB95E1AAA49E81D9E85F929A8E3100BE5 </t>
<t>y_qA = 8AB4846F11CACCB73CE49CBDD120F5A900A69FD32C272223F789EF10EB089BDC </t>
<t>dB = 55E40BC41E37E3E2AD25C3C6654511FFA8474A91A0032087593852D3E7D76BD3 </t>
<t>x_qB = 8D2D688C6CF93E1160AD04CC4429117DC2C41825E1E9FCA0ADDD34E6F1B39F7B </t>
<t>y_qB = 990C57520812BE512641E47034832106BC7D3E8DD0E4C7F1136D7006547CEC6A </t>
<t>x_Z = 89AFC39D41D3B327814B80940B042590F96556EC91E6AE7939BCE31F3A18BF2B </t>
<t>y_Z = 49C27868F4ECA2179BFD7D59B1E3BF34C1DBDE61AE12931648F43E59632504DE </t>
</list></t>
</section>
<section title="384 Bit Curve">
<t>Curve brainpoolP384r1
<list>
<t>dA = 1E20F5E048A5886F1F157C74E91BDE2B98C8B52D58E5003D57053FC4B0BD65D6F15EB5D1EE1610DF870795143627D042 </t>
<t>x_qA = 68B665DD91C195800650CDD363C625F4E742E8134667B767B1B476793588F885AB698C852D4A6E77A252D6380FCAF068 </t>
<t>y_qA = 55BC91A39C9EC01DEE36017B7D673A931236D2F1F5C83942D049E3FA20607493E0D038FF2FD30C2AB67D15C85F7FAA59 </t>
<t>dB = 032640BC6003C59260F7250C3DB58CE647F98E1260ACCE4ACDA3DD869F74E01F8BA5E0324309DB6A9831497ABAC96670 </t>
<t>x_qB = 4D44326F269A597A5B58BBA565DA5556ED7FD9A8A9EB76C25F46DB69D19DC8CE6AD18E404B15738B2086DF37E71D1EB4 </t>
<t>y_qB = 62D692136DE56CBE93BF5FA3188EF58BC8A3A0EC6C1E151A21038A42E9185329B5B275903D192F8D4E1F32FE9CC78C48 </t>
<t>x_Z = 0BD9D3A7EA0B3D519D09D8E48D0785FB744A6B355E6304BC51C229FBBCE239BBADF6403715C35D4FB2A5444F575D4F42 </t>
<t>y_Z = 0DF213417EBE4D8E40A5F76F66C56470C489A3478D146DECF6DF0D94BAE9E598157290F8756066975F1DB34B2324B7BD </t>
</list></t>
</section>
<section title="512 Bit Curve">
<t>Curve brainpoolP512r1
<list>
<t>dA = 16302FF0DBBB5A8D733DAB7141C1B45ACBC8715939677F6A56850A38BD87BD59B09E80279609FF333EB9D4C061231FB26F92EEB04982A5F1D1764CAD57665422 </t>
<t>x_qA = 0A420517E406AAC0ACDCE90FCD71487718D3B953EFD7FBEC5F7F27E28C6149999397E91E029E06457DB2D3E640668B392C2A7E737A7F0BF04436D11640FD09FD </t>
<t>y_qA = 72E6882E8DB28AAD36237CD25D580DB23783961C8DC52DFA2EC138AD472A0FCEF3887CF62B623B2A87DE5C588301EA3E5FC269B373B60724F5E82A6AD147FDE7 </t>
<t>dB = 230E18E1BCC88A362FA54E4EA3902009292F7F8033624FD471B5D8ACE49D12CFABBC19963DAB8E2F1EBA00BFFB29E4D72D13F2224562F405CB80503666B25429 </t>
<t>x_qB = 9D45F66DE5D67E2E6DB6E93A59CE0BB48106097FF78A081DE781CDB31FCE8CCBAAEA8DD4320C4119F1E9CD437A2EAB3731FA9668AB268D871DEDA55A5473199F </t>
<t>y_qB = 2FDC313095BCDD5FB3A91636F07A959C8E86B5636A1E930E8396049CB481961D365CC11453A06C719835475B12CB52FC3C383BCE35E27EF194512B71876285FA </t>
<t>x_Z = A7927098655F1F9976FA50A9D566865DC530331846381C87256BAF3226244B76D36403C024D7BBF0AA0803EAFF405D3D24F11A9B5C0BEF679FE1454B21C4CD1F </t>
<t>y_Z = 7DB71C3DEF63212841C463E881BDCF055523BD368240E6C3143BD8DEF8B3B3223B95E0F53082FF5E412F4222537A43DF1C6D25729DDB51620A832BE6A26680A2 </t>
</list></t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 03:36:58 |