From 5d273cce07da53d16c3e83ebeafe84a1aae4def0 Mon Sep 17 00:00:00 2001 From: Sebastian Clermont Date: Thu, 14 Nov 2024 13:59:52 +0100 Subject: [PATCH 1/3] Update Reference from Master Thesis to published Paper; modified citation style --- draft-bradleylundberg-cfrg-arkg.md | 36 ++++++++++++++++-------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index e77511e..8c01be9 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -87,13 +87,15 @@ 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:BCF24: + 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 @@ -101,7 +103,7 @@ informative: 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 @@ -478,7 +480,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] [Wilson]. This section defines a general formula for such instantiations of `BL`. This formula has the following parameters: @@ -629,7 +631,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] [Wilson]. This section defines a general formula for such instantiations of `KEM`. This formula has the following parameters: @@ -728,7 +730,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 @@ -1188,7 +1190,7 @@ This section registers the following values in the IANA "COSE Algorithms" regist 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], +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. @@ -1208,12 +1210,12 @@ 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]: +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 KDF1 parameter in [Frymann2020], -and the use of HMAC and HKDF in {{hmac-kem}} corresponds to the MAC and KDF2 parameters in [Frymann2020]. +The use of hash_to_field in {{blinding-ec}} corresponds to the KDF1 parameter in [CCS:FGKLMN20], +and the use of HMAC and HKDF in {{hmac-kem}} corresponds to the MAC and KDF2 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. @@ -1227,17 +1229,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:BCF24], Frymann et al. [Frymann2023] and Wilson [Wilson]. 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]. +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. From 2ef751be631a62012ad6b79ce698c973794e2713 Mon Sep 17 00:00:00 2001 From: Sebastian Clermont Date: Thu, 14 Nov 2024 14:16:41 +0100 Subject: [PATCH 2/3] fix citation for paper with three authors --- draft-bradleylundberg-cfrg-arkg.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index 8c01be9..b53356b 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -87,7 +87,7 @@ informative: author: - name: Pieter Wuille date: 2012 - AC:BCF24: + AC:BreCleFis24: target: https://eprint.iacr.org/2023/1275 author: - name: Jacqueline Brendel @@ -114,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 @@ -1236,7 +1236,7 @@ Frymann et al. [CCS:FGKLMN20] generalized the constructions by Lundberg, Nilsson 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 Brendel et al. [AC:BCF24], Frymann et al. [Frymann2023] and Wilson [Wilson]. +were developed independently by Brendel et al. [AC:BreCleFis24], Frymann et al. [FryGarMan23] and Wilson [Wilson]. 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. [CCS:FGKLMN20]. From 215f3b8e5a665ee7dacab163662a0c893c2c2032 Mon Sep 17 00:00:00 2001 From: Sebastian Clermont Date: Thu, 14 Nov 2024 14:23:41 +0100 Subject: [PATCH 3/3] Reference ASIACCS Paper instead of Wilson thesis --- draft-bradleylundberg-cfrg-arkg.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/draft-bradleylundberg-cfrg-arkg.md b/draft-bradleylundberg-cfrg-arkg.md index b53356b..c3f0d8b 100644 --- a/draft-bradleylundberg-cfrg-arkg.md +++ b/draft-bradleylundberg-cfrg-arkg.md @@ -129,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 @@ -216,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 @@ -261,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. @@ -288,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. @@ -321,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. @@ -480,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` [CCS:FGKLMN20] [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: @@ -631,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` [CCS:FGKLMN20] [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: @@ -1188,7 +1189,7 @@ 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. [CCS:FGKLMN20], but allow it to be omitted in case the chosen KEM already guarantees ciphertext integrity. @@ -1209,7 +1210,7 @@ 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 +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}} @@ -1236,9 +1237,9 @@ Frymann et al. [CCS:FGKLMN20] generalized the constructions by Lundberg, Nilsson 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 Brendel et al. [AC:BreCleFis24], Frymann et al. [FryGarMan23] 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], +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.