diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index 4f718a0..8078c64 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -197,21 +197,7 @@ Some motivating use cases of ARKG include: {::boilerplate bcp14-tagged} -## The Asynchronous Remote Key Generation (ARKG) algorithm - -The ARKG algorithm consists of three functions, each performed by one of two participants: -the _delegating party_ or the _subordinate party_. -The delegating party generates an ARKG _seed pair_ and emits the _public seed_ to the subordinate party -while keeping the _private seed_ secret. -The subordinate party can then use the public seed to generate derived public keys and _key handles_, -and the delegating party can use the private seed and a key handle to derive the corresponding private key. - -The following subsections define some notation and -the abstract instance parameters used to construct the three ARKG functions, -followed by the definitions of the three ARKG functions. - - -### Notation +## Notation The following notation is used throughout this document: @@ -222,14 +208,27 @@ The following notation is used throughout this document: - Elliptic curve operations are written in multiplicative notation: `*` denotes point multiplication, i.e., the curve group operation; - `^` denotes point exponentiation, i.e., repeated point multiplication; + `^` denotes point exponentiation, i.e., repeated point multiplication of the base with itself; and `+` denotes scalar addition modulo the curve order. - `Random(min_inc, max_exc)` represents a cryptographically secure random integer greater than or equal to `min_inc` and strictly less than `max_exc`. -### Instance parameters +# The Asynchronous Remote Key Generation (ARKG) algorithm + +The ARKG algorithm consists of three functions, each performed by one of two participants: +the _delegating party_ or the _subordinate party_. +The delegating party generates an ARKG _seed pair_ and emits the _public seed_ to the subordinate party +while keeping the _private seed_ secret. +The subordinate party can then use the public seed to generate derived public keys and _key handles_, +and the delegating party can use the private seed and a key handle to derive the corresponding private key. + +The following subsections define the abstract instance parameters used to construct the three ARKG functions, +followed by the definitions of the three ARKG functions. + + +## Instance parameters ARKG is composed of a suite of other algorithms. The parameters of an ARKG instance are: @@ -336,14 +335,14 @@ Instantiations MUST satisfy the following compatibility criteria: It is permissible for some `KDF` outputs to not be valid blinding factors, as long as this happens with negligible probability - - see section [Design Rationale: Using a MAC]. + see {{design-rationale-mac}}. - Output key material `okm` of length `L_mac` of `KDF` is a valid input MAC key `k` of `MAC-Tag(k, m)` and `MAC-Verify(k, m, t)`. It is permissible for some `KDF` outputs to not be valid MAC keys, as long as this happens with negligible probability - - see section [Design Rationale: Using a MAC]. + see {{design-rationale-mac}}. We denote a concrete ARKG instance by the pattern `ARKG-BL-KEM-MAC-KDF`, substituting the chosen instantiation for the `BL`, `KEM`, `MAC` and `KDF` parts. @@ -353,7 +352,7 @@ Concrete ARKG instances MUST always be identified by lookup in a registry of ful This is to prevent usage of algorithm combinations that may be incompatible or insecure. -### The function ARKG-Generate-Seed +## The function ARKG-Generate-Seed This function is performed by the delegating party. The delegating party generates the ARKG seed pair `(pk, sk)` @@ -381,7 +380,7 @@ ARKG-Generate-Seed() -> (pk, sk) ~~~ -### The function ARKG-Derive-Public-Key +## The function ARKG-Derive-Public-Key This function is performed by the subordinate party, which holds the ARKG public seed `pk = (pk_kem, pk_bl)`. The resulting public key `pk'` can be provided to external parties to use in asymmetric cryptography protocols, @@ -429,7 +428,7 @@ for example because `KDF` returns an invalid `tau` or `mk`, the procedure can safely be retried with the same arguments. -### The function ARKG-Derive-Secret-Key +## The function ARKG-Derive-Secret-Key This function is performed by the delegating party, which holds the ARKG private seed `(sk_kem, sk_bl)`. The resulting secret key `sk'` can be used in asymmetric cryptography protocols @@ -479,18 +478,16 @@ 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-Secret-Key`. -See also section [Design Rationale: Using a MAC]. +See also {{design-rationale-mac}}. -## Generic ARKG instantiations +# Generic ARKG instantiations This section defines generic formulae for instantiating the individual ARKG parameters, which can be used to define concrete ARKG instantiations. -TODO: IANA registry? COSE/JOSE? - -### Using elliptic curve arithmetic for key blinding +## Using elliptic curve arithmetic for key blinding {#blinding-ec} Instantiations of ARKG whose output keys are elliptic curve keys can use elliptic curve arithmetic as the key blinding scheme `BL`. [Frymann2020] [Wilson] @@ -540,7 +537,7 @@ BL-Blind-Secret-Key(sk, tau) -> sk_tau ~~~ -### Using ECDH as the KEM +## Using ECDH as the KEM {#kem-ecdh} Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism. This section defines a general formula for such instantiations of `KEM`. @@ -588,7 +585,7 @@ KEM-Decaps(sk, c) -> k ~~~ -### Using both elliptic curve arithmetic for key blinding and ECDH as the KEM +## Using both elliptic curve arithmetic for key blinding and ECDH as the KEM {#blinding-kem-ecdh} If elliptic curve arithmetic is used for key blinding and ECDH is used as the KEM, as described in the previous sections, @@ -599,7 +596,7 @@ as both the key blinding public key and the KEM public key. [Frymann2020] TODO: Caveats? I think I read in some paper or thesis about specific drawbacks of using the same key for both. -### Using HMAC as the MAC +## Using HMAC as the MAC {#mac-hmac} Let `Hash` be a cryptographic hash function. Then the `MAC` parameter of ARKG may be instantiated using HMAC [RFC2104] as follows: @@ -620,7 +617,7 @@ MAC-Verify(k, m, t) -> { 0, 1 } ~~~ -### Using HKDF as the KDF +## Using HKDF as the KDF {#kdf-hkdf} Let `Hash` be a cryptographic hash function. Then the `KDF` parameter of ARKG may be instantiated using HKDF [RFC5869] as follows: @@ -641,110 +638,110 @@ KDF(info, ikm, L) -> okm ~~~ -## Concrete ARKG instantiations +# Concrete ARKG instantiations This section defines an initial set of concrete ARKG instantiations. TODO: IANA registry? COSE/JOSE? -#### ARKG-P256-ECDH-P256-HMAC-SHA256-HKDF-SHA256 +## ARKG-P256-ECDH-P256-HMAC-SHA256-HKDF-SHA256 -The identifier `ARKG-P256-ECDH-P256-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instantiation: +The identifier `ARKG-P256-ECDH-P256-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The NIST curve `secp256r1` [SEC2]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH as described in {{kem-ecdh}} with the parameter: - `crv`: The NIST curve `secp256r1` [SEC2]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. - `L_bl`: 32 - `L_mac`: 32 -#### ARKG-P384-ECDH-P384-HMAC-SHA384-HKDF-SHA384 +## ARKG-P384-ECDH-P384-HMAC-SHA384-HKDF-SHA384 -The identifier `ARKG-P384-ECDH-P384-HMAC-SHA384-HKDF-SHA384` represents the following ARKG instantiation: +The identifier `ARKG-P384-ECDH-P384-HMAC-SHA384-HKDF-SHA384` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The NIST curve `secp384r1` [SEC2]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH as described in {{kem-ecdh}} with the parameter: - `crv`: The NIST curve `secp384r1` [SEC2]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-384 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-384 [FIPS 180-4]. - `L_bl`: 48 - `L_mac`: 48 -#### ARKG-P521-ECDH-P521-HMAC-SHA512-HKDF-SHA512 +## ARKG-P521-ECDH-P521-HMAC-SHA512-HKDF-SHA512 -The identifier `ARKG-P521-ECDH-P521-HMAC-SHA512-HKDF-SHA512` represents the following ARKG instantiation: +The identifier `ARKG-P521-ECDH-P521-HMAC-SHA512-HKDF-SHA512` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The NIST curve `secp521r1` [SEC2]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH as described in {{kem-ecdh}} with the parameter: - `crv`: The NIST curve `secp521r1` [SEC2]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-512 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-512 [FIPS 180-4]. - `L_bl`: 64 - `L_mac`: 64 -#### ARKG-P256k-ECDH-P256k-HMAC-SHA256-HKDF-SHA256 +## ARKG-P256k-ECDH-P256k-HMAC-SHA256-HKDF-SHA256 -The identifier `ARKG-P256k-ECDH-P256k-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instantiation: +The identifier `ARKG-P256k-ECDH-P256k-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The SECG curve `secp256k1` [SEC2]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH as described in {{kem-ecdh}} with the parameter: - `crv`: The SECG curve `secp256k1` [SEC2]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. - `L_bl`: 32 - `L_mac`: 32 -#### ARKG-Ed25519-X25519-HMAC-SHA256-HKDF-SHA256 +## ARKG-Ed25519-X25519-HMAC-SHA256-HKDF-SHA256 -The identifier `ARKG-Ed25519-X25519-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instantiation: +The identifier `ARKG-Ed25519-X25519-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The curve `Ed25519` [REF?]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH as described in {{kem-ecdh}} with the parameter: - `crv`: The curve `X25519` [REF?]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. - `L_bl`: 32 - `L_mac`: 32 -#### ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256 +## ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256 -The identifier `ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instantiation: +The identifier `ARKG-X25519-X25519-HMAC-SHA256-HKDF-SHA256` represents the following ARKG instance: -- `BL`: Elliptic curve arithmetic as described in section [Using elliptic curve arithmetic for key blinding] with the parameter: +- `BL`: Elliptic curve arithmetic as described in {{blinding-ec}} with the parameter: - `crv`: The curve `X25519` [REF?]. -- `KEM`: ECDH [RFC6090] as described in section [Using ECDH as the KEM] with the parameter: +- `KEM`: ECDH [RFC6090] as described in {{kem-ecdh}} with the parameter: - `crv`: The curve `X25519` [REF?]. -- `MAC`: HMAC as described in section [Using HMAC as the MAC] with the parameter: +- `MAC`: HMAC as described in {{mac-hmac}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. -- `KDF`: HKDF as described in section [Using HKDF as the KDF] with the parameter: +- `KDF`: HKDF as described in {{kdf-hkdf}} with the parameter: - `Hash`: SHA-256 [FIPS 180-4]. - `L_bl`: 32 - `L_mac`: 32 -## COSE bindings +# COSE bindings TODO?: Define COSE representations for interoperability: - ARKG public seed (for interoperability between different implementers of `ARKG-Generate-Seed` and `ARKG-Derive-Public-Key`) @@ -768,7 +765,7 @@ TODO # Design rationale -## Using a MAC +## Using a MAC {#design-rationale-mac} The ARKG construction by Wilson [Wilson] omits the MAC and instead encodes application context in the PRF labels, arguing this leads to invalid keys/signatures in cases that would have a bad MAC.