spec: Position of ephemeral public key in payload

[johnalanwoods]

Hi,

Reviewing the v1 spec, it seems that Age uses X25519 Ephem:Static ECDH for each new file/message encrypted for a recipients static key.

I infer this from this snippet, which I believe I'm interpreting correctly?

An X25519 recipient line is
-> X25519 encode(X25519(ephemeral secret, basepoint))
encrypt[HKDF[salt, label](X25519(ephemeral secret, public key))](file key)
where ephemeral secret is random(32) and MUST be new for every new file key,
salt is X25519(ephemeral secret, basepoint) || public key,
and label is "age-encryption.org/v1/X25519".

Anyway, what's not seemingly covered in the spec, is the structure of the payload itself.

The header, payload body and (what I expect to see), the ephemeral public key counterpart included in the encrypted payload.

Could someone explain or highlight the part of the spec that describes this?

[FiloSottile]

I am not sure I am interpreting the question correctly, but is this the section you are looking for?

After the header the binary payload is
nonce || STREAM[HKDF[nonce, "payload"](file key)](plaintext)
where nonce is random(16) and STREAM is from Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance with ChaCha20-Poly1305 in 64KiB chunks and a nonce structure of 11 bytes of big endian counter, and 1 byte of last block flag (0x00 / 0x01).

[cyb3rz3us]

Also, I'm confused by use of the term 'ephemeral public key' --- from my understanding, the recipient's public key is used to encrypt the secret key which is used to encrypt the payload.

[johnalanwoods]

I am not sure I am interpreting the question correctly, but is this the section you are looking for?

After the header the binary payload is
nonce || STREAM[HKDF[nonce, "payload"](file key)](plaintext)
where nonce is random(16) and STREAM is from Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance with ChaCha20-Poly1305 in 64KiB chunks and a nonce structure of 11 bytes of big endian counter, and 1 byte of last block flag (0x00 / 0x01).

Hi, yup I think that makes sense, so in the above, is the 'file key' the ephemeral public key needed by the recipient to execute ECDH?

I'm right in my assessment that Age uses Ephem:Static ECDH right? (creating a temp key pair to perform ECDH with the recipient key, and then sending the public piece so the recipient can do the same)...

[johnalanwoods]

Also, I'm confused by use of the term 'ephemeral public key' --- from my understanding, the recipient's public key is used to encrypt the secret key which is used to encrypt the payload.

Yes, the recipients public key is used to "encrypt", however you can't directly encrypt with elliptic curves, instead you must perform a key agreement interaction (elliptic curve diffie-hellman), I suggesting that ECDH is performed with a the recipients static public key and an ephemeral private key on the sender side.

Then the sender must include the ephemeral public key counterpart in the message payload so the recipient can use his static private key to reach the same secret.

@FiloSottile this is correct isn't it? (ps. that's what I'm trying to understand, where in the payload that ephemeral key is included).

[str4d]

The ephemeral public key is this part of the X25519 line:

encode(X25519(ephemeral secret, basepoint))

This is the X25519 RFC equivalent of epk = [esk] G.

[johnalanwoods]

The ephemeral public key is this part of the X25519 line:

encode(X25519(ephemeral secret, basepoint))

This is the X25519 RFC equivalent of epk = [esk] G.

Great that makes sense, so the Epk is in the payload, and it is ephem:static ECDH right?

[str4d]

The epk is the sole argument of the X25519 recipient stanza (which for any recipient type is always at least two lines). The body of the recipient stanza is the encrypted file key, which indeed uses ephemeral-static ECDH followed by HKDF (as documented in the spec). The file key is then used to symmetrically encrypt the age payload.