]> Carnegie Mellon University

riad@cmu.edu

IRTF Crypto Forum secp256k1 dhkem hpke This memo defines DHKEM-secp256k1, a variant of HPKE DHKEM (RFC9180) built on the secp256k1 elliptic curve. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Crypto Forum Research Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction

Motivation The secp256k1 elliptic curve is widely used in blockchain applications. To date, several proposals have sought to allow users to use their keys for encryption. To enable this application, this document specifies a DHKEM mode for use with the secp256k1 elliptic curve. Several implementations appear to have sprung up ad-hoc; this document is written in hope of avoiding fragmentation in the ecosystem, particularly around HPKE KEM suite-id assignments.

Conventions and Definitions 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.

Construction The secp256k1 elliptic curve is specified in , Section 2.4.1. DHKEM is specified in , Section 4. In particular, the Decap, Encap, AuthDecap, and AuthEncap functions for DHKEM are defined in Section 4.1 of that document. The secp256k1 DHKEM construction closely follows NIST-P256 DHKEM. See for the precise specification.

Serializing and deserializing keys Conversion functions in this section are defined in .

• The SerializePublicKey() function uses the uncompressed Elliptic-Curve-Point-to-Octet-String conversion.
• The DeserializePublicKey() function uses the uncompressed Octet-String-to-Elliptic-Curve-Point conversion. Deserialized public keys MUST be validated before they can be used in a manner analogous to the one for NIST-P256 in , Section 7.1.4.
• The SerializePrivateKey() function uses the Field-Element-to-Octet-String conversion. If the private key is an integer outside the range [0, order-1], where 'order' is the order of the curve being used, the private key MUST be reduced to its representative in [0, order-1].
• The DeserializePrivateKey() function uses the Octet-String-to-Field-Element conversion.

DeriveKeyPair The DeriveKeyPair() function is as described in , Section 7.1.3. For this curve, the bitmask value 0xff should be used. The order of the secp256k1 curve as defined in , Section 2.4.1, is 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141.

Security Considerations Please consult the security considerations from .

IANA Considerations This document requests/registers a new entry to the "HPKE KEM Identifiers" registry.

Value:

0x0016 (please)

KEM:

DHKEM(secp256k1, HKDF-SHA256)

Nsecret:

32

Nenc:

65

Npk:

65

Nsk:

32

Auth:

yes

Reference:

,

Normative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. 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.

Acknowledgements The author would like to thank Christopher Wood for his input.

Test Vectors This section contains test vectors formatted similary to the ones found in . These test vectors cover both Base and Auth setup for each of AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. (PSK and AuthPSK are elided because their DHKEM operations are identical to Base and Auth, respectively.)

DHKEM(Secp256k1, HKDF-SHA256) HKDF-SHA256 AES-128-GCM

Base

Auth

DHKEM(Secp256k1, HKDF-SHA256) HKDF-SHA256 AES-256-GCM

Base

Auth

DHKEM(Secp256k1, HKDF-SHA256) HKDF-SHA256 ChaCha20-Poly1305

Base

Auth