Skip to content

Latest commit

 

History

History
57 lines (46 loc) · 5.3 KB

dev-notes.md

File metadata and controls

57 lines (46 loc) · 5.3 KB
Raw

Development Notes

We are iteratively developing a proof of concept in the single-server setting. In the first phase, we focus on basic support for arbitrary secrets. In the second phase, we extend the system to support signing keys.

Page Contents

  1. Arbitrary Secrets
  2. Signing Keys
  3. Cryptographic Protocol and Implementation Dependencies

Arbitrary Secrets

We want to build a general-purpose, human-centric system that stores and retrieves secrets on a single server. The resulting proof of concept (PoC) will include basic cryptography to realize an end-to-end encrypted storage of arbitrary secrets. This constitutes a fundamental building block of our larger imagined digital asset management system.

Basic support for arbitrary secrets includes:

  • Local generation of secrets, where the generated secret is by default stored both locally and remotely at the key server;
  • Retrieving a key from the key server;
  • Importing an externally-generated key into the system for storage at the key server;
  • Exporting a key from the system; and
  • Obtaining an audit log of the asset owner's system and key use activity.

As part of completion of our first development phase, we are implementing a working command-line demo with cryptography for handling arbitrary secrets for the above workflows.

Extended support for arbitrary secrets includes:

  • Remote-only generation and storage of secrets, where the secret is generated and stored entirely at the key server.

For more details on the above, see Arbitrary Secrets Overview.

Signing Keys

We want our system to include support of signing keys. In this phase, we will include support for basic ECDSA signing key generation and use.

As part of this phase, we will extend our existing system functionalities to include:

  • Remote generation and storage of secrets, without local storage.
  • Generic support for generation and use of signing keys. Uses will include retrieval, import/export, generating signatures, and obtaining audit logs.

Cryptographic Protocol and Implementation Dependencies

We have the following dependencies:

  • We instantiate the asymmetric password-based authenticated key exchange protocol with OPAQUE. We are using opaque-ke, which currently implements version 09 of the IETF RFC. This library is under active development, as is the IETF draft. An earlier release of this repository has been audited by NCC Group in June 2021.
    • This implementation relies on voprf, which is tracking the IETF RFC on OPRFs.
    • As both of the above RFCs are in flux, we expect ongoing updates.
    • Following the terminology of the RFC, we use the following OPAQUE-3DH configuration: OPRF(ristretto255, SHA-512), HKDF-SHA-512, HMAC-SHA-512, SHA-512, ristretto255, with Argon2 as the KSF, and no shared context information.
  • TLS 1.3.
    • TODO #22: Select and add config, setup, and implementation dependency information.
  • Cryptographic Hash Function Hash. We use SHA3-256 throughout in our constructions, as implemented in sha3 by RustCrypto.
  • CSPRNG, rng.
  • Symmetric AEAD scheme. We are using chacha20poly1305 by RustCrypto, which implements RFC 8439. This library is under active development. An earlier release of this repository was audited by NCC Group in February 2020.
    • This scheme uses a 256-bit pseudorandom key. There are no further requirements on the format or properties of the key.
    • This implementation will not execute in constant time on processors with a variable-time multiplication operation.
  • HMAC-based key derivation function. We use hkdf by RustCrypto, which implements RFC 5869.
  • A message authentication code (MAC).
  • Cryptographic signing primitives:
    • ECDSA on secp256
    • Ed25519 (i.e., EdDSA on edwards25519).
    • TODO #49: Propagate implementation decisions here.