One document matched: draft-schmidt-pake-tls-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2629 PUBLIC '' 'reference.RFC.2629.xml'>
<!ENTITY rfc2119 PUBLIC '' 'reference.RFC.2119.xml'>
<!ENTITY rfc6090 PUBLIC '' 'reference.RFC.6090.xml'>
<!ENTITY rfc4013 PUBLIC '' 'reference.RFC.4013.xml'>
<!ENTITY rfc3454 PUBLIC '' 'reference.RFC.3454.xml'>
<!ENTITY rfc4492 PUBLIC '' 'reference.RFC.4492.xml'>
<!ENTITY rfc5246 PUBLIC '' 'reference.RFC.5246.xml'>
<!ENTITY rfc2434 PUBLIC '' 'reference.RFC.2434.xml'>
]>
<rfc category="std" ipr="trust200902" docName="draft-schmidt-pake-tls-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="PAKE in TLS">Using Password-Authenticated Key Agreement (PAKE) schemes in TLS</title>
<author initials="D.K" fullname="Dennis Kügler" surname="Kügler">
<organization>BSI</organization>
<address>
<postal>
<street>Postfach 200363</street>
<city>53133 Bonn</city>
<country>Germany</country>
</postal>
<email>Dennis.Kuegler@bsi.bund.de</email>
</address>
</author>
<author initials="J.-M.S." fullname="Jörn-Marc Schmidt" surname="Schmidt">
<organization>secunet Security Networks</organization>
<address>
<postal>
<street>Mergenthaler Allee 77</street>
<city>65760 Eschborn</city>
<country>Germany</country>
</postal>
<email>joern-marc.schmidt@secunet.com</email>
</address>
</author>
<date/>
<!--<workgroup>Internet Research Task Force</workgroup>-->
<abstract><t> This document describes how to integrate Password-Authenticated Key Agreement (PAKE) schemes into TLS. These schemes enable two parties who share a potentially weak password to derive a common cryptographic key, allowing them to establish a secure channel. The current document defines a generic way to integrate PAKE schemes into TLS. In addition, it demonstrates how to use the well-known Password Authenticated Connection Establishment (PACE) scheme in TLS as an example for the generic construction.
</t></abstract>
</front>
<middle>
<section title="Requirements notation">
<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"/>.</t>
</section>
<section title="Introduction">
<t>Assume two or more parties want to communicate in a protected manner. Using a shared password might be a simple possibility, since it is easy to remember and to transfer, e.g. via phone. However, it does not deliver a strong security, in particular not the level that is provided by a cryptographic key. Password-Authenticated Key Agreement (PAKE) schemes provide a combination of both benefits. They allow the parties to derive a cryptographic key from a password to establish a secure communication. A PAKE scheme uses the password in a way that prevents an adversary from performing a brute-force attack without interaction with a legitimate communication partner. This way, an adversary trying to iterate through all possible passwords is detected and hence such attacks are mitigated. This memo shows how to integrate PAKE schemes into TLS.</t>
<t>As an example of how to use PAKE in TLS, it is shown how to integrate the Password Authenticated Connection Establishment (PACE), a realization of such a PAKE. It is balanced in the sense that both parties possess the same representation of the shared password. It comes with a security proof based on number-theoretic assumptions related to the Diffie-Hellman problem using random oracles and ideal ciphers.</t>
</section>
<section title="PAKE Specification">
<t><!--This memo makes use of several PAKE schemes. Therefore, we first outline the used schemes and their definitions. We start with common definitions before describing the PACE protocol. --><!-- We will move along the lines of RFC-PAKE demonstrating how and to which extend the schemes fulfil the requirements stated there. -->
This section gives a definitions and preliminaries required for PACE and describes the scheme itself. </t>
<section title="Requirements">
<section title="Notation">
<t>The following notation is used in this memo:
<list style="hanging">
<t hangText="A||B:"> Concatenation of the values A and B </t>
</list>
</t>
</section>
<section title="Group Specification">
<t>Most PAKE schemes rely on finite groups. Here, we consider two different groups: (1) groups over finite fields and (2) groups over elliptic curves. They have in common that, using appropriate parameters, the discrete logarithm problem in both groups is hard to solve.
<list style="symbols">
<t>Let p be a prime for which the prime factors of (p-1)/2 are sufficiently large. Let g be a generator of the subgroup of GF(p) with q elements, whereas q is prime.</t>
<t>For elliptic curve cryptography (ECC) this document relies on the definitions and algorithms described in <xref target="RFC6090"/>. In particular, the domain parameters used in this document are a prime p defining the field GF(p). Two elements a,b of GF(p) give the curve equation. All points (x,y) in GF(p)^2 that satisfy the equation y^2=x^3+a*x+b mod p together with the point at infinity build the additive group of the curve, in which the computations are taking place. Furthermore, let G be an element of the EC group that generates a sub-group having a sufficient large prime order q. Over this group, we define the addition of two elements X,Y denoted as X+Y as well as a scalar multiplication k*G as adding k times the point G. Note that irrespective of the description of the curve in Weierstrass form here, other curves can be used as well.</t>
</list>
In the following, if the expressions are valid for both groups, we will use the multiplicative notation, i.e. a*b and a^c, which maps to a+b and c*a for the ECC case.</t>
</section>
<section title="Functions">
<t>In order to describe PACE, this memo makes use of the following cryptographic primitives:
<list style="symbols">
<t>A symmetric block cipher (E,D) that encrypts a message M using a key K with E(K,M) to the chipertext C and decrypts C with D(K,C).</t>
<t>A hash-function (H) that maps an arbitrary input X to a fixed-sized output Y=H(X).</t>
<t>A MAC-function (MAC) that generates an authentication tag T for the message M using the key K by T=MAC(K,M).</t>
</list>
Note that the algorithms that realized these primitives are given together with the identifier of the used PAKE scheme in our construction.</t>
<t>In addition, a function Hash2Point that maps from a random bit string to a point, either in the finite field or on the elliptic curve, is chosen. How this function operates depends on the used parameters:
<list style="hanging">
<t hangText="Finite Field:">In order to map a bit string S to a point m in a finite field GF(p), its hash is computed. This hash is mapped into a group of size q: m = (H(S))^((p-1)/q) mod p. Note that it MUST be verified, that m > 1 holds.</t>
<t hangText="Weierstrass Curve:">Weierstrass curves with the equation y^2=x^3+a*x+b mod p can use the map defined by Shallue, Woestijne <xref target="SW2006"/> and Ulas <xref target="U2007"/>. They showed that, defining g(u) = x^3+a*x+b, for at least one of the values x1(t,u)=u, x2(t,u)=-(b/a)*(1+1/(t^2*g(u)^2+t*g(u))) and x3(t,u)=t^3*g(u)^3*x2(t,u) exists an y with g(xi) = y^2 mod p. Based on this map, the Hash2Point function is defined. Let u be the smallest value such that no y with y^2=g(u) exists. Values of u and g(u) for different curves are given in <xref target="u_values"/>. Let sqrt(x) denote the square root of the element x. In case p= 3 mod 4, sqrt(x)=x^((p+1)/4). The Hash2Point function for a string S is defined as Hash2Point(S) = (x2(H(S),u),sqrt(g(x2(H(S),u))) if g(x2(H(S),u))^((p+1)/2) =g(x2(H(S),u))^2 else (x3(H(S),u),sqrt(g(x3(H(S),u)))).
Note that in order to achieve a constant time implementation, both points have to be computed.</t>
<t hangText="Curve25519:">For curves y^2=x^3+a*x^2+b*x mod p with a*b*(a^2-4b) not null, Elligator2 <xref target="BHKL2013"/> as defined by Bernstein et al. is used as Hash2Point function. Let |y|=y if 0<y<(p-1)/2 and |y|=-y otherwise. In order to compute the map, a square root function, sqrt(x), is defined. Since p=5 mod 8 holds for Curve25519, let h = x^(p+3)/8, sqrt(x) = |h| if b^4=a^2 and sqrt(x)=|sqrt(-1)*h| otherwise. A bit string S is first mapped to GF(p), the underlying prime field by m = H(S) mod p. Subsequently, v=-a/(1+2*m^2), e=(v^3+a*v^2+b*v)^((q-1)/2), x =e*v-(1-e)*a/2 mod p, y = -e*sqrt(x^3+a*x^2+b*x) mod p are computed. The result of Hash2Point(S) is P=(x,y).</t>
</list>
</t>
<texttable anchor="u_values" title="Values of u and g(u) for different Weierstrass curves.">
<ttcol align='center'>Name</ttcol>
<ttcol align='center'>u</ttcol>
<ttcol align='center'>g(u)</ttcol>
<c>secp256r1</c>
<c>1</c>
<c>0x5ac635d8aa3a93e7 b3ebbd55769886bc 651d06b0cc53b0f6 3bce3c3e27d26049</c>
<c>secp384r1</c>
<c>1</c>
<c>0xb3312fa7e23ee7e4 988e056be3f82d19 181d9c6efe814112 0314088f5013875a c656398d8a2ed19d 2a85c8edd3ec2aed</c>
<c>secp521r1</c>
<c>3</c>
<c>0x51953eb9618e1c9a 1f929a21a0b68540 eea2da725b99b315 f3b8b489918ef109 e156193951ec7e93 7b1652c0bd3bb1bf 073573df883d2c34 f1ef451fd46b503f 12</c>
<c>brainpoolP256r1</c>
<c>0</c>
<c>0x26dc5c6ce94a4b44 f330b5d9bbd77cbf 958416295cf7e1ce 6bccdc18ff8c07b6</c>
<c>brainpoolP384r1</c>
<c>0</c>
<c>0x04a8c7dd22ce2826 8b39b55416f0447c 2fb77de107dcd2a6 2e880ea53eeb62d5 7cb4390295dbc994 3ab78696fa504c11</c>
<c>brainpoolP512r1</c>
<c>0</c>
<c>0x3df91610a83441ca ea9863bc2ded5d5a a8253aa10a2ef1c9 8b9ac8b57f1117a7 2bf2c7b9e7c1ac4d 77fc94cadc083e67 984050b75ebae5dd 2809bd638016f723</c>
</texttable>
</section>
</section>
<section title="PACE">
<t>PACE is a balanced PAKE scheme that is used for e.g. travel documents <xref target="BFK2009" />. In a nutshell, a nonce is generated by the initiating party and send, encrypted with the (hash of) the shared password, to the second party. The possession of the correct password is proven by the ability to encrypt and decrypt the nonce. The parties generate jointly, based on the nonce, a group for a Diffie-Hellman key agreement. Finally, the encryption and authentication keys are derived from the Diffie-Hellman key.</t>
<t>The precondition for the execution of PACE is that both parties share a password. If the domain parameters are not agreed beforehand, the initializing party can send (a set of) supported parameter together with the nonce in the first message, the choice can be done by the second party by reflecting the parameters to use. Hence, we assume that Alice and Bob share a finite group, i.e. a finite field or domain parameters for an elliptic curve, its generator g with order q. All following computations are performed in this group.
<list style="hanging">
<t hangText="A->B:"> Alice selects a random integer s with a fixed bit-length (in practice it has to be a multiple of the block-length of the symmetric cipher) and encrypts it using the shared password PW. Alice sends E(PW,s) together with the domain parameters to Bob.</t>
<t hangText="B->A:">Bob decrypts s, selects a random integer t and derives g' = Hash2Point(s||t). Moreover, Bob chooses y_b<q and computes Y_b = (g')^y_b. Bob sends t and Y_b to Alice.</t>
<t hangText="A->B:">Alice verifies that Y_b is a valid not-null element of the specified group, and derives g' = Hash2Point(s||t). Alice chooses y_a<q and computes Y_a=(g')^y_a. Afterwards, Alice derives K=Y_b^y_a and computes an encryption key K_enc= H(K||1), a mac key K_mac(K||2), as well as MAC key for the verification tag K_tag=H(K||3). Alice computes T_a = MAC(K_tag,(Y_b||g')) and sends Y_a and T_a to Bob.</t>
<t hangText="B->A:">Bob verifies that Y_a is a valid element in the group and especially is not null. Using Y_a and y_b, Bob computes the shared key K=Y_a^y_b and derives the encryption key K_enc= H(K||1), the mac key K_mac(K||2), as well as MAC key for the verification tag K_tag=H(K||3). Using these keys, Bob verifies T_a. If T_a is valid, Bob computes T_b=MAC(K_tag,(Y_a||g')) and sends T_b to Alice.</t>
<t hangText="A:">Alice verifies T_b. If T_b is valid, Alice and Bob can use the shared keys K_enc and K_mac to establish a secured channel. </t>
</list>
After performing this protocol, both parties share a secret key that can be used for further communication.</t>
<section title="Performance">
<t>Key agreement using PACE requires exchanging 2 messages from Alice to Bob and 2 responses. This makes PACE a 2-round protocol. The sizes of the messages are defined by the domain parameters: The first message contains the encrypted nonce and possibly domain parameters. Bobs response contains a group element. Alice and Bob require the selection of 2 random variables, each. Both perform 2 exponentiations and one evaluation of Hash2Point. </t>
</section>
</section>
<section title="Handling PAKE Passwords">
<t>The passwords that are used in the PAKE schemes can be stored plain or protected either by hashing them or even using a salt with the hash. Furthermore, in case an augmented PAKE scheme is used, the representation of the password of the client and the server differs.</t>
</section>
</section>
<section title="PAKE Integration in TLS">
<t>In order to integrate PAKE schemes into TLS, the Hello Messages and the KeyExchange Messages have to be adapted. The client sends an additional extension with the ClientHello message in order to initiate a key-exchange using a PAKE. Furthermore, the extension may contain details to the desired PAKE like the identity of the client, the desired group parameters, and potential nonces. We show how to integrate a PAKE scheme using the example of PACE.</t>
<section title="Changes in ClientHello" anchor="ClientHello">
<t>The client notifies the Server with the ClientHallo messages that a PAKE scheme should be used for the key-agreement and sends a list of supported schemes. This is done by an extension of the Hello message. Moreover, the extension contains the information on the identity of the client and furthermore which set of schemes is supported.</t>
<figure>
<artwork>
enum{PAKE(TBD1)} ExtensionType;
struct{
opaque ClientName <1..2^8-1>
enum{PACE_AES128_SHA256(TBD2),
PACE_ECC_AES128_SHA256(TBD3),
} PAKEType;
} PAKEParams;
</artwork>
</figure>
<t>The parameter ClientName in the extension is used by the server to identify the client and determine which password to use for further messages. The ClientName
SHALL be a UTF-8 encoded character string processed according to the <xref target="RFC4013"/> profile of <xref target="RFC3454"/>. The PAKEType parameter defines which PAKE is supported by the client.</t>
<t> In case all requested PAKEs are unknown to the server or the requested domain parameters do not fit the expected ones, the server shall respond with an unknown cipher error. In case the supplied ClientName is unknown, the server should keep running the protocol using random elements that fit the expected answers and reject the TLS clients finished by sending a bad_record_mac alert.</t>
<section title="ClientHello for PACE_AES128_SHA256 / PACE_ECC_AES128_SHA256">
<t>The PAKEType PACE_AES128_SHA256 / PACE_ECC_AES128_SHA256 defines PACE using a finite field / an elliptic curve. As block cipher, AES128 is used, as MAC function an HMAC with SHA256.</t>
<t>Note that the client indicates whether a finite field, an elliptic curve or both can be used for PACE. In case ECC is supported, the client can further specify the supported curves and the point format by the Supported Elliptic Curves and Supported Point Formats extensions as defined in <xref target="RFC4492"/>. The selection of the used parameter set is done by the server.</t>
</section>
</section>
<section title="Changes in ServerKeyExchange">
<t>The ServerKeyExchange message contains the response of the server to the PAKE request in the ClientHello message.
The response should reflect one of the PAKEs supported by the client and send an appropriate answer back to the client.</t>
<figure>
<artwork>
enum{PACE_AES128_SHA256(TBD2),
PACE_ECC_AES128_SHA256(TBD3)} KeyExchangeAlgorithm;
struct {
opaque p<1..2^16-1>
opaque g<1..2^16-1>
opaque q<1..2^16-1>
opaque t[16];
opaque Y_s<1..2^16-1>
}PACE_parameters
struct {
ECParameters elliptic_curve;
opaque t[16];
ECPoint Y_s;
}PACE_ECC_parameters
struct {
select (KeyExchangeAlgorithm)
case PACE_AES128_SHA256:
opaque PACE_parameters;
case PACE_ECC_AES128_SHA256:
opaque PACE_ECC_parameters;
} ServerKeyExchange;
</artwork></figure>
<section title="ServerKeyExchange for PACE_AES128_SHA256">
<t>Upon reception of the ClientHello Message with PAKEType PACE_AES128_SHA256, the server selects appropriate domain parameters, i.e. a prime p and a generator g with order q. The server looks up the password corresponding to the ClientName sent and uses it to decrypt the first 16 bytes of the ClientRandom variable to s. Note that the ClientRandom is interpreted an encrypted value even though it was randomly selected by the client. This spares the parties from exchanging an additional nonce. The server furthermore selects two random numbers t < 2^128 and y_s < q and computes g'= Hash2Point(s||t) and verifies g' > 1. Otherwise, the server repeats the selection of t. The server computes Y_s=(g')^y_s mod p and answers by reflecting PACE_AES128_SHA256 as KeyExchangeAlgorithm and sending the values p, g, t and Y_s to the client.</t>
</section>
<section title="ServerKeyExchange for PACE_ECC_AES128_SHA256">
<t>Upon reception of the ClientHello Message with PAKEType PACE_ECC_AES128_SHA256, the server selects appropriate domain parameters. If the client sent the Supported Elliptic Curves and/or Supported Point Formats extension, the server MUST select one of the supported parameters. The server looks up the password corresponding to the ClientName sent and uses it to decrypt the first 16 bytes of the ClientRandom variable to s. Note that the ClientRandom is interpreted an encrypted value even though it was randomly selected by the client. This spares the parties from exchanging an additional nonce. The server furthermore selects two random numbers t<2^128 and y_s<q, computes G'= Hash2Point(s||t) and verifies that G' is not in a small subgroup for curves with cofactor > 1. In case this check fails, the server repeats the selection of t. Afterwards, the server computes Y_s=y_s*G'. The server answers by reflecting PACE_ECC_AES128_SHA256 as KeyExchangeAlgorithm and sending the domain parameters together with t and Y_s, encoded a ECPoint as defined in <xref target="RFC4492"/> to the client.</t>
</section>
</section>
<section title="Changes in ClientKeyExchange">
<t> The ClientKeyExchange message finalizes the key exchange.</t>
<figure>
<artwork>
struct {
select (PAKEType)
case PACE_AES128_SHA256: opaque Y_c<1..2^16-1>
case PACE_ECC_AES128_SHA256: ECPoint Y_c;
} ClientKeyPAKEParams;
</artwork></figure>
<section title="ClientKeyExchange for PACE_AES128_SHA256">
<t>Upon reception of the ServerKeyExchange Message with KeyExchangeAlgorithm PACE_AES128_SHA256, the client verifies the received parameters. In particular, it verifies that the domain parameters are valid and that Y_s is a not-null element of GF(p). After successful verification, the client uses the shared password to derive s from the first 16 Bytes of the ClientRandom value sent to the server in the ClientHello message. The client selects a random number y_c < q, computes g'= Hash2Point(s||t), verifies g' > 1 and computes Y_c = g'^y_c mod p as well as K = Y_s^y_c mod p. In case g' = 0 or g' = 1, the client SHALL NOT immediately report an error but use a random g' for all further computations and reject the server's Finished message. The client send Y_c to the server, which also derives K=Y_c^y_s mod p after validation of Y_c. Both parties now use the shared value K to derive an encryption key K_enc = H(K||1), a MAC key K_mac=H(K||2), as well as MAC key for the verification tag K_tag=H(K||3). The validation tag of the client is T_c=MAC(K_tag,"PACE_AES128_SHA256"||Y_c) and for the server T_s=MAC(K_tag,"PACE_AES128_SHA256"||Y_s).</t>
</section>
<section title="ClientKeyExchange for PACE_ECC_AES128_SHA256">
<t>Upon reception of the ServerKeyExchange Message with KeyExchangeAlgorithm PACE_ECC_AES128_SHA256, the client verifies the received parameters. In particular, it verifies the domain parameters and that Y_s is an element of the specified curve and is not equal to the point at infinity. After successful verification, the client uses the shared password to derive s from the first 16 Bytes of the ClientRandom value sent to the server in the ClientHello message. The client computes G'= Hash2Point(s||t) and verifies that G' is not in a small subgroup for curves with cofactor > 1. In case this check fails, the client SHALL NOT immediately report an error but use a random G' for all further computations and reject the server's Finished message. After successful verification, the client selects a random number y_c<q and and computes K=y_c*Y_s. The client sends Y_c, encoded a ECPoint as defined in <xref target="RFC4492"/>, to the server, which also derives K=y_s*Y_c after validation of Y_c. Both parties now use the x-coordinate of the shared value K denoted as K_x to derive an encryption key K_enc = H(K_x||1), a MAC key K_mac=H(K_x||2), as well as MAC key for the verification tag K_tag=H(K_x||3). The validation tag of the client is T_c=MAC(K_tag,"PACE_ECC_AES128_SHA256"||Y_c) and for the server T_s=MAC(K_tag,"PACE_ECC_AES128_SHA256"||Y_s).</t>
</section>
</section>
<section title="Finished">
<t>
The Finished messages contain the verification tags to proof that both sides derived the same cryptographic keys. In particular, the tags T_c and T_s are exchanged. After verification of the received tags, both parties are ready to establish a secure channel for application data.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document request IANA to assign a new value for TLS extension type from the TLS ExtensionType Registry defined in <xref target="RFC5246"/> with the name "PAKE" and the number TBD1. </t>
<t>In addition, this document defines a new registry to be maintained by IANA:
<list style="hanging">
<t hangText="TLS PAKEType: "> The registry is initially populated with the values described in <xref target="ClientHello"/>. Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action <xref target="RFC2434"/>. Values in the range 64-223 (decimal) inclusive are assigned via Specification Required <xref target="RFC2434"/>. Values from 224-255 (decimal) inclusive are reserved for Private Use <xref target="RFC2434"/>.</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>Overall, the PAKE schemes defined here preserves the structure of the TLS Handshake protocol and hence the security arguments of TLS after key-agreement carry over. The security of PAKE is discussed below.</t>
<section title="Security and Limitations of PAKE Schemes">
<t>This memo does not make any assumptions about the strength of the shared credential, i.e. the password; best practices like a sufficient password length and use of multiple character classes SHOULD be followed. Nevertheless, an adversary can perform a dictionary attack enumerating all possible passwords. In order to prevent such attacks, implementations MUST include protection mechanisms like restricting the allowed password attempts or even locking out identities after a specific number of failed tries. Please note that this holds for server and client implementations in equal measure.</t>
<t>For using PAKE schemes, storing the password in plain is not required. Both parties SHOULD use a hashed version of it. In case of an augmented PAKE, the server key SHOULD be derived from the hashed password.</t>
</section>
<section title="Security of the discussed PACE scheme">
<t><!--The extension for TLS defined in this memo uses the message-flow from the definition of the used PAKE, no changes regarding the message content or message flow is made. Hence, the security of the defined extension is based on the used PAKE and directly carries over from the security of the underlying scheme.
<list style="hanging">
<t hangText="PACE:"> -->In <xref target="BFK2009" />, Bender et al. show the security of the PACE scheme in the model of Bellare et al. <xref target="BPR2000" />. Their proof makes use of ideal ciphers and random oracles, i.e., idealized hash functions. In practice, the security of this scheme relies on the quality of the used randomness. In particular, if the nonce is not chosen in an uniform way, an adversary might use this information to compromise the password. Hence, using a strong pseudo random function to the raw random material in order to ensure the statistical quality of the random data is RECOMMENDED.</t>
<!--</list>
</t>-->
</section>
</section>
</middle>
<back>
<references title='Normative References'>&rfc2119;&rfc6090;&rfc4013;&rfc3454;&rfc4492;&rfc5246;&rfc2434;
</references>
<references title='Informative References'>
<reference anchor="BFK2009">
<front>
<title>Security Analysis of the PACE Key-Agreement Protocol</title>
<author initials ="J.B." fullname='Jens Bender' surname="Bender"/>
<author initials ="M.F." fullname='Marc Fischlin' surname="Fischlin"/>
<author initials ="D.K." fullname='Dennis Kügler' surname="Kügler"/>
<date year="2009"/>
</front>
<seriesInfo name="ISC" value="2009"/>
<seriesInfo name="LNCS" value="5735"/></reference>
<reference anchor="BPR2000">
<front>
<title>Authenticated Key Exchange Secure against Dictionary Attacks</title>
<author initials ="M.B." fullname='Mihir Bellare' surname="Bellare"/>
<author initials ="D.P." fullname='David Pointcheval' surname="Pointcheval"/>
<author initials ="P.R." fullname='Phillip Rogaway' surname="Rogaway"/>
<date year="2000"/>
</front>
<seriesInfo name="Euorcrypt" value="2000"/>
<seriesInfo name="LNCS" value="1807"/></reference>
<reference anchor="BHKL2013">
<front>
<title>Elligator: Elliptic-curve points indistinguishable from uniform random strings</title>
<author initials ="D.J.B." fullname='Daniel J. Bernstein' surname="Bernstein"/>
<author initials ="M.H." fullname='Mike Hamburg' surname="Hamburg"/>
<author initials ="A.K." fullname='Anna Krasnova' surname="Krasnova"/>
<author initials ="T.L." fullname='Tanja Lange' surname="Lange"/>
<date year="2013"/>
</front>
<seriesInfo name=" ACM CCS" value="2013"/>
</reference>
<reference anchor="SW2006">
<front>
<title>Construction of Rational Point on Elliptic Curves over Finite Fields</title>
<author initials ="A.S." fullname='Andrew Shallue' surname="Shallue"/>
<author initials ="C.E.W." fullname='Christiaan E. van de Woestijne' surname="Woestijne"/>
<date year="2006"/>
</front>
<seriesInfo name="ANTS" value="2006"/>
<seriesInfo name="LNCS" value="4076"/>
</reference>
<reference anchor="U2007">
<front>
<title>Rational Points on certain Hyperelliptic Curves over Finite Fields</title>
<author initials ="M.U." fullname='Maciej Ulas' surname="Ulas"/>
<date year="2007"/>
</front>
<seriesInfo name="arXiv" value="0706.1448"/>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:38:58 |