Skip to content

Commit

Permalink
Merge branch 'main' into review-2024-04-03/ec-arithmetic
Browse files Browse the repository at this point in the history
  • Loading branch information
@emlun
emlun committed Apr 8, 2024
2 parents 4197573 + 67d01d0 commit 0c36de5
Showing 1 changed file with 38 additions and 43 deletions.
81 changes: 38 additions & 43 deletions draft-bradleylundberg-cfrg-arkg.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -45,20 +45,26 @@ normative:
RFC4949:
RFC5869:
RFC6090:
BIP32:
target: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
title: BIP 32 Hierarchical Deterministic Wallets
author:
- name: Pieter Wuille
date: 2012
SEC1:
target: http://www.secg.org/sec1-v2.pdf
author:
- org: Certicom Research
date: 2020
title: SEC 1 Elliptic Curve Cryptography
date: 2009
title: 'SEC 1: Elliptic Curve Cryptography'
SEC2:
target: http://www.secg.org/sec2-v2.pdf
author:
- org: Certicom Research
date: 2010
title: 'SEC 2: Recommended Elliptic Curve Domain Parameters'

informative:
BIP32:
target: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
title: BIP 32 Hierarchical Deterministic Wallets
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
author:
Expand Down Expand Up @@ -121,6 +127,8 @@ We expect that additional instances will be defined in the future.

--- middle

{:emlun: source="Emil"}

# Introduction

Asymmetric cryptography, also called public key cryptography, is a fundamental component of much of modern information security.
Expand Down Expand Up @@ -168,7 +176,7 @@ Some motivating use cases of ARKG include:
- Enhanced forward secrecy for encrypted messaging.
For example, [section 8.5.4 of RFC 9052][rfc9052-direct-key-agreement] defines COSE representations for encrypted messages and notes that
"Since COSE is designed for a store-and-forward environment rather than an online environment,
[...] forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object."
\[...\] forward secrecy (see [RFC4949]) is not achievable. A static key will always be used for the receiver of the COSE object."
Applications could work around this limitation by exchanging a large number of keys in advance,
but that number limits how many messages can be sent before another such exchange is needed.
This also requires the sender to allocate storage space for the keys,
Expand Down Expand Up @@ -362,7 +370,7 @@ The subordinate party will then be able to generate public keys on behalf of the

~~~pseudocode
ARKG-Generate-Seed() -> (pk, sk)
Options:
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.

Expand Down Expand Up @@ -392,7 +400,7 @@ in order to generate any number of public keys.

~~~pseudocode
ARKG-Derive-Public-Key((pk_kem, pk_bl), info) -> (pk', kh)
Options:
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.
MAC A MAC scheme.
Expand All @@ -405,8 +413,9 @@ ARKG-Derive-Public-Key((pk_kem, pk_bl), info) -> (pk', kh)
Inputs:
pk_kem A key encapsulation public key.
pk_bl A key blinding public key.
info Optional context and application specific
information (can be a zero-length string).
info An octet string containing optional context
and application specific information
(can be a zero-length string).

Output:
pk' A blinded public key.
Expand Down Expand Up @@ -440,7 +449,7 @@ in order to derive the same or different secret keys any number of times.

~~~pseudocode
ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
Options:
ARKG instance parameters:
BL A key blinding scheme.
KEM A key encapsulation mechanism.
MAC A MAC scheme.
Expand All @@ -454,8 +463,9 @@ ARKG-Derive-Secret-Key((sk_kem, sk_bl), kh, info) -> sk'
sk_kem A key encapsulation secret key.
sk_bl A key blinding secret key.
kh A key handle output from ARKG-Derive-Public-Key.
info Optional context and application specific
information (can be a zero-length string).
info An octet string containing optional context
and application specific information
(can be a zero-length string).

Output:
sk' A blinded secret key.
Expand Down Expand Up @@ -491,17 +501,17 @@ which can be used to define concrete ARKG instantiations.
## 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]
can use elliptic curve arithmetic as the key blinding scheme `BL` [Frymann2020] [Wilson].
This section defines a general formula for such instantiations of `BL`.

Let `crv` be an elliptic curve.
Then the `BL` parameter of ARKG may be instantiated as follows:

- Elliptic curve points are encoded to and from octet strings
using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC 1][sec1].
using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC1].

- Elliptic curve scalar values are encoded to and from octet strings
using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC 1][sec1].
using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC1].

- `G` is the generator of `crv`.
- `N` is the order of `G`.
Expand Down Expand Up @@ -530,20 +540,20 @@ BL-Blind-Secret-Key(sk, tau) -> sk_tau

## Using ECDH as the KEM {#kem-ecdh}

Instantiations of ARKG can use ECDH [RFC6090] as the key encapsulation mechanism.
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`.

Let `crv` be an elliptic curve used for ECDH.
Then the `KEM` parameter of ARKG may be instantiated as follows:

- Elliptic curve points are encoded to and from octet strings
using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC 1][sec1].
using the procedures defined in sections 2.3.3 and 2.3.4 of [SEC1].

- Elliptic curve coordinate field elements are encoded to and from octet strings
using the procedures defined in sections 2.3.5 and 2.3.6 of [SEC 1][sec1].
using the procedures defined in sections 2.3.5 and 2.3.6 of [SEC1].

- Elliptic curve scalar values are encoded to and from octet strings
using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC 1][sec1].
using the procedures defined in sections 2.3.7 and 2.3.8 of [SEC1].

- `ECDH(pk, sk)` represents the compact output of ECDH [RFC6090]
using public key (curve point) `pk` and secret key (exponent) `sk`.
Expand Down Expand Up @@ -580,7 +590,7 @@ then both of them MAY use the same curve or MAY use different curves.
If both use the same curve, then it is also possible to use the same public key
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.
[^same_key_caveats]{:emlun}


## Using HMAC as the MAC {#mac-hmac}
Expand Down Expand Up @@ -612,14 +622,14 @@ Then the `KDF` parameter of ARKG may be instantiated using HKDF [RFC5869] as fol
~~~pseudocode
KDF(info, ikm, L) -> okm

PRK = HKDF-Extract with the arguments:
prk = HKDF-Extract with the arguments:
Hash: Hash
salt: not set
IKM: ikm

okm = HKDF-Expand with the arguments:
Hash: Hash
PRK: PRK
PRK: prk
info: info
L: L
~~~
Expand Down Expand Up @@ -796,23 +806,6 @@ one can also break the same property of the construction by Frymann et al.
TODO


# References

TODO

TODO: Ask authors for canonical reference addresses



[att-cred-data]: https://w3c.github.io/webauthn/#attested-credential-data
[authdata]: https://w3c.github.io/webauthn/#authenticator-data
[ctap2-canon]: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#ctap2-canonical-cbor-encoding-form
[privacy-cons]: https://www.w3.org/TR/2019/WD-webauthn-2-20191126/#sctn-credential-id-privacy-leak
[rp-auth-ext-processing]: https://w3c.github.io/webauthn/#sctn-verifying-assertion
[rp-reg-ext-processing]: https://w3c.github.io/webauthn/#sctn-registering-a-new-credential



--- back

# Acknowledgements
Expand Down Expand Up @@ -845,3 +838,5 @@ TODO
-01
Editorial Fixes to formatting and references.


[^same_key_caveats]: ISSUE: Caveats? I think I read in some paper or thesis about specific drawbacks of using the same key for both.

0 comments on commit 0c36de5

Please sign in to comment.