Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update references to published Paper; modified citation style #26

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Update references to published Paper; modified citation style #26

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5d273cc
Update Reference from Master Thesis to published Paper; modified cita…
nichtmonti Nov 14, 2024
2ef751b
fix citation for paper with three authors
nichtmonti Nov 14, 2024
215f3b8
Reference ASIACCS Paper instead of Wilson thesis
nichtmonti Nov 14, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 31 additions & 28 deletions draft-bradleylundberg-cfrg-arkg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -87,21 +87,23 @@ informative:
author:
- name: Pieter Wuille
date: 2012
Clermont:
target: https://www.cryptoplexity.informatik.tu-darmstadt.de/media/crypt/teaching_1/theses_1/Sebastian_Clermont_Thesis.pdf
AC:BreCleFis24:
target: https://eprint.iacr.org/2023/1275
author:
- name: Sebastian A. Clermont
- name: Jacqueline Brendel
- name: Sebastian Clermont
- name: Marc Fischlin
org: "Technische Universität Darmstadt"
date: 2022
title: "Post Quantum Asynchronous Remote Key Generation. Master's thesis"
date: 2023
title: "Post-Quantum Asynchronous Remote Key Generation for FIDO2 Account Recovery. ASIACRYPT '24"
WebAuthn-Recovery:
author:
- name: Emil Lundberg
- name: Dain Nilsson
title: "WebAuthn recovery extension: Asynchronous delegated key generation without shared secrets. GitHub"
date: 2019
target: https://github.com/Yubico/webauthn-recovery-extension
Frymann2020:
CCS:FGKLMN20:
author:
- name: Nick Frymann
- name: Daniel Gardham
Expand All @@ -112,7 +114,7 @@ informative:
title: "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"
date: 2020
target: https://eprint.iacr.org/2020/1004
Frymann2023:
EUROSP:FryGarMan23:
author:
- name: Nick Frymann
- name: Daniel Gardham
Expand All @@ -127,13 +129,14 @@ informative:
title: A Proposal for an ISO Standard for Public Key Encryption (version 2.0)
date: 2001
target: https://www.shoup.net/papers/iso-2.pdf
Wilson:
ASIACCS:SteWil24:
author:
- name: Douglas Stebila
- name: Spencer MacLaren Wilson
org: University of Waterloo,
title: "Post-Quantum Account Recovery for Passwordless Authentication. Master's thesis"
title: "Quantum-Safe Account Recovery for WebAuthn. ASIACCS '24"
date: 2023
target: http://hdl.handle.net/10012/19316
target: https://eprint.iacr.org/2024/678



Expand Down Expand Up @@ -214,7 +217,7 @@ ARKG consists of three procedures:
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 quantum-resistant alternatives exist that meet these requirements. [Wilson]
Both conventional primitives and quantum-resistant alternatives exist that meet these requirements. [ASIACCS:SteWil24]


[rfc9052-direct-key-agreement]: https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-key-agreement
Expand Down Expand Up @@ -259,7 +262,7 @@ followed by the definitions of the three ARKG functions.
ARKG is composed of a suite of other algorithms.
The parameters of an ARKG instance are:

- `BL`: An asymmetric key blinding scheme [Wilson], consisting of:
- `BL`: An asymmetric key blinding scheme [ASIACCS:SteWil24], consisting of:
- Function `BL-Generate-Keypair() -> (pk, sk)`: Generate a blinding key pair.

No input.
Expand All @@ -286,7 +289,7 @@ The parameters of an ARKG instance are:
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 [Wilson] for definitions of security properties required of the key blinding scheme `BL`.
See [ASIACCS:SteWil24] for definitions of security properties required of the key blinding scheme `BL`.

- `KEM`: A key encapsulation mechanism [Shoup], consisting of the functions:
- `KEM-Generate-Keypair() -> (pk, sk)`: Generate a key encapsulation key pair.
Expand Down Expand Up @@ -319,7 +322,7 @@ The parameters of an ARKG instance are:
{{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`.
See [ASIACCS:SteWil24] 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.
Expand Down Expand Up @@ -478,7 +481,7 @@ which can be used to define concrete ARKG instantiations.
## Using elliptic curve addition for key blinding {#blinding-ec}

Instantiations of ARKG whose output keys are elliptic curve keys
can use elliptic curve addition as the key blinding scheme `BL` [Frymann2020] [Wilson].
can use elliptic curve addition as the key blinding scheme `BL` [CCS:FGKLMN20] [ASIACCS:SteWil24].
This section defines a general formula for such instantiations of `BL`.

This formula has the following parameters:
Expand Down Expand Up @@ -629,7 +632,7 @@ 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].
Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism `KEM` [CCS:FGKLMN20] [ASIACCS:SteWil24].
This section defines a general formula for such instantiations of `KEM`.

This formula has the following parameters:
Expand Down Expand Up @@ -728,7 +731,7 @@ The `KEM` parameter of ARKG may be instantiated as described in section {{hmac-k

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] -
and ECDH is used as the KEM as described in {{kem-ecdh}} [CCS:FGKLMN20] -
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
Expand Down Expand Up @@ -1186,9 +1189,9 @@ This section registers the following values in the IANA "COSE Algorithms" regist

## Using a MAC {#design-rationale-mac}

The ARKG construction by Wilson [Wilson] omits the MAC and instead encodes application context in the PRF labels,
The ARKG construction by Stebila et al. [ASIACCS:SteWil24] 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],
We choose to keep the MAC from the construction by Frymann et al. [CCS:FGKLMN20],
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.
Expand All @@ -1207,13 +1210,13 @@ This would make it difficult or impossible to diagnose the root cause of the iss
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.

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]:
It is straightforward to see that adding the MAC to the construction by Stebila et al.
does not weaken the security properties defined by Frymann et al. [CCS:FGKLMN20]:
the construction by Frymann et al. can be reduced to the ARKG construction in this document
by instantiating `BL` as described in {{blinding-ec}}
and `KEM` as described in {{kem-ecdh}}.
The use of hash_to_field in {{blinding-ec}} corresponds to the KDF<sub>1</sub> parameter in [Frymann2020],
and the use of HMAC and HKDF in {{hmac-kem}} corresponds to the MAC and KDF<sub>2</sub> parameters in [Frymann2020].
The use of hash_to_field in {{blinding-ec}} corresponds to the KDF<sub>1</sub> parameter in [CCS:FGKLMN20],
and the use of HMAC and HKDF in {{hmac-kem}} corresponds to the MAC and KDF<sub>2</sub> parameters in [CCS:FGKLMN20].
Hence if one can break PK-unlinkability or SK-security of the ARKG construction in this document,
one can also break the same property of the construction by Frymann et al.

Expand All @@ -1227,17 +1230,17 @@ TODO

# Acknowledgements

ARKG was first proposed under this name by Frymann et al. [Frymann2020],
ARKG was first proposed under this name by Frymann et al. [CCS:FGKLMN20],
who analyzed a proposed extension to W3C Web Authentication by Lundberg and Nilsson [WebAuthn-Recovery],
which was in turn inspired by a similar construction by Wuille [BIP32] used to create privacy-preserving Bitcoin addresses.
Frymann et al. [Frymann2020] generalized the constructions by Lundberg, Nilsson and Wuille
Frymann et al. [CCS:FGKLMN20] 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 quantum-resistant instantiations
were developed independently by Clermont [Clermont], Frymann et al. [Frymann2023] and Wilson [Wilson].
were developed independently by Brendel et al. [AC:BreCleFis24], Frymann et al. [FryGarMan23] and Stebila et al. [ASIACCS:SteWil24].

This document adopts the construction proposed by Wilson [Wilson],
modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. [Frymann2020].
This document adopts the construction proposed by Stebila et al. [ASIACCS:SteWil24],
modified by the inclusion of a MAC in the key handles as done in the original construction by Frymann et al. [CCS:FGKLMN20].

The authors would like to thank all of these authors for their research and development work that led to the creation of this document.

Expand Down