Session Key Derivation

Every SwiftDrop transfer uses a unique session key derived fresh from an ephemeral key exchange. This page documents the exact derivation algorithm used in SwiftDrop protocol v3.

Full derivation flow

1.  Sender   generates: (sk_s, pk_s)  ← X25519 ephemeral key pair
2.  Receiver generates: (sk_r, pk_r)  ← X25519 ephemeral key pair
3.  pk_s sent to receiver  (in HELLO frame)
4.  pk_r sent to sender    (in KEY_EXCHANGE frame)

5.  shared_secret = X25519(sk_s, pk_r)   ← computed by sender
    shared_secret = X25519(sk_r, pk_s)   ← computed by receiver
    (both arrive at the same value)

6.  session_key = HKDF-SHA256(
       ikm  = shared_secret,
       salt = "swiftdrop-v3",
       info = "session-key",
       len  = 32 bytes
    )

7.  sk_s and sk_r are discarded immediately after derivation.

Why HKDF?

Raw ECDH output has structure that could be exploited. HKDF (HMAC-based Key Derivation Function, RFC 5869) conditions the shared secret into a uniformly random key suitable for AES. It also binds the key to a context string ("swiftdrop-v3") to prevent cross-protocol attacks.

Nonce strategy

Each AES-256-GCM operation requires a unique nonce. SwiftDrop derives nonces deterministically from the frame counter:

nonce[i] = left-pad(big-endian(frame_counter_i), 12 bytes)

Since each session key is used for exactly one transfer, the nonce space (2^96) is never exhausted.

Protocol version history

v3 is the current protocol. Devices running v1 or v2 are not compatible with v3.