From 2d8c0e84b1e9d9fa1665df13ee88ab7c4c55553f Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Tue, 14 May 2024 15:59:04 +0200 Subject: [PATCH] Make KEM ciphertext integrity (MAC) optional when unlinkability is not needed --- draft-bradleylundberg-cfrg-arkg.md | 519 ++++++++++++++++++++--------- 1 file changed, 370 insertions(+), 149 deletions(-) diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index 4dc5319..41f74bb 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -280,18 +280,14 @@ The parameters of an ARKG instance are: and a domain separation parameter `info`. `info` is an opaque octet string of arbitrary length. + Implementations MAY ignore the domain separation parameter `info`. + Output consists of the shared secret `k` on success, or an error otherwise. `k` and `c` are opaque octet strings. The representation of `pk` is defined by the protocol that invokes ARKG. The representation of `sk` is an undefined implementation detail. - The KEM MUST guarantee integrity of the ciphertext, - meaning that knowledge of the public key `pk` and the domain separation parameter `info` - is required in order to create any ciphertext `c` that can be successfully decapsulated by the corresponding private key `sk`. - {{hmac-kem}} describes a general formula for how any KEM can be adapted to include this guarantee. - {{design-rationale-mac}} discusses the reasons for this requirement. - See [Wilson] for definitions of additional security properties required of the key encapsulation mechanism `KEM`. A concrete ARKG instantiation MUST specify the instantiation @@ -432,7 +428,7 @@ ARKG instantiations SHOULD be chosen in a way that such errors are impossible if `kh` was generated by an honest and correct implementation of `ARKG-Derive-Public-Key`. Incorrect or malicious implementations of `ARKG-Derive-Public-Key` do not degrade the security of a correct and honest implementation of `ARKG-Derive-Private-Key`. -See also {{design-rationale-mac}}. +See also {{arkg-seed-id}} and {{arkg-seed-correlation}}. # Generic ARKG instantiations @@ -499,11 +495,109 @@ BL-Blind-Private-Key(sk, tau, info) -> sk_tau ~~~ -## Using HMAC to adapt a KEM without integrity protection {#hmac-kem} +## Using ECDH as the KEM {#kem-ecdh} + +Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism `KEM` [Frymann2020] [Wilson]. +This section defines a general formula for such instantiations of `KEM`. + +This formula has the following parameters: + +- `crv`: an elliptic curve valid for use with ECDH [RFC6090]. + +The `KEM` parameter of ARKG may be instantiated as follows: + +- `Elliptic-Curve-Point-to-Octet-String` and `Octet-String-to-Elliptic-Curve-Point` + are the conversion routines defined in sections 2.3.3 and 2.3.4 of [SEC1]. + +- `ECDH(pk, sk)` represents the compact output of ECDH [RFC6090] + using public key (curve point) `pk` and private key (exponent) `sk`. + +- `G` is the generator of the prime order subgroup of `crv`. +- `N` is the order of `G`. + +~~~pseudocode +Kem-Generate-Keypair() -> (pk, sk) + + Generate (pk, sk) using some procedure defined for crv. + + +Kem-Encaps(pk, info) -> (k, c) + + (pk', sk') = Kem-Generate-Keypair() + + k = ECDH(pk, sk') + c = Elliptic-Curve-Point-to-Octet-String(pk') + + +Kem-Decaps(sk, c, info) -> k + + pk' = Octet-String-to-Elliptic-Curve-Point(c) + k = ECDH(pk', sk) +~~~ + + +## Using X25519 or X448 as the KEM {#kem-x25519-x448} + +Instantiations of ARKG can use X25519 or X448 [RFC7748] as the key encapsulation mechanism `KEM`. +This section defines a general formula for such instantiations of `KEM`. + +This formula has the following parameters: + +- `DH-Function`: the function X25519 or the function X448 [RFC7748]. + +The `KEM` parameter of ARKG may be instantiated as follows: + +- `Random-Bytes(N)` represents a cryptographically secure, + uniformly distributed random octet string of length `N`. +- `L` is 32 if `DH-Function` is X25519, or 56 if `DH-Function` is X448. +- `G` is the octet string `h'0900000000000000 0000000000000000 0000000000000000 0000000000000000'` + if `DH-Function` is X25519, + or the octet string `h'0500000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000'` + if `DH-Function` is X448. + + These are the little-endian encodings of the integers 9 and 5, + which is the u-coordinate of the generator point of the respective curve group. + +~~~pseudocode +Kem-Generate-Keypair() -> (pk, sk) + + sk = Random-Bytes(L) + pk = DH-Function(sk, G) + + +Kem-Encaps(pk, info) -> (k, c) + + (pk', sk') = Kem-Generate-Keypair() + + k = DH-Function(sk', pk) + c = pk' + + +Kem-Decaps(sk, c, info) -> k + + k = DH-Function(sk, c) +~~~ + + +## Using the same key for both key blinding and KEM {#blinding-kem-same-key} -Not all key encapsulation mechanisms guarantee ciphertext integrity, -meaning that a valid KEM ciphertext can be created only with knowledge of the KEM public key. -This section defines a general formula for adapting any KEM to include integrity protection +When an ARKG instance uses the same type of key for both the key blinding and the KEM - +for example, if elliptic curve arithmetic is used for key blinding as described in {{blinding-ec}} +and ECDH is used as the KEM as described in {{kem-ecdh}} [Frymann2020] - +then the two keys MAY be the same key. +Representations of such an ARKG seed MAY allow for omitting the second copy of the constituent key, +but such representations MUST clearly identify that the single constituent key is to be used +both as the key blinding key and the KEM key. + + +## Using HMAC to augment a KEM with ciphertext integrity {#hmac-kem} + +As described in {{arkg-seed-correlation}}, +some implementations may require a KEM that guarantees ciphertext integrity, +meaning that a valid KEM ciphertext can be created only with knowledge of the KEM public key +and any domain separation parameters. +Not all KEMs provide this guarantee, +so this section defines a general formula for augmenting any KEM with ciphertext integrity by prepending a MAC to the KEM ciphertext. For example, ECDH does not guarantee ciphertext integrity - any elliptic curve point is a valid ECDH ciphertext @@ -511,10 +605,10 @@ and can be successfully decapsulated using any elliptic curve private scalar. This formula has the following parameters: -- `Hash`: A cryptographic hash function. -- `Sub-Kem`: A key encapsulation mechanism as described for the `KEM` parameter in {{arkg-params}}, - except `Sub-Kem` MAY ignore the `info` parameter and MAY not guarantee ciphertext integrity. - `Sub-Kem` defines the functions `Sub-Kem-Generate-Keypair`, `Sub-Kem-Encaps` and `Sub-Kem-Decaps`. +- `Hash`: A cryptographic hash function suitable for use in HMAC [RFC2104] and HKDF [RFC5869]. +- `Sub-Kem`: An instance of the `KEM` parameter described in {{arkg-params}}. + This `KEM` instance defines functions `KEM-Generate-Keypair`, `KEM-Encaps` and `KEM-Decaps` + which are respectively referred to below as `Sub-Kem-Generate-Keypair`, `Sub-Kem-Encaps` and `Sub-Kem-Decaps`. The `KEM` parameter of ARKG may be instantiated using `Sub-Kem`, HMAC [RFC2104] and HKDF [RFC5869] as follows: @@ -524,11 +618,17 @@ HMAC [RFC2104] and HKDF [RFC5869] as follows: - `DROP_LEFT(X, n)` is the byte array `X` without the first `n` bytes. We truncate the HMAC output to 128 bits (16 octets) -because as described in {{design-rationale-mac}}, +because as described in {{arkg-seed-correlation}}, ARKG needs ciphertext integrity only to ensure correctness, not for security. Extendable-output functions used as the `Hash` parameter SHOULD still be instantiated with an output length appropriate for the desired security level, in order to not leak information about the `Sub-KEM` shared secret key. +Instantiations of this formula SHOULD prefer `Hash` functions already used in the algorithm suite. + +This formula ensures domain separation from the base KEM +by prepending a prefix to the domain separation tag `info` of `Sub-KEM` +and by passing the base KEM shared secret `k'` through HKDF +to produce the final shared secret `k`. ~~~pseudocode @@ -539,7 +639,7 @@ KEM-Generate-Keypair() -> (pk, sk) KEM-Encaps(pk, info) -> (k, c) - (k', c') = Sub-Kem-Encaps(pk, info) + (k', c') = Sub-Kem-Encaps(pk, 'arkg-KEM-hmac' || info) prk = HKDF-Extract with the arguments: Hash: Hash @@ -565,7 +665,7 @@ KEM-Decaps(sk, c, info) -> k t = LEFT(c, 16) c' = DROP_LEFT(c, 16) - k' = Sub-Kem-Decaps(sk, c', info) + k' = Sub-Kem-Decaps(sk, c', 'arkg-KEM-hmac' || info) prk = HKDF-Extract with the arguments: Hash: Hash @@ -590,109 +690,6 @@ KEM-Decaps(sk, c, info) -> k ~~~ -## Using ECDH as the KEM {#kem-ecdh} - -Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism `KEM` [Frymann2020] [Wilson]. -This section defines a general formula for such instantiations of `KEM`. - -This formula has the following parameters: - -- `crv`: an elliptic curve valid for use with ECDH [RFC6090]. -- `Hash`: A cryptographic hash function. - -The `KEM` parameter of ARKG may be instantiated as described in section {{hmac-kem}} with the parameters: - -- `Hash`: `Hash`. -- `Sub-Kem`: The functions `Sub-Kem-Generate-Keypair`, `Sub-Kem-Encaps` and `Sub-Kem-Decaps` defined as follows: - - - `Elliptic-Curve-Point-to-Octet-String` and `Octet-String-to-Elliptic-Curve-Point` - are the conversion routines defined in sections 2.3.3 and 2.3.4 of [SEC1]. - - - `ECDH(pk, sk)` represents the compact output of ECDH [RFC6090] - using public key (curve point) `pk` and private key (exponent) `sk`. - - - `G` is the generator of the prime order subgroup of `crv`. - - `N` is the order of `G`. - - ~~~pseudocode - Sub-Kem-Generate-Keypair() -> (pk, sk) - - Generate (pk, sk) using some procedure defined for crv. - - - Sub-Kem-Encaps(pk, info) -> (k, c) - - (pk', sk') = Sub-Kem-Generate-Keypair() - - k = ECDH(pk, sk') - c = Elliptic-Curve-Point-to-Octet-String(pk') - - - Sub-Kem-Decaps(sk, c, info) -> k - - pk' = Octet-String-to-Elliptic-Curve-Point(c) - k = ECDH(pk', sk) - ~~~ - - -## Using X25519 or X448 as the KEM {#kem-x25519-x448} - -Instantiations of ARKG can use X25519 or X448 [RFC7748] as the key encapsulation mechanism `KEM`. -This section defines a general formula for such instantiations of `KEM`. - -This formula has the following parameters: - -- `DH-Function`: the function X25519 or the function X448 [RFC7748]. - -The `KEM` parameter of ARKG may be instantiated as described in section {{hmac-kem}} with the parameters: - -- `Hash`: SHA-512 [FIPS 180-4] if `DH-Function` is X25519, - or SHAKE256 [FIPS 202] with output length 64 octets if `DH-Function` is X448. -- `Sub-Kem`: The functions `Sub-Kem-Generate-Keypair`, `Sub-Kem-Encaps` and `Sub-Kem-Decaps` defined as follows: - - - `Random-Bytes(N)` represents a cryptographically secure, - uniformly distributed random octet string of length `N`. - - `L` is 32 if `DH-Function` is X25519, or 56 if `DH-Function` is X448. - - `G` is the octet string `h'0900000000000000 0000000000000000 0000000000000000 0000000000000000'` - if `DH-Function` is X25519, - or the octet string `h'0500000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000'` - if `DH-Function` is X448. - - These are the little-endian encodings of the integers 9 and 5, - which is the u-coordinate of the generator point of the respective curve group. - - ~~~pseudocode - Sub-Kem-Generate-Keypair() -> (pk, sk) - - sk = Random-Bytes(L) - pk = DH-Function(sk, G) - - - Sub-Kem-Encaps(pk, info) -> (k, c) - - (pk', sk') = Sub-Kem-Generate-Keypair() - - k = DH-Function(sk', pk) - c = pk' - - - Sub-Kem-Decaps(sk, c, info) -> k - - k = DH-Function(sk, c) - ~~~ - - -## Using the same key for both key blinding and KEM {#blinding-kem-same-key} - -When an ARKG instance uses the same type of key for both the key blinding and the KEM - -for example, if elliptic curve arithmetic is used for key blinding as described in {{blinding-ec}} -and ECDH is used as the KEM as described in {{kem-ecdh}} [Frymann2020] - -then the two keys MAY be the same key. -Representations of such an ARKG seed MAY allow for omitting the second copy of the constituent key, -but such representations MUST clearly identify that the single constituent key is to be used -both as the key blinding key and the KEM key. - - # Concrete ARKG instantiations This section defines an initial set of concrete ARKG instantiations. @@ -710,7 +707,20 @@ The identifier `ARKG-P256ADD-ECDH` represents the following ARKG instance: - `hash-to-field-DST`: `'ARKG-P256ADD-ECDH'`. - `KEM`: ECDH as described in {{kem-ecdh}} with the parameters: - `crv`: The NIST curve `secp256r1` [SEC2]. + + +## ARKG-P256ADD-ECDH-HMAC + +The identifier `ARKG-P256ADD-ECDH-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The NIST curve `secp256r1` [SEC2]. + - `hash-to-crv-suite`: `P256_XMD:SHA-256_SSWU_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-P256ADD-ECDH-HMAC'`. +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: - `Hash`: SHA-256 [FIPS 180-4]. + - `Sub-Kem`: ECDH as described in {{kem-ecdh}} with the parameters: + - `crv`: The NIST curve `secp256r1` [SEC2]. ## ARKG-P384ADD-ECDH @@ -723,7 +733,20 @@ The identifier `ARKG-P384ADD-ECDH` represents the following ARKG instance: - `hash-to-field-DST`: `'ARKG-P384ADD-ECDH'`. - `KEM`: ECDH as described in {{kem-ecdh}} with the parameters: - `crv`: The NIST curve `secp384r1` [SEC2]. + + +## ARKG-P384ADD-ECDH-HMAC + +The identifier `ARKG-P384ADD-ECDH-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The NIST curve `secp384r1` [SEC2]. + - `hash-to-crv-suite`: `P384_XMD:SHA-384_SSWU_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-P384ADD-ECDH-HMAC'`. +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: - `Hash`: SHA-384 [FIPS 180-4]. + - `Sub-Kem`: ECDH as described in {{kem-ecdh}} with the parameters: + - `crv`: The NIST curve `secp384r1` [SEC2]. ## ARKG-P521ADD-ECDH @@ -739,6 +762,20 @@ The identifier `ARKG-P521ADD-ECDH` represents the following ARKG instance: - `Hash`: SHA-512 [FIPS 180-4]. +## ARKG-P521ADD-ECDH-HMAC + +The identifier `ARKG-P521ADD-ECDH-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The NIST curve `secp521r1` [SEC2]. + - `hash-to-crv-suite`: `P521_XMD:SHA-512_SSWU_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-P521ADD-ECDH-HMAC'`. +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHA-512 [FIPS 180-4]. + - `Sub-Kem`: ECDH as described in {{kem-ecdh}} with the parameters: + - `crv`: The NIST curve `secp521r1` [SEC2]. + + ## ARKG-P256kADD-ECDH The identifier `ARKG-P256kADD-ECDH` represents the following ARKG instance: @@ -752,6 +789,20 @@ The identifier `ARKG-P256kADD-ECDH` represents the following ARKG instance: - `Hash`: SHA-256 [FIPS 180-4]. +## ARKG-P256kADD-ECDH-HMAC + +The identifier `ARKG-P256kADD-ECDH-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The SECG curve `secp256k1` [SEC2]. + - `hash-to-crv-suite`: `secp256k1_XMD:SHA-256_SSWU_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-P256kADD-ECDH-HMAC'`. +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHA-256 [FIPS 180-4]. + - `Sub-Kem`: ECDH as described in {{kem-ecdh}} with the parameters: + - `crv`: The SECG curve `secp256k1` [SEC2]. + + ## ARKG-curve25519ADD-X25519 The identifier `ARKG-curve25519ADD-X25519` represents the following ARKG instance: @@ -783,6 +834,39 @@ The identifier `ARKG-curve25519ADD-X25519` represents the following ARKG instanc - `DH-Function`: X25519 [RFC7748]. +## ARKG-curve25519ADD-X25519-HMAC + +The identifier `ARKG-curve25519ADD-X25519-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The curve `curve25519` [RFC7748]. + - `hash-to-crv-suite`: `curve25519_XMD:SHA-512_ELL2_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-curve25519ADD-X25519-HMAC'`. + + WARNING: Some algorithms on curve25519, including X25519 [RFC7748], + construct private key scalars within a particular range + to enable optimizations and constant-time guarantees. + This `BL` scheme does not guarantee that blinded private scalars remain in that range, + so implementations using this ARKG instance MUST NOT rely on such a guarantee. + + Note: Input and output keys of this `BL` scheme are curve scalars and curve points. + Some algorithms on curve25519, including X25519 [RFC7748], + define the private key input as a random octet string and applies some preprocessing to it + before interpreting the result as a private key scalar, + and define public keys as a particular octet string encoding of a curve point. + This `BL` scheme is not compatible with such preprocessing + since it breaks the relationship between the blinded private key and the blinded public key. + Implementations using this ARKG instance MUST apply `BL-Blind-Private-Key` + to the interpreted private key scalar, not the random private key octet string, + and implementations of `BL-Blind-Public-Key` MUST interpret the public key input as a curve point, + not an opaque octet string. + +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHA-512 [FIPS 180-4]. + - `Sub-Kem`: X25519 as described in {{kem-x25519-x448}} with the parameters: + - `DH-Function`: X25519 [RFC7748]. + + ## ARKG-curve448ADD-X448 The identifier `ARKG-curve448ADD-X448` represents the following ARKG instance: @@ -814,6 +898,39 @@ The identifier `ARKG-curve448ADD-X448` represents the following ARKG instance: - `DH-Function`: X448 [RFC7748]. +## ARKG-curve448ADD-X448-HMAC + +The identifier `ARKG-curve448ADD-X448-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The curve `curve448` [RFC7748]. + - `hash-to-crv-suite`: `curve448_XOF:SHAKE256_ELL2_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-curve448ADD-X448-HMAC'`. + + WARNING: Some algorithms on curve25519, including X448 [RFC7748], + construct private key scalars within a particular range + to enable optimizations and constant-time guarantees. + This `BL` scheme does not guarantee that blinded private scalars remain in that range, + so implementations using this ARKG instance MUST NOT rely on such a guarantee. + + Note: Input and output keys of this `BL` scheme are curve scalars and curve points. + Some algorithms on curve25519, including X448 [RFC7748], + define the private key input as a random octet string and applies some preprocessing to it + before interpreting the result as a private key scalar, + and define public keys as a particular octet string encoding of a curve point. + This `BL` scheme is not compatible with such preprocessing + since it breaks the relationship between the blinded private key and the blinded public key. + Implementations using this ARKG instance MUST apply `BL-Blind-Private-Key` + to the interpreted private key scalar, not the random private key octet string, + and implementations of `BL-Blind-Public-Key` MUST interpret the public key input as a curve point, + not an opaque octet string. + +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHAKE256 [FIPS 202] with output length 64 octets. + - `Sub-Kem`: X448 as described in {{kem-x25519-x448}} with the parameters: + - `DH-Function`: X448 [RFC7748]. + + ## ARKG-edwards25519ADD-X25519 The identifier `ARKG-edwards25519ADD-X25519` represents the following ARKG instance: @@ -845,6 +962,39 @@ The identifier `ARKG-edwards25519ADD-X25519` represents the following ARKG insta - `DH-Function`: X25519 [RFC7748]. +## ARKG-edwards25519ADD-X25519-HMAC + +The identifier `ARKG-edwards25519ADD-X25519-HMAC` represents the following ARKG instance: + +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The curve `edwards25519` [RFC7748]. + - `hash-to-crv-suite`: `edwards25519_XMD:SHA-512_ELL2_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-edwards25519ADD-X25519-HMAC'`. + + WARNING: Some algorithms on edwards25519, including EdDSA [RFC8032], + construct private key scalars within a particular range + to enable optimizations and constant-time guarantees. + This `BL` scheme does not guarantee that blinded private scalars remain in that range, + so implementations using this ARKG instance MUST NOT rely on such a guarantee. + + Note: Input and output keys of this `BL` scheme are curve scalars and curve points. + Some algorithms on edwards25519, including EdDSA [RFC8032], + define the private key input as a random octet string and applies some preprocessing to it + before interpreting the result as a private key scalar, + and define public keys as a particular octet string encoding of a curve point. + This `BL` scheme is not compatible with such preprocessing + since it breaks the relationship between the blinded private key and the blinded public key. + Implementations using this ARKG instance MUST apply `BL-Blind-Private-Key` + to the interpreted private key scalar, not the random private key octet string, + and implementations of `BL-Blind-Public-Key` MUST interpret the public key input as a curve point, + not an opaque octet string. + +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHA-512 [FIPS 180-4]. + - `Sub-Kem`: X25519 as described in {{kem-x25519-x448}} with the parameters: + - `DH-Function`: X25519 [RFC7748]. + + ## ARKG-edwards448ADD-X448 The identifier `ARKG-edwards448ADD-X448` represents the following ARKG instance: @@ -876,52 +1026,87 @@ The identifier `ARKG-edwards448ADD-X448` represents the following ARKG instance: - `DH-Function`: X448 [RFC7748]. -# COSE bindings +## ARKG-edwards448ADD-X448-HMAC -TODO?: Define COSE representations for interoperability: -- ARKG public seed (for interoperability between different implementers of `ARKG-Generate-Seed` and `ARKG-Derive-Public-Key`) -- ARKG key handle (for interoperability between different implementers of `ARKG-Derive-Public-Key` and `ARKG-Derive-Private-Key`) +The identifier `ARKG-edwards448ADD-X448-HMAC` represents the following ARKG instance: +- `BL`: Elliptic curve addition as described in {{blinding-ec}} with the parameters: + - `crv`: The curve `edwards448` [RFC7748]. + - `hash-to-crv-suite`: `edwards448_XOF:SHAKE256_ELL2_RO_` [RFC9380]. + - `hash-to-field-DST`: `'ARKG-edwards448ADD-X448-HMAC'`. -# Security Considerations {#Security} - -TODO - + WARNING: Some algorithms on edwards25519, including EdDSA [RFC8032], + construct private key scalars within a particular range + to enable optimizations and constant-time guarantees. + This `BL` scheme does not guarantee that blinded private scalars remain in that range, + so implementations using this ARKG instance MUST NOT rely on such a guarantee. -# Privacy Considerations {#Privacy} + Note: Input and output keys of this `BL` scheme are curve scalars and curve points. + Some algorithms on edwards25519, including EdDSA [RFC8032], + define the private key input as a random octet string and applies some preprocessing to it + before interpreting the result as a private key scalar, + and define public keys as a particular octet string encoding of a curve point. + This `BL` scheme is not compatible with such preprocessing + since it breaks the relationship between the blinded private key and the blinded public key. + Implementations using this ARKG instance MUST apply `BL-Blind-Private-Key` + to the interpreted private key scalar, not the random private key octet string, + and implementations of `BL-Blind-Public-Key` MUST interpret the public key input as a curve point, + not an opaque octet string. -TODO +- `KEM`: A HMAC-augmented KEM as described in {{hmac-kem}} with the parameters: + - `Hash`: SHAKE256 [FIPS 202] with output length 64 octets. + - `Sub-Kem`: X448 as described in {{kem-x25519-x448}} with the parameters: + - `DH-Function`: X448 [RFC7748]. -# IANA Considerations {#IANA} +# COSE bindings -TODO +TODO?: Define COSE representations for interoperability: +- ARKG public seed (for interoperability between different implementers of `ARKG-Generate-Seed` and `ARKG-Derive-Public-Key`) +- ARKG key handle (for interoperability between different implementers of `ARKG-Derive-Public-Key` and `ARKG-Derive-Private-Key`) -# Design rationale +# Implementation Considerations {#Implementation} -## Using a MAC {#design-rationale-mac} +## Identifying the ARKG seed {#arkg-seed-id} -The ARKG construction by Wilson [Wilson] omits the MAC and instead encodes application context in the PRF labels, -arguing that this leads to invalid keys/signatures in cases that would have a bad MAC. -We choose to keep the MAC from the construction by Frymann et al. [Frymann2020], -but allow it to be omitted in case the chosen KEM already guarantees ciphertext integrity. +In some use cases there might exist multiple ARKG seed pairs or multiple candidate key handles in the same context, +so the subordinate party must somehow communicate to the delegate party +which key handle belongs to which ARKG seed. -The reason for this is ensure that the delegating party can distinguish key handles that belong to its ARKG seed. For example, applications using the W3C Web Authentication API [WebAuthn] do not know beforehand which authenticators are connected and available. Instead, authentication requests may include references to several eligible authenticators, and the one to use is chosen opportunistically by the WebAuthn client depending on which are available at the time. Consider using ARKG in such a scenario to sign some data with a derived private key: -a user may have several authenticators and thus several ARKG seeds, -so the signing request might include several well-formed ARKG key handles, -but only one of them belongs to the ARKG seed of the authenticator that is currently connected. -Without an integrity check, -choosing the wrong key handle might cause the `ARKG-Derive-Private-Key` procedure to silently derive the wrong key -instead of returning an explicit error, which would in turn lead to an invalid signature or similar final output. -This would make it difficult or impossible to diagnose the root cause of the issue and present actionable user feedback. -For this reason, we require the KEM to guarantee ciphertext integrity -so that `ARKG-Derive-Private-Key` can fail early if the key handle belongs to a different ARKG seed. +if the authenticator - the delegating party - chooses the wrong combination of private seed and key handle, +this might cause the `ARKG-Derive-Private-Key` procedure to silently derive the wrong key instead of returning an explicit error, +which would in turn lead to an invalid signature. +This might not be detected until a third party attempts to verify the signature, +at which point it may be difficult or impossible to diagnose the root cause of the invalid signature and present actionable user feedback. + +A simple solution for this is to have the delegating party emit an opaque identifier for the ARKG seed pair +along with the result of `ARKG-Generate-Seed`, +and have the subordinate party communicate that identifier along with the key handle output of `ARKG-Derive-Public-Key`. +This way the delegating party knows which ARKG private seed to use with which key handle +to compute the correct result in `ARKG-Derive-Private-Key`, +and can ignore any key handles that belong to a different delegating party. + +However, this solution may be unsuitable for some implementatiosn due to privacy implications. +This is discussed further in {{arkg-seed-correlation}}. + + +# Security Considerations {#Security} + +## Using a MAC {#security-mac} + +{{hmac-kem}} specifies a formula for adding a MAC to ARKG key handles. +The ARKG construction by Wilson [Wilson] omits this MAC and instead encodes application context in the PRF labels, +arguing that this leads to invalid keys/signatures in cases that would have a bad MAC. +For reasons described in {{arkg-seed-correlation}}, +we choose for some ARKG instantiations to keep the MAC from the construction by Frymann et al. [Frymann2020]. +This is not necessary in case the ARKG seed can be identified by other means as described in {{arkg-seed-id}} +or if the chosen KEM already guarantees ciphertext integrity as defined in {{arkg-seed-correlation}}. It is straightforward to see that adding the MAC to the construction by Wilson does not weaken the security properties defined by Frymann et al. [Frymann2020]: @@ -935,6 +1120,42 @@ Hence if one can break PK-unlinkability or SK-security of the ARKG construction one can also break the same property of the construction by Frymann et al. +# Privacy Considerations {#Privacy} + +## ARKG seed correlatability {#arkg-seed-correlation} + +{{arkg-seed-id}} discusses why some implementations may require a way to identify +which ARKG key handle belongs to which ARKG seed. +However, a static identifier could be an unacceptable correlation handle +in some use cases where the key handle may be communicated through an untrusted channel. + +For example, the original ARKG proposal [Frymann2020] studied a proposed extension to W3C Web Authentication (WebAuthn) +where the delegating and subordinate parties are WebAuthn authenticators +and the key handle is communicated through a WebAuthn Relying Party, +and that Relying Party must be prevented from tracking users by correlating ARKG key handles. + +The same paper solves the correlation issue by attaching a MAC to the key handle +instead of attaching an identifier for the ARKG seed. +The MAC tag is computed from the KEM shared key, +and so requires knowledge of the ARKG public seed and any domain separation parameters to compute. +This way the delegating party can ensure correctness in `ARKG-Derive-Private-Key` +by rejecting any key handle with an invalid MAC, +as it was most likely computed for a different ARKG seed. + +We choose here to model this capability as "KEM ciphertext integrity", +meaning that knowledge of the KEM public key and any domain separation parameters +is required in order to create any KEM ciphertext that can be successfully decapsulated by the corresponding KEM private key. +{{hmac-kem}} specifies a general formula for augmenting any KEM with a MAC to guarantee ciphertext integrity. + + +TODO + + +# IANA Considerations {#IANA} + +TODO + + ## Implementation Status TODO