Edge Protocol

Purpose

Edge Protocol provides a secure foundation for crypto-systems without requiring persistent private-key storage. It enables:

• Stateless private-key derivation

• Self-validating IDs

• Expiring and associative identifiers

• Secure signatures and data encryption

Design Goals

• Use only standardized cryptographic primitives

• Avoid private-key storage

• Ensure constant-time operations

• Provide compact, tamper-resistant identifiers

• Support expiration and hierarchical relationships

• Enable deterministic, reproducible key derivation

• Allow generic arguments so that users won't be locked in to a specific curve or hash function

Cryptographic Primitives

The Edge Protocol is implemented using Rust generics, allowing developers to supply any compatible algorithms from the RustCrypto ecosystem. This includes:

• Any ECC curve implementing the elliptic-curve traits (e.g. P-256, P-384).

• Any hash function implementing the Digest trait for HKDF or MAC constructions.

• Any ChaChaXRng from chacha20.

This design ensures that the protocol is not tied to a specific curve, hash function, or RNG. Implementers can choose primitives that match their performance, security, or compliance requirements while preserving the protocol's structure and guarantees.

Another note: because this library was created with prerelease versions of RustCrypto crates, you may have to use specific prerelease versions of RustCrypto crates.

ECDH

Used for key agreement for encrypting and decrypting requests and responses.

ECDSA

Used for signing and verifying requests and responses.

HKDF

Used to derive private keys and symmetric keys from:

• Curve name

• Key ID

• Epoch-specific salt

• Purpose enumerator

MAC (HMAC or CMAC)

Used to validate IDs, detect tampering, and authenticate requests.

ID Structure

Each ID consists of:

• Pre-MAC portion:

  • Optional prefix with predetermined length

  • Flag indicating whether associated data was used

  • Flag determining whether the ID is expiring

  • Optional timestamp and epoch counter with predetermined length

• MAC portion:

  • ID-type-specific variable-length MAC, of length m

This structure provides:

• 2^(8m) possible MAC outputs

• Guaranteed detection of MAC tampering

• Near-guaranteed detection of ID forgery or modification

Key Derivation

Private keys are derived using HKDF:

let salt = csprng.generate_epoch_salt(epoch, purpose);
let mut key = [0u8; 48];
private_key = hkdf.extract(&mut key, &[salt, curve, key_id, associated_data]);

This allows:

• Stateless regeneration

• Purpose-bound keys

• Epoch-isolated key spaces

Implementation Note:

In the current version, the CSPRNG generates rotating salts that are fed into HKDF as part of the info parameter. A future revision will instead generate rotating HKDF and MAC keys directly and maintain them in a small LRU cache for improved clarity and security.

Associative IDs

IDs can be linked by including one ID within another's MAC input or HKDF info parameter. This enables:

• Client-specific or server-specific keys

• Hierarchical or chained identifiers

• One-way binding between IDs

Even if two IDs share identical prefixes and MACs, their derived private keys will differ when associated data is incorporated into the derivation.

Expiring IDs

Expiration timestamps are embedded using:

• Epoch counters

• Right-shifted timestamps to reduce size

• Time deltas between epoch start and the expiration time

This enables compact, self‑contained expiration semantics without server‑side state. The exact right‑shift amount, timestamp bit‑width, and epoch/version bit allocation are configurable through the VersionConfig (this will later be named the EpochConfig or RotationConfig). These parameters allow IDs to be made extremely compact, but misconfiguration can lead to premature timestamp rollover or insufficient representable lifetime. Careful selection of these values is required to ensure long‑term system usability.

Data Encryption

Symmetric keys are derived using HKDF with the data's ID, index key, or path as input. Nonces are prefixed to the ciphertext, and pseudorandom nonces are preferred for simplicity and safety.

Limitations and Future Work

• MAC length tradeoffs:

Shorter MACs reduce ID size but increase collision and forgery probability.

• Rotating salts in HKDF info:

Version 1 uses epoch-specific salts in the HKDF info parameter. While the salts remain private and are generated by a secure CSPRNG, this design introduces a low-risk vulnerability due to the intended use of the info field. A future revision will replace salts with rotating HKDF and MAC keys generated by the CSPRNG.

• RustCrypto ecosystem stability:

The next version of the Edge Protocol will be implemented once the RustCrypto crates reach their next stable minor release, replacing the current prerelease-based implementation.