One document matched: draft-irtf-cfrg-curves-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-irtf-cfrg-curves-01" ipr="trust200902">
<front>
<title abbrev="cfrgcurve">Elliptic Curves for Security</title>
<author fullname="Adam Langley" initials="A." surname="Langley">
<organization>Google</organization>
<address>
<postal>
<street>345 Spear St</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>US</country>
</postal>
<email>agl@google.com</email>
</address>
</author>
<author fullname="Rich Salz" initials="R." surname="Salz">
<organization>Akamai Technologies</organization>
<address>
<postal>
<street>8 Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>
<email>rsalz@akamai.com</email>
</address>
</author>
<author fullname="Sean Turner" initials="S." surname="Turner">
<organization>IECA, Inc.</organization>
<address>
<postal>
<street>3057 Nutley Street</street>
<street>Suite 106</street>
<city>Fairfax</city>
<region>VA</region>
<code>22031</code>
<country>US</country>
</postal>
<email>turners@ieca.com</email>
</address>
</author>
<date month="January" year="2015" />
<area>General</area>
<workgroup>CFRG</workgroup>
<keyword>elliptic curve</keyword>
<keyword>cryptography</keyword>
<keyword>ecc</keyword>
<abstract>
<t>This memo describes an algorithm for deterministically generating parameters for elliptic curves over prime fields offering high practical security in cryptographic applications, including Transport Layer Security (TLS) and X.509 certificates. It also specifies a specific curve at the ~128-bit security level.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Since the initial standardization of elliptic curve cryptography (ECC) in <xref target="SEC1"/> there has been significant progress related to both efficiency and security of curves and implementations. Notable examples are algorithms protected against certain side-channel attacks, various 'special' prime shapes which allow faster modular arithmetic, and a larger set of curve models from which to choose. There is also concern in the community regarding the generation and potential weaknesses of the curves defined in <xref target="NIST"/>.</t>
<t>This memo describes a deterministic algorithm for generating cryptographic elliptic curves over a given prime field. The constraints in the generation process produce curves that support constant-time, exception-free scalar multiplications that are resistant to a wide range of side-channel attacks including timing and cache attacks, thereby offering high practical security in cryptographic applications. The deterministic algorithm operates without any input parameters that would permit manipulation of the resulting curves. The selection between curve models is determined by choosing the curve form that supports the fastest (currently known) complete formulas for each modularity option of the underlying field prime. Specifically, the Edwards curve x^2 + y^2 = 1 + dx^2y^2 is used with primes p with p = 3 mod 4, and the twisted Edwards curve -x^2 + y^2 = 1 + dx^2y^2 is used when p = 1 mod 4.</t>
</section>
<section title="Requirements Language">
<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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="security-requirements" title="Security Requirements">
<t>For each curve at a specific security level:</t>
<t>
<list style="numbers">
<t>The domain parameters SHALL be generated in a simple, deterministic manner, without any secret or random inputs. The derivation of the curve parameters is defined in <xref target="generation" />.</t>
<t>The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in <xref target="Smart" />, <xref target="AS" />, and <xref target="S" />, as in <xref target="EBP" />.</t>
<t>MOV Degree: the embedding degree k MUST be greater than (r - 1) / 100, as in <xref target="EBP" />.</t>
<t>CM Discriminant: discriminant D MUST be greater than 2^100, as in <xref target="SC" />.</t>
</list>
</t>
</section>
<section anchor="notation" title="Notation">
<t>Throughout this document, the following notation is used:</t>
<t>
<list style="hanging">
<t hangText="p">Denotes the prime number defining the underlying field.</t>
<t hangText="GF(p)">The finite field with p elements.</t>
<t hangText="d">An element in the finite field GF(p), not equal to -1 or zero.</t>
<t hangText="Ed">An Edwards curve: an elliptic curve over GF(p) with equation x^2 + y^2 = 1 + dx^2y^2.</t>
<t hangText="tEd">A twisted Edwards curve where a=-1: an elliptic curve over GF(p) with equation -x^2 + y^2 = 1 + dx^2y^2.</t>
<t hangText="oddDivisor">The largest odd divisor of the number of GF(p)-rational points on a (twisted) Edwards curve.</t>
<t hangText="oddDivisor'">The largest odd divisor of the number of GF(p)-rational points on the non-trivial quadratic twist of a (twisted) Edwards curve.</t>
<t hangText="cofactor">The cofactor of the subgroup of order oddDivisor in the group of GF(p)-rational points of a (twisted) Edwards curve.</t>
<t hangText="cofactor'">The cofactor of the subgroup of order oddDivisor in the group of GF(p)-rational points on the non-trivial quadratic twist of a (twisted) Edwards curve.</t>
<t hangText="trace">The trace of Frobenius of Ed or tEd such that #Ed(GF(p)) = p + 1 - trace or #tEd(GF(p)) = p + 1 - trace, respectively.</t>
<t hangText="P">A generator point defined over GF(p) of prime order oddDivisor on Ed or tEd.</t>
<t hangText="X(P)">The x-coordinate of the elliptic curve point P.</t>
<t hangText="Y(P)">The y-coordinate of the elliptic curve point P.</t>
</list>
</t>
</section>
<section anchor="generation" title="Parameter Generation">
<t>This section describes the generation of the curve parameter, namely d, of the elliptic curve. The input to this process is p, the prime that defines the underlying field. The size of p determines the amount of work needed to compute a discrete logarithm in the elliptic curve group and choosing a precise p depends on many implementation concerns. The performance of the curve will be dominated by operations in GF(p) and thus carefully choosing a value that allows for easy reductions on the intended architecture is critical. This document does not attempt to articulate all these considerations.</t>
<section anchor="edwards-generation" title="Edwards Curves">
<t>For p = 3 mod 4, the elliptic curve Ed in Edwards form is determined by the non-square element d from GF(p) (not equal to -1 or zero) with smallest absolute value such that #Ed(GF(p)) = cofactor * oddDivisor, #Ed'(GF(p)) = cofactor' * oddDivisor', cofactor = cofactor' = 4, and both subgroup orders oddDivisor and oddDivisor' are prime. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from <xref target="security-requirements" /> are met.</t>
<t>These cofactors are chosen because they are minimal.</t>
<figure align="center" title="GenerateCurveEdwards">
<artwork align="left"><![CDATA[
Input: a prime p, with p = 3 mod 4
Output: the parameter d defining the curve Ed
1. Set d = 0
2. repeat
repeat
if (d > 0) then
d = -d
else
d = -d + 1
end if
until d is not a square in GF(p)
Compute oddDivisor, oddDivisor', cofactor and cofactor' where #Ed(GF(p)) =
cofactor * oddDivisor, #Ed'(GF(p)) = cofactor' * oddDivisor', cofactor and
cofactor' are powers of 2 and oddDivisor, oddDivisor' are odd.
until ((cofactor = cofactor' = 4), oddDivisor is prime and oddDivisor' is prime)
3. Output d]]></artwork>
</figure>
</section>
<section anchor="twisted-edwards-generation" title="Twisted Edwards Curves">
<t>For a prime p = 1 mod 4, the elliptic curve tEd in twisted Edwards form is determined by the non-square element d from GF(p) (not equal to -1 or zero) with smallest absolute value such that #tEd(GF(p)) = cofactor * oddDivisor, #tEd'(GF(p)) = cofactor' * oddDivisor', cofactor = 8, cofactor' = 4 and both subgroup orders oddDivisor and oddDivisor' are prime. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from <xref target="security-requirements" /> are met.</t>
<t>These cofactors are chosen so that they are minimal such that the cofactor of the main curve is greater than the cofactor of the twist. For 1 mod 4 primes, the cofactors are never equal. If the cofactor of the twist is larger than the cofactor of the curve, algorithms may be vulnerable to a small-subgroup attack if a point on the twist is incorrectly accepted.</t>
<figure align="center" title="GenerateCurveTEdwards">
<artwork align="left"><![CDATA[
Input: a prime p, with p = 1 mod 4
Output: the parameter d defining the curve tEd
1. Set d = 0
2. repeat
repeat
if (d > 0) then
d = -d
else
d = -d + 1
end if
until d is not a square in GF(p)
Compute oddDivisor, oddDivisor', cofactor, cofactor' where #tEd(GF(p)) =
cofactor * oddDivisor, #tEd'(GF(p)) = cofactor' * oddDivisor', cofactor
and cofactor' are powers of 2 and oddDivisor, oddDivisor' are odd.
until (cofactor = 8 and cofactor' = 4 and rd is prime and rd' is prime)
3. Output d]]></artwork>
</figure>
</section>
</section>
<section anchor="curves" title="Recommended Curves">
<t>For the ~128-bit security level, the prime 2^255-19 is recommended for performance on a wide-range of architectures. This prime is congruent to 1 mod 4 and the above procedure results in the following twisted Edwards curve, called <spanx style="verb">intermediate25519</spanx>:</t>
<t>
<list style="hanging">
<t hangText="p">2^255-19</t>
<t hangText="d">121665</t>
<t hangText="order">2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed</t>
<t hangText="cofactor">8</t>
</list>
</t>
<t>In order to be compatible with widespread existing practice, the recommended curve is an isogeny of this curve. An isogeny is a "renaming" of the points on the curve and thus cannot affect the security of the curve:</t>
<t>
<list style="hanging">
<t hangText="p">2^255-19</t>
<t hangText="d">37095705934669439343138083508754565189542113879843219016388785533085940283555</t>
<t hangText="order">2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed</t>
<t hangText="cofactor">8</t>
<t hangText="X(P)">15112221349535400772501151409588531511454012693041857206046113283949847762202</t>
<t hangText="Y(P)">46316835694926478169428394003475163141307993866256225615783033603165251855960</t>
</list>
</t>
<t>The d value in this curve is much larger than the generated curve and this might slow down some implementations. If this is a problem then implementations are free to calculate on the original curve, with small d, as the isogeny map can be merged into the affine transform without any performance impact.</t>
<t>The latter curve is isomorphic to a Montgomery curve defined by v^2 = u^3 + 486662u^2 + u where the maps are:</t>
<figure align="center">
<artwork align="left"><![CDATA[
(u, v) = ((1+y)/(1-y), sqrt(-1)*sqrt(486664)*u/x)
(x, y) = (sqrt(-1)*sqrt(486664)*u/v, (u-1)/(u+1)]]></artwork>
</figure>
<t>The base point maps onto the Montgomery curve such that u = 9, v = 14781619447589544791020593568409986887264606134616475288964881837755586237401.</t>
<t>The Montgomery curve defined here is equal to the one defined in <xref target="curve25519"/> and the isomorphic twisted Edwards curve is equal to the one defined in <xref target="ed25519"/>.</t>
</section>
<section title="The curve25519 function">
<t>The <spanx style="verb">curve25519</spanx> function performs scalar multiplication on the Montgomery form of the above curve. (This is used when implementing Diffie-Hellman.) The function takes a scalar and a u-coordinate as inputs and produces a u-coordinate as output. Although the function works internally with integers, the inputs and outputs are 32-byte strings and this specification defines their encoding.</t>
<t>U-coordinates are elements of the underlying field GF(2^255-19) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256 * u[1] + 256^2 * u[2] + ... + 256^n * u[n] is congruent to the value modulo p and u[n] is minimal. When receiving such an array, implementations MUST mask the most-significant bit in the final byte. This is done to preserve compatibility with point formats which reserve the sign bit for use in other protocols and to increase resistance to implementation fingerprinting.</t>
<t>For example, the following functions implement this in Python, although the Python code is not intended to be performant nor side-channel free:</t>
<figure align="center">
<artwork align="left"><![CDATA[
def decodeLittleEndian(b):
return sum([b[i] << 8*i for i in range(32)])
def decodeUCoordinate(u):
u_list = [ord(b) for b in u]
u_list[31] &= 0x7f
return decodeLittleEndian(u_list)
def encodeUCoordinate(u):
u = u % p
return ''.join([chr((u >> 8*i) & 0xff) for i in range(32)])]]></artwork>
</figure>
<t>(EDITORS NOTE: draft-turner-thecurve25519function also says "Implementations MUST reject numbers in the range [2^255-19, 2^255-1], inclusive." but I'm not aware of any implementations that do so.)</t>
<t>Scalars are assumed to be randomly generated bytes. In order to decode 32 bytes into an integer scalar, set the three least significant bits of the first byte and the most significant bit of the last to zero, set the second most significant bit of the last byte to 1 and, finally, decode as little-endian. This means that resulting integer is of the form 2^254 + 8 * {0, 1, ..., 2^(251) - 1}.</t>
<figure align="center">
<artwork align="left"><![CDATA[
def decodeScalar(k):
k_list = [ord(b) for b in k]
k_list[0] &= 248
k_list[31] &= 127
k_list[31] |= 64
return decodeLittleEndian(k_list)]]></artwork>
</figure>
<t>To implement the <spanx style="verb">curve25519(k, u)</spanx> function (where <spanx style="verb">k</spanx> is the scalar and <spanx style="verb">u</spanx> is the u-coordinate) first decode <spanx style="verb">k</spanx> and <spanx style="verb">u</spanx> and then perform the following procedure, taken from <xref target="curve25519"/> and based on formulas from <xref target="montgomery"/>. All calculations are performed in GF(p), i.e., they are performed modulo p. The constant a24 is (486662 - 2) / 4 = 121665.</t>
<figure align="center">
<artwork align="left"><![CDATA[
x_1 = u
x_2 = 1
z_2 = 0
x_3 = u
z_3 = 1
swap = 0
For t = 254 down to 0:
k_t = (k >> t) & 1
swap ^= k_t
// Conditional swap; see text below.
(x_2, x_3) = cswap(swap, x_2, x_3)
(z_2, z_3) = cswap(swap, z_2, z_3)
swap = k_t
A = x_2 + z_2
AA = A^2
B = x_2 - z_2
BB = B^2
E = AA - BB
C = x_3 + z_3
D = x_3 - z_3
DA = D * A
CB = C * B
x_3 = (DA + CB)^2
z_3 = x_1 * (DA - CB)^2
x_2 = AA * BB
z_2 = E * (AA + a24 * E)
// Conditional swap; see text below.
(x_2, x_3) = cswap(swap, x_2, x_3)
(z_2, z_3) = cswap(swap, z_2, z_3)
Return x_2 * (z_2^(p - 2))]]></artwork>
</figure>
<t>(TODO: Note the difference in the formula from Montgomery's original paper. See https://www.ietf.org/mail-archive/web/cfrg/current/msg05872.html.)</t>
<t>Finally, encode the resulting value as 32 bytes in little-endian order.</t>
<t>When implementing this procedure, due to the existence of side-channels in commodity hardware, it is important that the pattern of memory accesses and jumps not depend on the values of any of the bits of <spanx style="verb">k</spanx>. It is also important that the arithmetic used not leak information about the integers modulo p (such as having b*c be distinguishable from c*c).</t>
<t>The cswap instruction SHOULD be implemented in constant time (independent of <spanx style="verb">swap</spanx>) as follows:</t>
<figure align="center">
<artwork align="left"><![CDATA[
cswap(swap, x_2, x_3):
dummy = swap * (x_2 - x_3)
x_2 = x_2 - dummy
x_3 = x_3 + dummy
Return (x_2, x_3)]]></artwork>
</figure>
<t>where <spanx style="verb">swap</spanx> is 1 or 0. Alternatively, an implementation MAY use the following:</t>
<figure align="center">
<artwork align="left"><![CDATA[
cswap(swap, x_2, x_3):
dummy = mask(swap) AND (x_2 XOR x_3)
x_2 = x_2 XOR dummy
x_3 = x_3 XOR dummy
Return (x_2, x_3)]]></artwork>
</figure>
<t>where <spanx style="verb">mask(swap)</spanx> is the all-1 or all-0 word of the same length as x_2 and x_3, computed, e.g., as mask(swap) = 1 - swap. The latter version is often more efficient.</t>
<section title="Test vectors">
<figure align="center">
<artwork align="left"><![CDATA[
Input scalar:
a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4
Input scalar as a number (base 10):
31029842492115040904895560451863089656472772604678260265531221036453811406496
Input U-coordinate:
e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c
Input U-coordinate as a number:
34426434033919594451155107781188821651316167215306631574996226621102155684838
Output U-coordinate:
c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552
Input scalar:
4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d
Input scalar as a number (base 10):
35156891815674817266734212754503633747128614016119564763269015315466259359304
Input U-coordinate:
e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493
Input U-coordinate as a number:
8883857351183929894090759386610649319417338800022198945255395922347792736741
Output U-coordinate:
95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957]]></artwork>
</figure>
</section>
</section>
<section title="Diffie-Hellman">
<t>The <spanx style="verb">curve25519</spanx> function can be used in an ECDH protocol as follows:</t>
<t>Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = curve25519(f, 9) to Bob, where 9 is the u-coordinate of the base point and is encoded as a byte with value 9, followed by 31 zero bytes.</t>
<t>Bob similarly generates 32 random bytes in g[0] to g[31] and computes K_B = curve25519(g, 9) and transmits it to Alice.</t>
<t>Alice computes curve25519(f, K_B); Bob computes curve25519(g, K_A) using their generated values and the received input.</t>
<t>Both now share K = curve25519(f, curve25519(g, 9)) = curve25519(g, curve25519(f, 9)) as a shared secret. Alice and Bob can then use a key-derivation function, such as hashing K, to compute a key.</t>
<t>Note that this Diffie-Hellman protocol is not contributory, e.g. if the u-coordinate is zero then the output will always be zero. A contributory Diffie-Hellman function would ensure that the output was unpredictable no matter what the peer's input. This is not a problem for the vast majority of cases but, if a contributory function is specifically required, then <spanx style="verb">curve25519</spanx> should not be used.</t>
<section title="Test vectors">
<figure align="center">
<artwork align="left"><![CDATA[
Alice's private key, f:
77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
Alice's public key, curve25519(f, 9):
8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a
Bob's private key, g:
5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb
Bob's public key, curve25519(g, 9):
de9edb7d7b7dc1b4d35b61c2ece435373f8343c85b78674dadfc7e146f882b4f
Their shared secret, K:
4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742]]></artwork>
</figure>
</section>
</section>
<section title="Acknowledgements">
<t>This document merges <spanx style="verb">draft-black-rpgecc-01</spanx> and <spanx style="verb">draft-turner-thecurve25519function-01</spanx>. The following authors of those documents wrote much of the text and figures but are not listed as authors on this document: Benjamin Black, Joppe W. Bos, Craig Costello, Patrick Longa, Michael Naehrig and Watson Ladd.</t>
<t>The authors would also like to thank Tanja Lange and Rene Struik for their reviews.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- A reference written by by an organization not a person. -->
<reference anchor="Smart">
<front>
<title>The discrete logarithm problem on elliptic curves of trace one</title>
<author fullname="Nigel Smart" initials="N.S." surname="Smart" />
<date year="1999" />
</front>
</reference>
<reference anchor="AS">
<front>
<title>Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves</title>
<author fullname="Takakazu Satoh" initials="T.S." surname="Satoh" />
<author fullname="Kiyomichi Araki" initials="K.A." surname="Araki" />
<date year="1998" />
</front>
</reference>
<reference anchor="S">
<front>
<title>Evaluation of discrete logarithms on some elliptic curves</title>
<author fullname="Igor Semaev" initials="I.S." surname="Semaev" />
<date year="1998" />
</front>
</reference>
<reference anchor="EBP" target="http://www.ecc-brainpool.org/download/Domain-parameters.pdf">
<front>
<title>ECC Brainpool Standard Curves and Curve Generation</title>
<author>
<organization>ECC Brainpool</organization>
</author>
<date day ="19" month="October" year="2005" />
</front>
</reference>
<reference anchor="SC"
target="http://safecurves.cr.yp.to/">
<front>
<title>SafeCurves: choosing safe curves for elliptic-curve cryptography</title>
<author fullname="Daniel J. Bernstein" initials="D.J.B." surname="Bernstein" />
<author fullname="Tanja Lange" initials="T.J." surname="Lange" />
<date day="28" month="June" year="2014" />
</front>
</reference>
<reference anchor="NIST"
target="http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf">
<front>
<title>Recommended Elliptic Curves for Federal Government Use</title>
<author>
<organization>National Institute of Standards</organization>
</author>
<date month="July" year="1999" />
</front>
</reference>
<reference anchor="SEC1"
target="http://www.secg.org/collateral/sec1_final.pdf">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Certicom Research</organization>
</author>
<date day="20" month="September" year="2000" />
</front>
</reference>
<reference anchor="curve25519" target="http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf">
<front>
<title>Curve25519 -- new Diffie-Hellman speed records</title>
<author fullname="Daniel J. Bernstein" initials="D.J." surname="Bernstein"/>
<date year="2006"/>
</front>
</reference>
<reference anchor="montgomery" target="http://www.ams.org/journals/mcom/1987-48-177/S0025-5718-1987-0866113-7/S0025-5718-1987-0866113-7.pdf">
<front>
<title>Speeding the Pollard and elliptic curve methods of factorization</title>
<author fullname="Peter L. Montgomery" initials="P." surname="Montgomery"/>
<date year="1983"/>
</front>
</reference>
<reference anchor="ed25519" target="http://ed25519.cr.yp.to/ed25519-20110926.pdf">
<front>
<title>High-speed high-security signatures</title>
<author fullname="Daniel J. Bernstein" initials="D.J." surname="Bernstein"/>
<author fullname="Niels Duif" initials="N." surname="Duif"/>
<author fullname="Tanja Lange" initials="T." surname="Lange"/>
<author fullname="Peter Schwabe" initials="P." surname="Schwabe"/>
<author fullname="Bo-Yin Yang" initials="B.Y." surname="Yang"/>
<date year="2011"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:26:43 |