Pure Rust implementations of the key-committing (and context-committing) AEADs

Overview

kc-aeads

Pure Rust implementations of the key-committing (and context-committing) AEADs defined in Bellare and Hoang '22.

Crash course on the paper:

  • The UtC transform converts an AEAD into a key-committing AEAD
  • The RtC transform converts a misuse-resistant AEAD into a key-committing misuse-resistant AEAD
  • The HtE transform converts a key-committing AEAD to an context-comitting (aka CMTD-4) AEAD, i.e., an AEAD whose ciphertext-tag output commits to the key, nonce, associated data, and plaintext. This is not the same as key-committing. Using an example from the paper, recall AES-GCM and hence UtC[AES-GCM] has a tag size of 128 bits. If the plaintext is empty, then this the tag is essentially a 128-bit MAC over the authenticated associated data (AAD). This is too short to be binding: for a fixed key an adversary could find two AAD strings which produce a collision in time 2^64. Thus, UtC[AES-GCM] is not AAD-committing (indeed HtE handles AAD entirely differently, using a collision-resistant hash instead of the AEAD).
  • The CX Committing PRF is a PRF constructed from a block cipher. Rather than returning a single output it returns a pseudorandom pair (com, mask). This is used in the construction of UtC.

Roadmap

Low-level things implemented:

  • CX block cipher Committing PRF (maybe not sufficiently secure; see question below)
  • UtC transform
  • RtC transform (not sure if I will; see question 3)
  • HtE transform
    • HtE constructed from a generic MAC (called MacHte)
    • HtE constructed from the HKDF of a generic hash function (called HkdfHte)

High-level things implemented:

  • UtC-transformed AES-128/256-GCM (using HKDF-SHA2 for Committing PRF)
  • HtE-transformed UtC-AES-128/256-GCM (using HMAC-SHA2 or HKDF-SHA2 for MAC)
  • RtC-transformed AES-128-GCM-SIV
  • HtE-transformed RtC-AES-128-GCM-SIV
  • UtC-transformed ChaCha20-Poly1305
  • HtE-transformed UtC-ChaCha20-Poly1305
  • UtC-transformed XChaCha20-Poly1305
  • HtE-transformed UtC-XChaCha20-Poly1305

Questions

  1. Recall HtE "commits" to a nonce and AEAD by computing a MAC over them and using the resulting MAC as an encryption key. If the encryption key size is 128 bits, then this is not a very strongly committing scheme, is it? Does that mean that HtE only gives strong commitment guarantees when the underlying AEAD has 256-bit keys or greater? Does that mean I should implement a key-expanding UtC transform which doubles the key size of the AEAD?
  2. I have the CX[E] PRF implemented to produce 256-bit commitments for AES-128 and 512-bit commitments for AES-256. Is that correct? The reason I think it is is because thoerem 7.2 links key-committing security to "binding" security of the PRF. This comes down to collision resistance in the commitment. On the other hand, proposition 7.1 says that the binding security of CX[E] is limited by the collision resistance of a one-block Davies-Meyer PRF. In that case, this is totally insecure (since block size is 128) and I shouldn't use CX[E] at all.
  3. The main reason I'm using CX is because someone using AES for encryption might reasonable have HW acceleration and want to use AES for PRFs and hashing too. So similar question: what should I use instead of Blake2b in the HtE transform for AES? CMAC/PMAC/CBC-MAC digests are too small.
  4. It appears that RtC (Figure 16) requires the ciphertext to be at least one block long. That's a pain as far as API design goes. Is there a way around this?
  5. Are CAU and CAU-C1 (Section 5) worth implementing? They have really low overhead, but it says explicitly in the discussion that key-commitment can be broken with 2^64 work. If our goal with this library is developer ease-of-use, is that bound sufficiently high?
  6. I have HkdfHte and MacHte. I would much prefer to get rid of HkdfHte because it's strictly more expensive. The only reason it's currently there is because it's a little bit cleaner. Specifically, it offers more opportunities for domain separation and it lets the caller specify the number of bytes it wants (rather than making the caller truncate to get an AEAD key-sized output). These desires might be totally superfluous though.
  7. Similarly, HkdfComPrf is pretty expensive too. It needs to do an Extract operation when being instantiated because the key sizes it receives are too small to do an Expand right away (recall its key sizes are double the bit level they target; why is that?).
  8. What PRFs should I use for the UtC and HtE over ChaCha? I'd like to use Blake2b for the UtC committing PRF and HtE MAC. But the former usage requires more than 64 bytes of digest. Am I doomed to use HKDF-Blake2b for the PRF, just like HKDF-SHA2 in the AES ciphers?
  9. It appears from this comment that ChaCha20-BLAKE3-SIV gets to be almost 2x the throughput of XChaCha20Poly1305. If you just double the SIV tag size (this should cost nothing), you have a fully context-committing AEAD. Why aren't we all just doing that??

Warning

This code has not been audited in any sense of the word. Use at your own peril.

You might also like...
A suite of programs for Solana key management and security.
A suite of programs for Solana key management and security.

🔑 goki Goki is a suite of programs for Solana key management and security. It currently features: Goki Smart Wallet: A wallet loosely based on the Se

🧑‍✈ Version control and key management for Solana programs.

captain 🧑‍✈️ Version control and key management for Solana programs. Automatic versioning of program binaries based on Cargo Separation of deployer a

Plutonium is a two-device chat application that utilises WebSockets and a X25519 ECDH Key Exchange

Plutonium is a two-device chat application that utilises WebSockets and a X25519 ECDH Key Exchange, in addition to AES-256 to securely communicate between the two clients.

Key derivation and cryptographic signing functionality for Ethereum applications (ethers-rs)

ethers-signer-factory ethers-signer-factory is a Rust crate that provides functions for key derivation and signing of Ethereum transactions and messag

Keyhouse is a skeleton of general-purpose Key Management System written in Rust.

Keyhouse Keyhouse is a skeleton of general-purpose Key Management System. Keyhouse is not an off-the-shelf system, and it's not ready for production.

Ethereum key tool - Lightweight CLI tool to deal with ETH keys written in rust

ekt - Etherum Key Tool ekt is a lightweight tool to generate ethereum keys and addresses. Installation Either clone it and run it with cargo or instal

HD wallet BIP-32 related key derivation utilities.

HDWallet Docs HD wallet(BIP-32) key derivation utilities. This crate is build upon secp256k1 crate, this crate only provides BIP-32 related features,

An implementation of the OPAQUE password-authenticated key exchange protocol

The OPAQUE key exchange protocol OPAQUE is an asymmetric password-authenticated key exchange protocol. It allows a client to authenticate to a server

Manage secret values in-repo via public key cryptography

amber Manage secret values in-repo via public key cryptography. See the announcement blog post for more motivation. Amber provides the ability to secu

Owner
Michael Rosenberg
Cryptography PhD student at the University of Maryland. PM me your orphan blocks
Michael Rosenberg
Elliptic-curves - Collection of pure Rust elliptic curve implementations (e.g. P-256, P-384, secp256k1)

RustCrypto: Elliptic Curves General purpose Elliptic Curve Cryptography (ECC) support, including types and traits for representing various elliptic cu

Rust Crypto 386 Dec 27, 2022
OpenZKP - pure Rust implementations of Zero-Knowledge Proof systems.

OpenZKP OpenZKP - pure Rust implementations of Zero-Knowledge Proof systems. Overview Project current implements ?? the Stark protocol (see its readme

0x 529 Jan 5, 2023
X25519 elliptic curve Diffie-Hellman key exchange in pure-Rust, using curve25519-dalek.

x25519-dalek A pure-Rust implementation of x25519 elliptic curve Diffie-Hellman key exchange, with curve operations provided by curve25519-dalek. This

dalek cryptography 252 Dec 26, 2022
Validity is a next-generation, deduction-based language for formally verified, context-aware, autonomous & reactive smart contracts.

Validity Language Validity is a next-generation, deduction-based language for formally verified, context-aware, autonomous & reactive smart contracts.

Tempest Labs 4 Nov 11, 2022
the official Rust and C implementations of the BLAKE3 cryptographic hash function

BLAKE3 is a cryptographic hash function that is: Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2. Secure, unlike MD5 and SHA-1. And secure again

BLAKE3 team 3.7k Jan 6, 2023
Making composability with the Zeta DEX a breeze, FuZe provides CPI interfaces and sample implementations for on-chain program integration.

Zeta FuZe ?? Zeta FuZe FuZe is Zeta's cross-program integration ecosystem. This repository contains the Zeta Cross Program Invocation (CPI) interface

Zeta 39 Aug 27, 2022
A Boring(SSL)-compatible API abstraction for Rust cryptographic implementations.

A Boring(SSL)-compatible API abstraction for Rust cryptographic implementations. What is Superboring? Superboring hides the complexity, diversity and

Frank Denis 7 Dec 29, 2023
Cryptography-oriented big integer library with constant-time, stack-allocated (no_std-friendly) implementations of modern formulas

RustCrypto: Cryptographic Big Integers Pure Rust implementation of a big integer library which has been designed from the ground-up for use in cryptog

Rust Crypto 88 Dec 31, 2022
A bridge between different serde implementations.

serde-bridge   Bridge between serde types Quick Start use anyhow::Result; use serde_bridge::{from_value, into_value, FromValue, IntoValue, Value}; fn

Xuanwo 14 Nov 24, 2022
A safe implementation of the secure remote password authentication and key-exchange protocol (SRP), SRP6a and legacy are as features available.

Secure Remote Password (SRP 6 / 6a) A safe implementation of the secure remote password authentication and key-exchange protocol (SRP version 6a). Ver

Sven Assmann 10 Nov 3, 2022