<br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 13:49, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The plan is to have a encryption with integrity mode that doesn't require GCM.<br>
<br>
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.<br>
The content is AES CBC 128 encrypted (as an example).  Then a HMAC is calculated over the encrypted body using the integrity key.<br></blockquote><div><br></div><div>Excellent.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
To decrypt the process is reversed.<br>
<br>
Assuming that you are using symmetric keys the one composite operation gets you encryption integrity and verification of the sender.<br>
<br>
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.<br></blockquote><div><br></div><div>Again, our assessment is that we don't see any safe usage of JWT encryption that is not an authenticated encryption mode. I assume that means we fully support these changes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
John B.<br>
<div><div class="h5">On 2012-01-12, at 6:29 PM, Breno de Medeiros wrote:<br>
<br>
> 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.<br>

><br>
> 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.<br>

><br>
> 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:<br>

><br>
> "This document does not specify a combination signed and encrypted<br>
>   mode.  However, because the contents of a message can be arbitrary,<br>
>   encryption and data origin authentication can be provided by<br>
>   recursively encapsulating multiple JWE and JWS messages.  In general,<br>
>   senders SHOULD sign the message and then encrypt the result (thus<br>
>   encrypting the signature).  This prevents attacks in which the<br>
>   signature is stripped, leaving just an encrypted message, as well as<br>
>   providing privacy for the signer."<br>
><br>
> 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.<br>

> 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,<br>

> then sign (or authenticate) again. Which is terribly inefficient.<br>
><br>
> In other words, in our security review, the only usable mode for JWT encryption defined today is AES-GCM. Which is not generally available.<br>
><br>
> Is that the desirable state of things? Because if so, we plan to define some other way to use encryption with JWT instead.<br>
><br>
> --<br>
> --Breno<br>
><br>
</div></div>> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>--Breno<br>