Re: [Cfrg] Multi-recipient public key authenticated encryption

[Paul Grubbs <[e-mail]>]

This sounds like a really interesting question, but I'm having trouble
understanding your proposed scheme - can you give a bit more detail?

I also don't quite understand the threat model. Are you trying to prevent a
malicious receiver from "forging" a new payload that looks like it came
from the sender?

On Mon, Apr 27, 2020 at 10:12 AM Neil Madden <[e-mail]>
wrote:

> Hi all,
>
> I am working on an enhancement to the JOSE standards and would like
> feedback from members of CFRG about solutions to a particular issue if any
> of you have time.
>
> In JOSE currently if you wish to create a message that has both
> confidentiality and sender authentication using public key cryptography
> then the only option is to both sign and then encrypt the message. This is
> expensive because it involves multiple passes over the message and results
> in a very bulky nested message structure with two layers of base64-encoding.
>
> Given that many uses of this sign-then-encrypt pattern do not require the
> strong security properties of signatures, I have proposed [1] a public key
> authenticated encryption mode based on NIST’s one-pass unified model from
> SP 800-56A. This avoids the nested structure and means that you don’t need
> multiple cryptographic primitives. The proposed algorithm uses two ECDH key
> agreements: one between the sender’s ephemeral private key and the
> recipient’s long-term public key; and a second between the two parties’
> long term keys. The two shared secrets are concatenated and passed through
> a KDF along with some context arguments. For a single recipient this
> achieves sender authentication (subject to replay), and the single
> recipient case is what I am primarily concerned about.
>
> (If you squint this is also roughly similar to the Noise framework “K”
> one-way pattern, but my hands are waving quite a lot here).
>
> To support multiple recipients I copied the existing pattern used in
> JOSE’s ECDH-ES+A256KW algorithm family in which the message is encrypted
> using a random Content Encryption Key (CEK) and then the CEK is encrypted
> for each recipient using AES-KeyWrap with the ECDH-derived key. As I then
> mention in the security considerations this leads to any recipient being
> able to produce a forgery using that CEK and claim it came from the
> original sender:
>
>    When Key Agreement with Key Wrapping is used, with the same Content
>    Encryption Key (CEK) reused for multiple recipients, any of those
>    recipients can produce a new message that appears to come from the
>    original sender.  The new message will be indistinguishable from a
>    genuine message from the original sender to any of the other
>    participants.  To avoid this attack, the content SHOULD be encrypted
>    separately to each recipient with a unique CEK or a nested signature
>    over the content SHOULD be used.
>
>
> Because I am primarily interested in single-recipient use cases, this
> seemed like an acceptable trade-off. However, I have since been contacted
> by people who would like to use this draft for multi-recipient messages and
> would not like to fall back on a nested signature structure.
>
> An initial proposal was to solve this by simply including the MAC tag from
> the content encryption in either the per-recipient payload (encrypted using
> AES-KeyWrap) or as an additional context field to the KDF. But the MAC is
> computed using the CEK that is known to all recipients, so for this to be
> secure would require second preimage resistance of the MAC with a known
> key, which cannot be guaranteed for JOSE because it supports content
> encryption using AES-GCM for which second preimages can be trivially
> computed if you know the key.
>
> Assuming that a per-recipient MAC is too much overhead, an alternative
> would be to include a collision-resistant hash of entire ciphertext (and IV
> and associated data) in the KDF. This is unfortunate as it requires another
> pass over the entire message when we’ve already encrypted and MACed, but it
> appears to be a solution and at least is no more inefficient than the
> original signed-then-encrypted approach which also needs to hash the entire
> message.
>
> So two questions:
>
> 1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming
> symmetric AE) in the per-recipient KDF calculation sufficient to prevent
> forgeries in the multi-recipient setting?
>
> 2. Are there more efficient alternatives that don’t assume 2nd preimage
> resistance of the underlying symmetric MAC?
>
> [1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03
>
> Kind regards,
>
> Neil Madden
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>