DID Auth: client

Overview & Cryptographic Context

This workflow is Part 2 of the four-part DID Auth learning suite (Key Pairs → Client → Server → End-to-End Demo). It models the client side of an ECDH challenge-response authentication protocol: the server sends its P-256 public key and a 32-byte challenge Nonce, and the client must prove possession of the private key corresponding to its DID document public key without ever transmitting the private key.

The client computes the P-256 ECDH shared secret Z (raw_x, 32 B), hashes D = SHA-256(Z) (32 B), splits D into a 16-byte AES-128 key (D[0..16]) and a 16-byte IV (D[16..32]), encrypts the 32-byte challenge nonce with AES-128-CBC (Padding = None), and extracts the first 8 bytes of the final 16-byte ciphertext block (offset = -16, length = 8) as an 8-byte response MAC.

Pipeline Architecture & Wiring Flow

1. Shared Secret Agreement (ECDH Key Agreement): Combines Client Private Key (32 B) and Server Public Key (65 B) on curve p256 to output the 32-byte X coordinate.
2. Key & IV Partitioning (Cryptographic Hash + Byte Slicer × 2): Hashes the shared secret with SHA-256 and slices bytes 0..16 as Key and bytes 16..32 as IV.
3. Challenge Encryption & Truncation (AES Encrypt + Byte Slicer): Encrypts the 32-byte Nonce in CBC mode (Padding = None) and slices 8 bytes from the start of the last ciphertext block (offset = -16, length = 8) to emit MAC alongside Client Public Key.

Nodes & Configuration

Node reference →

Inputs, Outputs & Test Vector Verification

Verification Source: independent implementation: Node crypto (reference/did-auth/did-auth.mjs), no published vector

Inputs

Expected Outputs