[Openid-specs-ab] JWT encryption

Dirk Balfanz balfanz at google.com
Thu Jan 12 22:27:05 UTC 2012

On Thu, Jan 12, 2012 at 1:49 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> The plan is to have a encryption with integrity mode that doesn't require
> GCM.
> You create a content master key and key wrap that (Symmetric or
> Asymmetric).  That key is used with a KDF to crate 2 keys,  a content
> encryption key and a integrity key.
> The content is AES CBC 128 encrypted (as an example).  Then a HMAC is
> calculated over the encrypted body using the integrity key.

This sounds good. One question: if the key I want to use to
encrypt-and-sign is already a, say, 128-bit symmetric key, then creating
another 128-bit "master" key (which needs to be wrapped) and KDF-ing the
signer and encrypter from that seems like overkill. Why not just KDF the
signer and encrypter directly from my original key? It makes the spec more
complex (in some cases you can skip the wrapping of the master key, and
some you can't), but shipping an extra key around when you don't need to is
no fun...


> To decrypt the process is reversed.
> Assuming that you are using symmetric keys the one composite operation
> gets you encryption integrity and verification of the sender.
> This will be added to a upcoming draft of JOSE (if there is support).
> The fist JOSE draft will not have normative changes from the existing input
> specs.
> If you want to use asymmetric keys you will still need to do a separate
> signing step.  It can be inside or outside the encryption depending on use
> case.
> John B.
> On 2012-01-12, at 6:29 PM, Breno de Medeiros wrote:
> > This is feedback related to the JWT Encryption/JWS specs. I am
> submitting this here because we're reviewing the whole stack. Independently
> of the Connect implementation, we are working on a different project that
> uses JWT encryption.
> >
> > In this first usage of JWT encryption, we need integrity-protected
> encrypted payloads. We do not need non-repudiation. The underlying
> libraries do not have support for AES-GCM. We don't expect the latter
> reality to change for a number of years since the clients have a slow
> update cycle.
> >
> > The JWT Encryption/JWS spec do appear to support this use case. Note
> that to have integrity encrypted data, one needs to perform
> encryption-then-authentication, since that is the correct order to compose
> these primitives. So my first observation is that this security
> recommendation in the JWT encryption spec is factually incorrect when
> referring to symmetric authentication schemes as opposed to public key
> signatures:
> >
> > "This document does not specify a combination signed and encrypted
> >   mode.  However, because the contents of a message can be arbitrary,
> >   encryption and data origin authentication can be provided by
> >   recursively encapsulating multiple JWE and JWS messages.  In general,
> >   senders SHOULD sign the message and then encrypt the result (thus
> >   encrypting the signature).  This prevents attacks in which the
> >   signature is stripped, leaving just an encrypted message, as well as
> >   providing privacy for the signer."
> >
> > In addition, the JWT Encryption/JWS recommends Sign-then-encrypt, which
> provides confidentiality of signed data, but does not provide integrity of
> the encrypted data. So in some scenarios you could attack the encryption
> layer by sending random data and forcing it to decrypt blindly. The
> signature verification step performed after the decryption may be too late.
> > Again, to protect the encryption layer, one should encrypt then
> sign/authenticate.  So if one wants to have both confidentiality and
> non-repudiation which the JWT/JWS specs are designed to support) and
> AES-GCM is not available (as the case in the next few years depending on
> which environment you're targeting), the only way to use the JWT/JWS specs
> securely is to sign, then encrypt,
> > then sign (or authenticate) again. Which is terribly inefficient.
> >
> > In other words, in our security review, the only usable mode for JWT
> encryption defined today is AES-GCM. Which is not generally available.
> >
> > Is that the desirable state of things? Because if so, we plan to define
> some other way to use encryption with JWT instead.
> >
> > --
> > --Breno
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120112/8227daff/attachment.html>

More information about the Openid-specs-ab mailing list