Public-key authenticated encryption using static-static ECDH

[codedust]

Sometimes, we want to ensure the authenticity of a message's origin without the need of a pre-shared secret. This can simply be achieved in JOSE by using asymmetric signatures. However, if signed data is leaked, a third party (the attacker) can also verify the message's authenticity, which is problematic in several use-cases (e.g. in the case of a leakage of signed bank details). Therefore, asymmetric signatures cannot be used when repudiation is a design goal. Ensuring the a message's origin can also be achieved using public-key authenticated encryption.

This library already implements symmetric-key authenticated encryption with associated data (AEAD). This guarantees authenticity in scenarios where a symmetric key has been exchanged beforehand via a secure channel and mitigates a number of attack vectors.

In contrast, public-key authenticated encryption using static-static elliptic curve Diffie-Hellman key agreement allows the receiver to verify a messages' origin (identified by their public key) without the need of a pre-shared-secret. However, it is currently not (easily) possible to achieve public-key authenticated encryption using this library.

By design, the ECDH* algorithms already authenticate messages using the sender's secret key and the receiver's public key (by performing a ECDH key agreement with these keys to derive a symmetric key which is then used for symmetric AEAD).

As per JWE specification, the sender includes its public key in the encrypted message (epk header). This later allows the receiver to derive the same symmetric key by performing a ECDH key agreement with the sender's public key and the reiceiver's private key.

In order to achieve public-key authenticated encryption, it would be great if this library provided an easy way to validate that the sender's public key matches the key from the epk header. This could easily implemented by users of the library by manually comparing these two keys. However, this requires a lot of expert knowledge on how asymmetric AEAD works.

The NaCl library provides a nice "box" interface that encourages/enforces to implicitly check the sender's public key: https://nacl.cr.yp.to/box.html

Here's a shot example that shows how this could be implemented in this library, too:

// let's send a message from Alice to Bob
const keyPair_Alice = await generateKeyPair('ECDH-ES', { 'crv': 'P-384' })
const keyPair_Bob = await generateKeyPair('ECDH-ES', { 'crv': 'P-384' })

const jwe = await new FlattenedEncrypt(
  new TextEncoder().encode(
    'It’s a dangerous business, Bob, going out your door.'
  )
)
  .setProtectedHeader({ alg: 'ECDH-ES+A256KW', enc: 'A256GCM' })
  .setKeyManagementParameters({'epk': keyPair_Alice.privateKey})
  .encrypt(keyPair_Bob.publicKey)

// this decrypts correctly, but Bob has not verified that the message came from Alice
const { plaintext, protectedHeader } = await FlattenedDecrypt(jwe, keyPair_Bob.privateKey);

// NEW: this only decrypts correctly if Alice's public key was used in the `epk` header
const { plaintext, protectedHeader } = await FlattenedAuthenticatedDecrypt(jwe, keyPair_Bob.privateKey, keyPair_Alice.publicKey);

What do you think?

[panva]

In order to achieve public-key authenticated encryption, it would be great if this library provided an easy way to validate that the sender's public key matches the key from the epk header.

ECDH-ES is not meant, designed, or vetted to be used for public-key authenticated encryption. Adding an API to support such use of ECDH-ES doesn't seem like a good idea to me. You can see that in the docs that setKeyManagementParameters, which you use in your example to have a specific key (re)used as epk, is not meeting its intended use either, it is only really intended for test and vector validation purposes. If it wasn't for Agreement PartyUInfo and Agreement PartyVInfo in ECDH-ES or p2c in PBES2 I wouldn't even have added this API so I'm thinking I'll actually deprecate it.

This could easily implemented by users of the library by manually comparing these two keys. However, this requires a lot of expert knowledge on how asymmetric AEAD works.

Usually one would resort to a signed (JWS), then encrypted (JWE) structure. This of course increases the overhead and size of resulting messages.

@NeilMadden was proposing a JWE algorithm for a public key authenticated encryption. I am not sure what state that I-D is in, if it's safe to use and interoperable, and if it's ever going to get published but it is something I may consider if there's wider library support for it in other languages.

[codedust]

Thanks for your thoughts! You're absolutely right about the re-use of the ephemeral key here. That's not ideal at all.

Usually one would resort to a signed (JWS), then encrypted (JWE) structure. This of course increases the overhead and size of resulting messages.

That would not really solve the problem here, since this results in (undesirable) stronger third-party verification and non-repudiation properties of asymmetric digital signatures.

Instead, when repudiation is a design goal, I cannot think of another way than using public-key authenticated encryption (PKAE).

I wasn't aware of the ECDH-1PU proposal. That's nice! @NeilMadden: Can you tell us more about the status of this draft?

Also, I've just discovered this blog post that exactly covers many of the issues I have with the current design of the JOSE framework (and many more!). I was exactly thinking of the OIDC use case here! Thanks @NeilMadden for the great writeup!

(I also found this (outdated) OIDC Authentication Draft that implements a DH key agreement to authenticate messages but it's not very JOSE-ish).

Any other ideas on how to achieve PKAE using JOSE? Signing the ephemeral epk in ECDH-ES-A***KW might be an option but that feels a bit hacky.

[codedust]

Somewhat related: It might be a good idea to split the algorithm selection guide's "Authenticated Encryption" section into two separate sections:

• "Authenticated Encryption" with all the symmetric AEAD algorithms
• "Public-Key Encryption" with all the non-authenticated public-key algorithms

[panva]

Feel free to make concrete suggestions, edits - here's the source in a gist that you can fork and modify. https://gist.github.com/panva/a085be6472d1c05af67d3e5f8dd17465

[codedust]

Thanks! I've just forked and updated the gist: https://gist.github.com/codedust/b69ebb3be60490e8ddc4f1cabf76ec90

What do you think?

[panva]

@codedust thank you for the proposal, I will update the pinned article.

[panva]

done.

[CMCDragonkai]

A question about this part:

Do not use Public/Private key pair schemes when you're both the issuer and recipient, better use direct symmetric encryption in such case.

I'm looking into https://eprint.iacr.org/2021/509.pdf that is using Ed25519 converted to X25519 for KEM.

The suggested route is to do the DH exchange to get the X25519 shared secret, then HKDF-extract to get an key that can be used for encryption.

If I'm doing this, it makes more sense to just use the dir mode right?

I checked the ECDH-ES code inside jose and it seems different from what is suggested, even though I can convert the Ed25519 keys to X25519 keys and plug that into ECDH-ES mode. Not sure which is the better route.