]>
The Asynchronous Remote Key Generation (ARKG) algorithm
Yubico
Kungsgatan 44
Stockholm
SE
emil@emlun.se
Yubico
ve7jtb@ve7jtb.com
IRTF
Crypto Forum
KDF
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm
that enables delegation of asymmetric public key generation without giving access to the corresponding private keys.
This capability enables a variety of applications:
a user agent can generate pseudonymous public keys to prevent tracking;
a message sender can generate ephemeral recipient public keys to enhance forward secrecy;
two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other.
This document provides three main contributions:
a specification of the generic ARKG algorithm using abstract primitives;
a set of formulae for instantiating the abstract primitives using concrete primitives;
and an initial set of fully specified concrete ARKG instances.
We expect that additional instances will be defined in the future.
About This Document
Status information for this document may be found at .
Source for this draft and an issue tracker can be found at
.
Introduction
Asynchronous Remote Key Generation (ARKG) introduces a mechanism
to generate public keys without access to the corresponding private keys.
Such a mechanism is useful for many scenarios when a new public key is needed
but the private key holder is not available to perform the key generation.
This may occur when private keys are stored in a hardware security device,
which may be unavailable or locked at the time a new public key is needed.
Some motivating use cases of ARKG include:

Singleuse asymmetric keys:
Envisioned for the European Union's digital identity framework,
which is set to use singleuse asymmetric keys to prevent colluding verifiers from using public keys as correlation handles.
Each digital identity credential would thus be issued with a singleuse proofofpossession key,
used only once to present the credential to a verifier.
ARKG empowers both online and offline usage scenarios:
for offline scenarios, ARKG enables pregeneration of public keys for singleuse credentials
without needing to access the hardware security device that holds the private keys.
For online scenarios, ARKG gives the credential issuer assurance
that all derived private keys are bound to the same secure hardware element.
In both cases, application performance may be improved
since public keys can be generated in a generalpurpose execution environment instead of a secure enclave.

Enhanced forward secrecy:
The use of ARKG can facilitate forward secrecy in certain contexts.
For instance, section 8.5.4 of RFC 9052 notes that
"Since COSE is designed for a storeandforward environment rather than an online environment,
[...] forward secrecy (see ) is not achievable. A static key will always be used for the receiver of the COSE object."
As opposed to workarounds like exchanging a large number of keys in advance,
ARKG enables the the sender to generate ephemeral recipient public keys on demand.

Backup key generation:
For example, the W3C Web Authentication API [WebAuthn] (WebAuthn) generates a new key pair for each account on each web site.
ARKG could allow for simultaneously generating a backup public key when registering a new public key.
A primary authenticator could generate both a key pair for itself and a public key for a paired backup authenticator.
The backup authenticator only needs to be paired with the primary authenticator once,
and can then be safely stored until it is needed.
ARKG consists of three procedures:

Initialization:
The delegating party generates a seed pair and discloses the public seed to a subordinate party,
while securely retaining the private seed.

Public key generation:
The subordinate party uses the public seed to autonomously generate a new public key
along with a unique key handle for the public key.
This can be repeated any number of times.

Private key derivation:
The delegating party uses a key handle and the private seed
to derive the private key corresponding to the public key generated along with the key handle.
This can be repeated with any number of key handles.
Notably, ARKG can be built entirely using established cryptographic primitives.
The required primitives are a public key blinding scheme and a key encapsulation mechanism (KEM),
which may in turn use a key derivation function (KDF) and a message authentication code (MAC) scheme.
Both conventional primitives and quantumresistant alternatives exist that meet these requirements.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Notation
The following notation is used throughout this document:

The symbol  represents octet string concatenation.

Literal text strings and octet strings are denoted
using the CDDL syntax defined in .

Elliptic curve operations are written in additive notation:
+ denotes point addition, i.e., the curve group operation;
* denotes point multiplication, i.e., repeated point addition;
and + also denotes scalar addition modulo the curve order.
* has higher precedence than +, i.e., a + b * C is equivalent to a + (b * C).
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:

BL: An asymmetric key blinding scheme , consisting of:

Function BLGenerateKeypair() > (pk, sk): Generate a blinding key pair.
No input.
Output consists of a blinding public key pk and a blinding private key sk.

Function BLBlindPublicKey(pk, tau, info) > pk_tau: Deterministically compute a blinded public key.
Input consists of a blinding public key pk,
a blinding factor tau
and a domain separation parameter info.
Output consists of the blinded public key pk_tau.

Function BLBlindPrivateKey(sk, tau, info) > sk_tau: Deterministically compute a blinded private key.
Input consists of a blinding private key sk,
a blinding factor tau
and a domain separation parameter info.
Output consists of the blinded private key sk_tau.
tau and info are an opaque octet strings of arbitrary length.
The representations of pk and pk_tau are defined by the protocol that invokes ARKG.
The representations of sk and sk_tau are an undefined implementation detail.
See for definitions of security properties required of the key blinding scheme BL.

KEM: A key encapsulation mechanism, consisting of the functions:

KEMGenerateKeypair() > (pk, sk): Generate a key encapsulation key pair.
No input.
Output consists of public key pk and private key sk.

KEMEncaps(pk, info) > (k, c): Generate a key encapsulation.
Input consists of an encapsulation public key pk
and a domain separation parameter info.
Output consists of a shared secret k and an encapsulation ciphertext c.

KEMDecaps(sk, c, info) > k: Decapsulate a shared secret.
Input consists of encapsulation private key sk, encapsulation ciphertext c
and a domain separation parameter info.
Output consists of the shared secret k on success, or an error otherwise.
k, c and info are opaque octet strings of arbitrary length.
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.
describes a general formula for how any KEM can be adapted to include this guarantee.
discusses the reasons for this requirement.
See for definitions of additional security properties required of the key encapsulation mechanism KEM.
A concrete ARKG instantiation MUST specify the instantiation
of each of the above functions and values.
The output keys of the BL scheme are also the output keys of the ARKG instance as a whole.
For example, if BLBlindPublicKey and BLBlindPrivateKey output ECDSA keys,
then the ARKG instance will also output ECDSA keys.
We denote a concrete ARKG instance by the pattern ARKGBLKEM,
substituting the chosen instantiation for the BL and KEM.
Note that this pattern cannot in general be unambiguously parsed;
implementations MUST NOT attempt to construct an ARKG instance by parsing such a pattern string.
Concrete ARKG instances MUST always be identified by lookup in a registry of fully specified ARKG instances.
This is to prevent usage of algorithm combinations that may be incompatible or insecure.
The function ARKGGenerateSeed
This function is performed by the delegating party.
The delegating party generates the ARKG seed pair (pk, sk)
and keeps the private seed sk secret, while the public seed pk is provided to the subordinate party.
The subordinate party will then be able to generate public keys on behalf of the delegating party.
(pk, sk)
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.
Inputs: None
Output:
(pk, sk) An ARKG seed pair with public seed pk
and private seed sk.
The output (pk, sk) is calculated as follows:
(pk_kem, sk_kem) = KEMGenerateKeypair()
(pk_bl, sk_bl) = BLGenerateKeypair()
pk = (pk_kem, pk_bl)
sk = (sk_kem, sk_bl)
]]>
Deterministic key generation
Although the above definition expresses the key generation as opaque,
likely sampling uniformly random key distributions,
implementations MAY choose to implement the functions BLGenerateKeypair(),
KEMGenerateKeypair() and ARKGGenerateSeed()
as deterministic functions of some outofband input.
This can be thought of as defining a singleuse ARKG instance where these function outputs are static.
This use case is beyond the scope of this document
since the implementation of ARKGGenerateSeed is internal to the delegating party,
even if applications choose to distribute the delegating party across multiple processing entities.
For example, one entity may randomly sample pk_bl, derive pk_kem deterministically from pk_bl
and submit only pk_bl to a separate service that uses the same procedure to also derive the same pk_kem.
This document considers both of these entities as parts of the same logical delegating party.
The function ARKGDerivePublicKey
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,
and the resulting key handle kh can be used by the delegating party to derive the private key corresponding to pk'.
This function may be invoked any number of times with the same public seed,
in order to generate any number of public keys.
(pk', kh)
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.
Inputs:
pk_kem A key encapsulation public key.
pk_bl A key blinding public key.
info An octet string containing optional context
and application specific information
(can be a zerolength string).
Output:
pk' A blinded public key.
kh A key handle for deriving the blinded
private key sk' corresponding to pk'.
The output (pk', kh) is calculated as follows:
info_kem = 'ARKGDeriveKeyKEM.'  info
info_bl = 'ARKGDeriveKeyBL.'  info
(tau, c) = KEMEncaps(pk_kem, info_kem)
pk' = BLBlindPublicKey(pk_bl, tau, info_bl)
kh = c
]]>
If this procedure aborts due to an error,
the procedure can safely be retried with the same arguments.
The function ARKGDerivePrivateKey
This function is performed by the delegating party, which holds the ARKG private seed (sk_kem, sk_bl).
The resulting private key sk' can be used in asymmetric cryptography protocols
to prove possession of sk' to an external party that has the corresponding public key.
This function may be invoked any number of times with the same private seed,
in order to derive the same or different private keys any number of times.
sk'
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.
Inputs:
sk_kem A key encapsulation private key.
sk_bl A key blinding private key.
kh A key handle output from ARKGDerivePublicKey.
info An octet string containing optional context
and application specific information
(can be a zerolength string).
Output:
sk' A blinded private key.
The output sk' is calculated as follows:
info_kem = 'ARKGDeriveKeyKEM.'  info
info_bl = 'ARKGDeriveKeyBL.'  info
tau = KEMDecaps(sk_kem, kh, info_kem)
If decapsulation failed:
Abort with an error.
sk' = BLBlindPrivateKey(sk_bl, tau, info_bl)
]]>
Errors in this procedure are typically unrecoverable.
For example, KEMDecaps may fail to decapsulate the KEM ciphertext kh if it fails an integrity check.
ARKG instantiations SHOULD be chosen in a way that such errors are impossible
if kh was generated by an honest and correct implementation of ARKGDerivePublicKey.
Incorrect or malicious implementations of ARKGDerivePublicKey do not degrade the security
of a correct and honest implementation of ARKGDerivePrivateKey.
See also .
Generic ARKG instantiations
This section defines generic formulae for instantiating the individual ARKG parameters,
which can be used to define concrete ARKG instantiations.
Using elliptic curve addition for key blinding
Instantiations of ARKG whose output keys are elliptic curve keys
can use elliptic curve addition as the key blinding scheme BL .
This section defines a general formula for such instantiations of BL.
This formula has the following parameters:

crv: An elliptic curve.

hashtocrvsuite: A hashtocurve suite
suitable for hashing to the scalar field of crv.

DST_ext: A domain separation tag.
Then the BL parameter of ARKG may be instantiated as follows:

G is the generator of the prime order subgroup of crv.

N is the order of G.

The function hash_to_field is defined in .
(pk, sk)
Generate (pk, sk) using some procedure defined for the curve crv.
BLBlindPublicKey(pk, tau, info) > pk_tau
tau' = hash_to_field(tau, 1) with the parameters:
DST: 'ARKGBLEC.'  DST_ext  info
F: GF(N), the scalar field
of the prime order subgroup of crv
p: N
m: 1
L: The L defined in hashtocrvsuite
expand_message: The expand_message function
defined in hashtocrvsuite
pk_tau = pk + tau' * G
BLBlindPrivateKey(sk, tau, info) > sk_tau
tau' = hash_to_field(tau, 1) with the parameters:
DST: 'ARKGBLEC.'  DST_ext  info
F: GF(N), the scalar field
of the prime order subgroup of crv.
p: N
m: 1
L: The L defined in hashtocrvsuite
expand_message: The expand_message function
defined in hashtocrvsuite
sk_tau_tmp = sk + tau'
If sk_tau_tmp = 0, abort with an error.
sk_tau = sk_tau_tmp
]]>
Using HMAC to adapt a KEM without integrity protection
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
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
and can be successfully decapsulated using any elliptic curve private scalar.
This formula has the following parameters:

Hash: A cryptographic hash function.

DST_ext: A domain separation parameter.

SubKem: A key encapsulation mechanism as described for the KEM parameter in ,
except SubKem MAY ignore the info parameter and MAY not guarantee ciphertext integrity.
SubKem defines the functions SubKemGenerateKeypair, SubKemEncaps and SubKemDecaps.
The KEM parameter of ARKG may be instantiated using SubKem,
HMAC and HKDF as follows:

L is the output length of Hash in octets.

LEFT(X, n) is the first n bytes of the byte array X.

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 ,
ARKG needs ciphertext integrity only to ensure correctness, not for security.
Extendableoutput 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 SubKEM shared secret key.
(pk, sk)
(pk, sk) = SubKemGenerateKeypair()
KEMEncaps(pk, info) > (k, c)
info_sub = 'ARKGKEMHMAC.'  DST_ext  info
(k', c') = SubKemEncaps(pk, info_sub)
prk = HKDFExtract with the arguments:
Hash: Hash
salt: not set
IKM: k'
mk = HKDFExpand with the arguments:
Hash: Hash
PRK: prk
info: 'ARKGKEMHMACmac.'  DST_ext  info
L: L
t = HMACHash128(K=mk, text=info)
k = HKDFExpand with the arguments:
Hash: Hash
PRK: prk
info: 'ARKGKEMHMACshared.'  DST_ext  info
L: The length of k' in octets.
c = t  c'
KEMDecaps(sk, c, info) > k
t = LEFT(c, 16)
c' = DROP_LEFT(c, 16)
info_sub = 'ARKGKEMHMAC.'  DST_ext  info
k' = SubKemDecaps(sk, c', info_sub)
prk = HKDFExtract with the arguments:
Hash: Hash
salt: not set
IKM: k'
mk = HKDFExpand with the arguments:
Hash: Hash
PRK: prk
info: 'ARKGKEMHMACmac.'  DST_ext  info
L: L
t' = HMACHash128(K=mk, text=info)
If t = t':
k = HKDFExpand with the arguments:
Hash: Hash
PRK: prk
info: 'ARKGKEMHMACshared.'  DST_ext  info
L: The length of k' in octets.
Else:
Abort with an error.
]]>
Using ECDH as the KEM
Instantiations of ARKG can use ECDH as the key encapsulation mechanism KEM .
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 .

Hash: A cryptographic hash function.

DST_ext: A domain separation parameter.
The KEM parameter of ARKG may be instantiated as described in section with the parameters:

Hash: Hash.

DST_ext: 'ARKGECDH.'  DST_ext.

SubKem: The functions SubKemGenerateKeypair, SubKemEncaps and SubKemDecaps defined as follows:

EllipticCurvePointtoOctetString and OctetStringtoEllipticCurvePoint
are the conversion routines defined in sections 2.3.3 and 2.3.4 of ,
without point compression.

ECDH(pk, sk) represents the compact output of ECDH
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.
(pk, sk)
Generate (pk, sk) using some procedure defined for crv.
SubKemEncaps(pk, info) > (k, c)
(pk', sk') = SubKemGenerateKeypair()
k = ECDH(pk, sk')
c = EllipticCurvePointtoOctetString(pk')
SubKemDecaps(sk, c, info) > k
pk' = OctetStringtoEllipticCurvePoint(c)
k = ECDH(pk', sk)
]]>
Using X25519 or X448 as the KEM
Instantiations of ARKG can use X25519 or X448 as the key encapsulation mechanism KEM.
This section defines a general formula for such instantiations of KEM.
This formula has the following parameters:

DHFunction: the function X25519 or the function X448 .

DST_ext: A domain separation parameter.
The KEM parameter of ARKG may be instantiated as described in section with the parameters:

Hash: SHA512 [FIPS 1804] if DHFunction is X25519,
or SHAKE256 [FIPS 202] with output length 64 octets if DHFunction is X448.

DST_ext: 'ARKGECDHX.'  DST_ext.

SubKem: The functions SubKemGenerateKeypair, SubKemEncaps and SubKemDecaps defined as follows:

RandomBytes(N) represents a cryptographically secure,
uniformly distributed random octet string of length N.

L is 32 if DHFunction is X25519, or 56 if DHFunction is X448.

G is the octet string h'0900000000000000 0000000000000000 0000000000000000 0000000000000000'
if DHFunction is X25519,
or the octet string h'0500000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000'
if DHFunction is X448.
These are the littleendian encodings of the integers 9 and 5,
which is the ucoordinate of the generator point of the respective curve group.
(pk, sk)
sk = RandomBytes(L)
pk = DHFunction(sk, G)
SubKemEncaps(pk, info) > (k, c)
(pk', sk') = SubKemGenerateKeypair()
k = DHFunction(sk', pk)
c = pk'
SubKemDecaps(sk, c, info) > k
k = DHFunction(sk, c)
]]>
Using the same key for both key blinding and KEM
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
and ECDH is used as the KEM as described in 
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.
TODO: IANA registry? COSE/JOSE?
ARKGP256ADDECDH
The identifier ARKGP256ADDECDH represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The NIST curve secp256r1 .

hashtocrvsuite: P256_XMD:SHA256_SSWU_RO_ .

DST_ext: 'ARKGP256ADDECDH'.

KEM: ECDH as described in with the parameters:

crv: The NIST curve secp256r1 .

Hash: SHA256 [FIPS 1804].

DST_ext: 'ARKGP256ADDECDH'.
ARKGP384ADDECDH
The identifier ARKGP384ADDECDH represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The NIST curve secp384r1 .

hashtocrvsuite: P384_XMD:SHA384_SSWU_RO_ .

DST_ext: 'ARKGP384ADDECDH'.

KEM: ECDH as described in with the parameters:

crv: The NIST curve secp384r1 .

Hash: SHA384 [FIPS 1804].

DST_ext: 'ARKGP384ADDECDH'.
ARKGP521ADDECDH
The identifier ARKGP521ADDECDH represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The NIST curve secp521r1 .

hashtocrvsuite: P521_XMD:SHA512_SSWU_RO_ .

DST_ext: 'ARKGP521ADDECDH'.

KEM: ECDH as described in with the parameters:

crv: The NIST curve secp521r1 .

Hash: SHA512 [FIPS 1804].

DST_ext: 'ARKGP521ADDECDH'.
ARKGP256kADDECDH
The identifier ARKGP256kADDECDH represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The SECG curve secp256k1 .

hashtocrvsuite: secp256k1_XMD:SHA256_SSWU_RO_ .

DST_ext: 'ARKGP256kADDECDH'.

KEM: ECDH as described in with the parameters:

crv: The SECG curve secp256k1 .

Hash: SHA256 [FIPS 1804].

DST_ext: 'ARKGP256kADDECDH'.
ARKGcurve25519ADDX25519
The identifier ARKGcurve25519ADDX25519 represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The curve curve25519 .

hashtocrvsuite: curve25519_XMD:SHA512_ELL2_RO_ .

DST_ext: 'ARKGcurve25519ADDX25519'.
WARNING: Some algorithms on curve25519, including X25519 ,
construct private key scalars within a particular range
to enable optimizations and constanttime 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 ,
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 BLBlindPrivateKey
to the interpreted private key scalar, not the random private key octet string,
and implementations of BLBlindPublicKey MUST interpret the public key input as a curve point,
not an opaque octet string.

KEM: X25519 as described in with the parameters:

DHFunction: X25519 .

DST_ext: 'ARKGcurve25519ADDX25519'.
ARKGcurve448ADDX448
The identifier ARKGcurve448ADDX448 represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The curve curve448 .

hashtocrvsuite: curve448_XOF:SHAKE256_ELL2_RO_ .

DST_ext: 'ARKGcurve448ADDX448'.
WARNING: Some algorithms on curve25519, including X448 ,
construct private key scalars within a particular range
to enable optimizations and constanttime 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 ,
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 BLBlindPrivateKey
to the interpreted private key scalar, not the random private key octet string,
and implementations of BLBlindPublicKey MUST interpret the public key input as a curve point,
not an opaque octet string.

KEM: X448 as described in with the parameters:

DHFunction: X448 .

DST_ext: 'ARKGcurve448ADDX448'.
ARKGedwards25519ADDX25519
The identifier ARKGedwards25519ADDX25519 represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The curve edwards25519 .

hashtocrvsuite: edwards25519_XMD:SHA512_ELL2_RO_ .

DST_ext: 'ARKGedwards25519ADDX25519'.
WARNING: Some algorithms on edwards25519, including EdDSA ,
construct private key scalars within a particular range
to enable optimizations and constanttime 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 ,
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 BLBlindPrivateKey
to the interpreted private key scalar, not the random private key octet string,
and implementations of BLBlindPublicKey MUST interpret the public key input as a curve point,
not an opaque octet string.

KEM: X25519 as described in with the parameters:

DHFunction: X25519 .

DST_ext: 'ARKGedwards25519ADDX25519'.
ARKGedwards448ADDX448
The identifier ARKGedwards448ADDX448 represents the following ARKG instance:

BL: Elliptic curve addition as described in with the parameters:

crv: The curve edwards448 .

hashtocrvsuite: edwards448_XOF:SHAKE256_ELL2_RO_ .

DST_ext: 'ARKGedwards448ADDX448'.
WARNING: Some algorithms on edwards25519, including EdDSA ,
construct private key scalars within a particular range
to enable optimizations and constanttime 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 ,
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 BLBlindPrivateKey
to the interpreted private key scalar, not the random private key octet string,
and implementations of BLBlindPublicKey MUST interpret the public key input as a curve point,
not an opaque octet string.

KEM: X448 as described in with the parameters:

DHFunction: X448 .

DST_ext: 'ARKGedwards448ADDX448'.
COSE bindings
This section proposes additions to COSE to support ARKG use cases.
The novelty lies primarily in a new key type definition to represent ARKG public seeds
and new key type definitions to represent references to private keys rather than the keys themselves.
COSE key type: ARKG public seed
An ARKG public seed is represented as a COSE_Key structure
with kty value TBD (placeholder value 65537).
This key type defines key type parameters 1 and 2 for the BL and KEM public key, respectively.
The following CDDL example represents an ARKGP256ADDECDH public seed
restricted to generating derived public keys for use with the ESP256 signature algorithm:
The following is the same example encoded as CBOR:
COSE key reference types
While keys used by many other algorithms can usually be referenced by a single atomic identifier,
such as that used in the kid parameter in a COSE_Key object or in the unprotected header of a COSE_Recipient,
users of the function ARKGDeriveSecretKey need to represent
a reference to an ARKG private seed along with a key handle for a derived private key.
A COSE key reference is a COSE_Key object whose kty value is defined to represent a reference to a key.
The kid parameter MUST be present when kty is a key reference type.
The following CDDL example represents a reference to a key derived by ARKGP256ADDECDH
and restricted for use with the ESP256 signature algorithm:
The following is the same example encoded as CBOR:
Security Considerations
TODO
Privacy Considerations
TODO
IANA Considerations
COSE Key Types Registrations
This section registers the following values in the IANA "COSE Key Types" registry .

Name: ARKGpubseed

Value: TBD (Placeholder 65537)

Description: ARKG public seed

Capabilities: [kty(65537), pk_bl, pk_kem]

Reference: of this document

Name: ARKGderived

Value: TBD (Placeholder 65538)

Description: Reference to private key derived by ARKG

Capabilities: [kty(65538), kh]

Reference: of this document

Name: RefOKP

Value: TBD (Requested assignment 1)

Description: Reference to a key pair of key type "OKP"

Capabilities: [kty(1), crv]

Reference: of this document

Name: RefEC2

Value: TBD (Requested assignment 2)

Description: Reference to a key pair of key type "EC2"

Capabilities: [kty(1), crv]

Reference: of this document
COSE Key Type Parameters Registrations
This section registers the following values in the IANA "COSE Key Type Parameters" registry .

Key Type: TBD (ARKGpubseed, placeholder 65537)

Name: pk_bl

Label: 1

CBOR Type: COSE_Key

Description: ARKG key blinding public key

Reference: of this document

Key Type: TBD (ARKGpubseed, placeholder 65537)

Name: pk_kem

Label: 2

CBOR Type: COSE_Key

Description: ARKG key encapsulation public key

Reference: of this document

Key Type: TBD (ARKGderived, placeholder 65538)

Name: kh

Label: 1

CBOR Type: bstr

Description: kh argument to ARKGDerivePrivateKey

Reference: of this document

Key Type: TBD (ARKGderived, placeholder 65538)

Name: info

Label: 2

CBOR Type: bstr

Description: info argument to ARKGDerivePrivateKey

Reference: of this document
COSE Algorithms Registrations
This section registers the following values in the IANA "COSE Algorithms" registry .

Name: ESP256ARKG

Value: TBD (Placeholder 65539)

Description: ESP256 with key derived by ARKGP256ADDECDH

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes

Name: ESP384ARKG

Value: TBD (Placeholder 65540)

Description: ESP384 with key derived by ARKGP384ADDECDH

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes

Name: ESP512ARKG

Value: TBD (Placeholder 65541)

Description: ESP512 with key derived by ARKGP521ADDECDH

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes

Name: ES256KARKG

Value: TBD (Placeholder 65542)

Description: ES256K with key derived by ARKGP256kADDECDH

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes

Name: Ed25519ARKG

Value: TBD (Placeholder 65543)

Description: Ed25519 with key derived by ARKGedwards25519ADDX25519

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes

Name: Ed448ARKG

Value: TBD (Placeholder 65544)

Description: Ed448 with key derived by ARKGedwards448ADDX448

Capabilities: [kty]

Change Controller: TBD

Reference: , of this document

Recommended: Yes
TODO: Add the rest
Design rationale
Using a MAC
The ARKG construction by 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. ,
but allow it to be omitted in case the chosen KEM already guarantees ciphertext integrity.
The reason for this is to ensure that the delegating party can distinguish key handles that belong to its ARKG seed.
For example, this is important for applications using the W3C Web Authentication API [WebAuthn],
which 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 wellformed 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 ARKGDerivePrivateKey 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 ARKGDerivePrivateKey can fail early if the key handle belongs to a different ARKG seed.
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. :
the construction by Frymann et al. can be reduced to the ARKG construction in this document
by instantiating BL as described in
and KEM as described in .
The use of hash_to_field in corresponds to the KDF_{1} parameter in ,
and the use of HMAC and HKDF in corresponds to the MAC and KDF_{2} parameters in .
Hence if one can break PKunlinkability or SKsecurity of the ARKG construction in this document,
one can also break the same property of the construction by Frymann et al.
Implementation Status
TODO
References
Normative References
FullySpecified Algorithms for JOSE and COSE
SelfIssued Consulting
CBOR Object Signing and Encryption (COSE)
IANA
HMAC: KeyedHashing for Message Authentication
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind
Internet Security Glossary, Version 2
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already wellestablished in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.
HMACbased ExtractandExpand Key Derivation Function (HKDF)
This document specifies a simple Hashed Message Authentication Code (HMAC)based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
Fundamental Elliptic Curve Cryptography Algorithms
This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.
Elliptic Curves for Security
This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128bit and ~224bit security level, respectively, and are generated deterministically based on a list of required properties.
EdwardsCurve Digital Signature Algorithm (EdDSA)
This document describes elliptic curve signature scheme Edwardscurve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.
CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms
The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSAPKCS1v1_5 using SHA256, SHA384, SHA512, and SHA1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.
CBOR Object Signing and Encryption (COSE): Structures and Process
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.
This document, along with RFC 9053, obsoletes RFC 8152.
Hashing to Elliptic Curves
This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
SEC 1: Elliptic Curve Cryptography
Certicom Research
SEC 2: Recommended Elliptic Curve Domain Parameters
Certicom Research
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
BIP 32 Hierarchical Deterministic Wallets
Post Quantum Asynchronous Remote Key Generation. Master's thesis
Technische Universität Darmstadt
WebAuthn recovery extension: Asynchronous delegated key generation without shared secrets. GitHub
Asynchronous Remote Key Generation: An Analysis of Yubico's Proposal for W3C WebAuthn. CCS '20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security
Asynchronous Remote Key Generation for PostQuantum Cryptosystems from Lattices. 2023 IEEE 8th European Symposium on Security and Privacy
PostQuantum Account Recovery for Passwordless Authentication. Master's thesis
University of Waterloo,
Acknowledgements
ARKG was first proposed under this name by Frymann et al. ,
who analyzed a proposed extension to W3C Web Authentication by Lundberg and Nilsson ,
which was in turn inspired by a similar construction by Wuille used to create privacypreserving Bitcoin addresses.
Frymann et al. generalized the constructions by Lundberg, Nilsson and Wuille
from elliptic curves to any discrete logarithm (DL) problem,
and also proved the security of arbitrary asymmetric protocols composed with ARKG.
Further generalizations to include quantumresistant instantiations
were developed independently by Clermont , Frymann et al. and Wilson .
This document adopts the construction proposed by Wilson ,
modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. .
The authors would like to thank all of these authors for their research and development work that led to the creation of this document.
Document History

00 Initial Version

01 Editorial Fixes to formatting and references.

02

Rewritten introduction.

Renamed ARKGDeriveSecretKey to ARKGDerivePrivateKey.

Overhauled EC instantiations to use hash_to_field and account for nonprime order curve key generation.

Eliminated toplevel MAC and KDF instance parameters.

Added info parameter to instance parameter functions.

Added requirement of KEM ciphertext integrity and generic formula for augmenting any KEM using HMAC.

Added curve/edwards25519/448 instances.

Added proposal for COSE bindings and key reference types.
Contributors
Yubico
Agency for Digital Government
SE