CPace enables balanced password-authenticated key establishment. CPace requires a shared secret octet string, the password-related string (PRS) available to both parties A and B. PRS can be a low-entropy secret itself, for instance a clear-text password encoded according to [RFC8265], or any string derived from a common secret, for instance by use of a key derivation function.¶
-Applications with clients and servers where the server side is storing account and password information in its persistent memory are recommended to use augmented PAKE protocols such as OPAQUE [I-D.irtf-cfrg-opaque].¶
+CPace enables balanced password-authenticated key establishment. I.e. with CPace the parties start the protocol with a shared secret octet string, namely the password-related string (PRS). +PRS can be a low-entropy secret itself, for instance a clear-text password encoded according to [RFC8265], or any string derived from a common secret, for instance by use of a key derivation function.¶
+Applications with clients and servers where the server side is storing account and password information in its persistent memory are recommended to use augmented +PAKE protocols such as OPAQUE [I-D.irtf-cfrg-opaque].¶
In the course of the CPace protocol, A sends one message to B and B sends one message to A. CPace does not mandate any ordering of these two messages. We use the term "initiator-responder" for CPace where A always speaks first, and the term "symmetric" setting where anyone can speak first.¶
-CPace's output is an intermediate session key (ISK), but any party might abort in case of an invalid received message. A and B will produce the same ISK value only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS and the same value for the optional input parameters CI, ADa, ADb and sid that will be specified in the upcoming sections.¶
+CPace's output is an intermediate session key (ISK), but any party might abort in case of an invalid received message. A and B will produce the same ISK value if and only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS and the same value for the optional input parameters CI, ADa, ADb and sid that will be specified in section Section 3.1.¶
The naming of ISK as "intermediate" session key highlights the fact that it is RECOMMENDED that applications process ISK by use of a suitable strong key derivation function KDF (such as defined in [RFC5869]) before using the key in a higher-level protocol.¶
-prepend_len(octet_string) denotes the octet sequence that is obtained from prepending -the length of the octet string to the string itself. The length shall be prepended by using an LEB128 encoding of the length. -Test vectors and reference implementations for prepend_len are given in the appendix.¶
+the length of the octet string to the string itself. The length is encoded using LEB128. +Test vectors and code for prepend_len are available in the appendix.¶lv_cat(a0,a1, ...) is the "length-value" encoding function which returns the concatenation of the input strings with an encoding of @@ -1966,9 +1968,11 @@
CPace is a one round protocol between two parties, A and B. At invocation, A and B are provisioned with PRS,G,H and OPTIONAL CI,sid,ADa (for A) and CI,sid,ADb (for B). -A sends the public share Ya and OPTIONAL associated data ADa (i.e., an ADa field that MAY have a length of 0 bytes) to B. -Likewise, B sends the public share Yb and OPTIONAL associated data ADb (i.e., an ADb field that MAY have a length of 0 bytes). +
CPace is a one round protocol between two parties, A and B. At invocation, A and B are provisioned with PRS,G and H. +Parties will also be provisioned with OPTIONAL CI,sid,ADa (for A) and CI,sid,ADb (for B) which will default to the empty +string b"" if not used. +A sends the public share Ya and optional associated data ADa to B. +Likewise, B sends the public share Yb and optional associated data ADb to A. Both A and B use the received messages for deriving a shared intermediate session key, ISK.¶
The zero padding of length len_zpad is designed such that the encoding of DSI and PRS together with the zero padding field completely fills at least the first input block (of length s_in_bytes) of the hash. -As a result for the common case of short PRS the number of bytes to hash becomes independent of the actual length of the password (PRS). (A reference implementation and test vectors are provided in the appendix.)¶
+As a result for the common case of short PRS the number of bytes to hash becomes independent of the actual length of the password (PRS). (Code and test vectors are provided in the appendix.)¶The introduction of a zero-padding within the generator string also helps mitigating attacks of a side-channel adversary that analyzes correlations between publicly known variable information with a short low-entropy PRS string. Note that the hash of the first block is intentionally made independent of session-specific inputs, such as sid or CI and that there is no limitation @@ -2341,7 +2345,8 @@
Otherwise G.scalar_mult_vfy(s,X) SHALL return the result of the ECSVDP-DH procedure from [IEEE1363] (section 7.2.1). I.e. it shall -either return "error" (in case that s*X is the neutral element) or the secret shared value "z" (otherwise). "z" SHALL be encoded by using +either return "error" (in case that s*X is the neutral element) or the secret shared value "z" defined in [IEEE1363] (otherwise). +"z" SHALL be encoded by using the big-endian encoding of the x-coordinate of the result point s*X according to [SEC1].¶
For curves over fields F_q where q is a prime close to a power of two, we recommend sampling scalars as a uniform bit string of length field_size_bits. We do so in order to reduce both, complexity of the implementation and the attack surface with respect to side-channels for embedded systems in hostile environments. -The effect of non-uniform sampling on security was demonstrated to be benign in [AHH21] for the case of Curve25519 and Curve448. +[AHH21] demonstrated that non-uniform sampling did not negatively impact security for the case of Curve25519 and Curve448. This analysis however does not transfer to most curves in Short-Weierstrass form.¶
As a result, we recommend rejection sampling if G is as in Section 7.4. Alternatively an algorithm designed along the lines of the hash_to_field() function from [RFC9380] can also be used. There, oversampling to an integer significantly larger than the curve order is followed by a modular reduction to the group order.¶
@@ -2531,7 +2536,7 @@The curve has order (p * c) with p prime and c a small cofactor. Also the curve's quadratic twist must be of order (p' * c') with p' prime and c' a cofactor.¶
The cofactor c of the curve MUST BE EQUAL to or an integer multiple of the cofactor c' of the curve's quadratic twist. Also, importantly, the +
The cofactor c of the curve MUST BE equal to or an integer multiple of the cofactor c' of the curve's quadratic twist. Also, importantly, the implementation of the scalar_mult and scalar_mult_vfy functions must ensure that all scalars actually used for the group operation are integer multiples of c (e.g. such as asserted by the specification of the decodeScalar functions in [RFC7748]).¶
diff --git a/draft-irtf-cfrg-cpace.txt b/draft-irtf-cfrg-cpace.txt index fced0bb..6283e7c 100644 --- a/draft-irtf-cfrg-cpace.txt +++ b/draft-irtf-cfrg-cpace.txt @@ -293,15 +293,15 @@ Table of Contents 3. High-level application perspective CPace enables balanced password-authenticated key establishment. - CPace requires a shared secret octet string, the password-related - string (PRS) available to both parties A and B. PRS can be a low- - entropy secret itself, for instance a clear-text password encoded + I.e. with CPace the parties start the protocol with a shared secret + octet string, namely the password-related string (PRS). PRS can be a + low-entropy secret itself, for instance a clear-text password encoded according to [RFC8265], or any string derived from a common secret, for instance by use of a key derivation function. Applications with clients and servers where the server side is storing account and password information in its persistent memory are - recommended to use augmented PAKE protocols such as OPAQUE + recommended to use _augmented_ PAKE protocols such as OPAQUE [I-D.irtf-cfrg-opaque]. In the course of the CPace protocol, A sends one message to B and B @@ -312,10 +312,10 @@ Table of Contents CPace's output is an intermediate session key (ISK), but any party might abort in case of an invalid received message. A and B will - produce the same ISK value only if both sides did initiate the + produce the same ISK value if and only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS and the same value for the optional input parameters CI, ADa, ADb and - sid that will be specified in the upcoming sections. + sid that will be specified in section Section 3.1. The naming of ISK as "intermediate" session key highlights the fact that it is RECOMMENDED that applications process ISK by use of a @@ -548,9 +548,8 @@ Table of Contents * prepend_len(octet_string) denotes the octet sequence that is obtained from prepending the length of the octet string to the - string itself. The length shall be prepended by using an LEB128 - encoding of the length. Test vectors and reference - implementations for prepend_len are given in the appendix. + string itself. The length is encoded using LEB128. Test vectors + and code for prepend_len are available in the appendix. * lv_cat(a0,a1, ...) is the "length-value" encoding function which returns the concatenation of the input strings with an encoding of @@ -589,13 +588,13 @@ Table of Contents 6. The CPace protocol CPace is a one round protocol between two parties, A and B. At - invocation, A and B are provisioned with PRS,G,H and OPTIONAL - CI,sid,ADa (for A) and CI,sid,ADb (for B). A sends the public share - Ya and OPTIONAL associated data ADa (i.e., an ADa field that MAY have - a length of 0 bytes) to B. Likewise, B sends the public share Yb and - OPTIONAL associated data ADb (i.e., an ADb field that MAY have a - length of 0 bytes). Both A and B use the received messages for - deriving a shared intermediate session key, ISK. + invocation, A and B are provisioned with PRS,G and H. Parties will + also be provisioned with OPTIONAL CI,sid,ADa (for A) and CI,sid,ADb + (for B) which will default to the empty string b"" if not used. A + sends the public share Ya and optional associated data ADa to B. + Likewise, B sends the public share Yb and optional associated data + ADb to A. Both A and B use the received messages for deriving a + shared intermediate session key, ISK. 6.1. Protocol flow @@ -659,8 +658,8 @@ Table of Contents completely fills at least the first input block (of length s_in_bytes) of the hash. As a result for the common case of short PRS the number of bytes to hash becomes independent of the actual - length of the password (PRS). (A reference implementation and test - vectors are provided in the appendix.) + length of the password (PRS). (Code and test vectors are provided in + the appendix.) The introduction of a zero-padding within the generator string also helps mitigating attacks of a side-channel adversary that analyzes @@ -982,9 +981,10 @@ Table of Contents - Otherwise G.scalar_mult_vfy(s,X) SHALL return the result of the ECSVDP-DH procedure from [IEEE1363] (section 7.2.1). I.e. it shall either return "error" (in case that s*X is the neutral - element) or the secret shared value "z" (otherwise). "z" SHALL - be encoded by using the big-endian encoding of the x-coordinate - of the result point s*X according to [SEC1]. + element) or the secret shared value "z" defined in [IEEE1363] + (otherwise). "z" SHALL be encoded by using the big-endian + encoding of the x-coordinate of the result point s*X according + to [SEC1]. * We represent the neutral element G.I by using the representation of the "error" result case from [IEEE1363] as used in the @@ -1172,10 +1172,10 @@ Table of Contents two, we recommend sampling scalars as a uniform bit string of length field_size_bits. We do so in order to reduce both, complexity of the implementation and the attack surface with respect to side-channels - for embedded systems in hostile environments. The effect of non- - uniform sampling on security was demonstrated to be benign in [AHH21] - for the case of Curve25519 and Curve448. This analysis however does - not transfer to most curves in Short-Weierstrass form. + for embedded systems in hostile environments. [AHH21] demonstrated + that non-uniform sampling did not negatively impact security for the + case of Curve25519 and Curve448. This analysis however does not + transfer to most curves in Short-Weierstrass form. As a result, we recommend rejection sampling if G is as in Section 7.4. Alternatively an algorithm designed along the lines of @@ -1194,7 +1194,7 @@ Table of Contents Also the curve's quadratic twist must be of order (p' * c') with p' prime and c' a cofactor. - * The cofactor c of the curve MUST BE EQUAL to or an integer + * The cofactor c of the curve MUST BE equal to or an integer multiple of the cofactor c' of the curve's quadratic twist. Also, importantly, the implementation of the scalar_mult and scalar_mult_vfy functions must ensure that all scalars actually