[Openid-specs-ab] Encryption
John Bradley
ve7jtb at ve7jtb.com
Mon Oct 31 20:16:04 UTC 2011
The more options the more likely people will get it wrong.
I could live with SHA256 being the default KDF hash and SHA512 being used for any key over 256bits.
Though it is debatable if changing the KDF hash is more of a performance issue or a security one.
Again for encryption keys SHA256 for keys up to 256 bits and SHA512 for keys over 256bits.
Normally you are the one arguing for simplicity not me:)
Thought needs to go into this and some tradeoffs selected.
We could also consider including a public seed for the KDF in the envelope to vary signing and integrity keys derived from a static secret.
Perhaps useful but an
We are actually going to need a KDF anyway to go from a ECDH-ES negotiated key to a 256bit (or other length) key for bulk encryption.
John
On 2011-10-31, at 4:42 PM, Breno de Medeiros wrote:
> On Mon, Oct 31, 2011 at 11:02, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> I am not opposed to it.
>>
>> However there are multiple details that need to be sorted out.
>>
>> If we are going that far, you probably don't want to use the same key for
>> encrypting and integrity.
>>
>> That would argue for a KDF to be used to crate multiple keys from a master.
>>
>> Not hard ConcatKDF would work specifying different use strings.
>>
>> Though that may not be available packaged everywhere it is easy enough to
>> make one if you have SHA256.
>>
>> This opens questions of specifying KDF
>> Specifying hash for KDF (some default to SHA1 and others SHA256)
>>
>> Specifying the integrity HMAC alg.
>>
>> So complexity can get out of control.
>>
>> I think we could do something like say always:
>> 1. concatKDF with a MAC of SHA256
>> 2 "Encrypt" as the U input for encryption key
>> 3 "Integrity" as the U input for the integrity key
>> 4 The HMAC is SHA256
>> 5 The HMAC is calculated over the base64url encoded envelope, key wrap, and
>> message when directly concatenated together in that order.
>> 6 the base64url encoded output is prepended with a period and appended to
>> the first three segments to form a JWE.
>
> At the very least we need to specify a companion MAC algorithm for
> each encryption scheme. For instance, if someone is using a 512-bit
> encryption key (conceivably in the future that will happen) the MAC
> should use a 512-bit key as well. I am fine if the coupling of
> encryption and mac is hard, i.e., specifying the encryption algorithm
> automatically specifies the MAC algorithm. But having a single MAC
> algorithm for all ciphers doesn't work.
>
> The same goes for the hash algorithm in the KDF.
>
>>
>> That adds 13 bytes to each JWE so that is not an issue.
>>
>> While for us it may be nice to have lots of knobs to fiddle with, we should
>> pick one way to add integrity to keep it simple for developers.
>>
>> It will add some complexity though arguably necessary if you want privacy &
>> integrity.
>> This is new functionality over John Panzer's proposal.
>>
>> I am good with documenting this proposal if you are:)
>>
>> John B.
>> On 2011-10-31, at 2:07 PM, Breno de Medeiros wrote:
>>
>> On Mon, Oct 31, 2011 at 10:03, John Bradley <jbradley at mac.com> wrote:
>>
>> Is encryption with integrity better? Yes.
>>
>> Without AES GCM being available in common libraries we need to force a
>> composite operation doing both encryption and HMAC.
>>
>> The additional cost is negligible.
>>
>>
>> That is arguably not necessary if the thing you are encrypting is already
>> signed. (as long as you don't leave your implementation open to a padding
>> oracle attack)
>>
>> That happens at a different layer. It's basic rule-of-thumb in
>> cryptography design that having security provide by loosely coupled
>> layers that moreover are designed for independent re-use is risky and
>> likely to introduce vulnerabilities in unanticipated (but valid) use
>> cases.
>>
>>
>> There is a fair argument for forcing HMAC if not using GCM or an equivalent.
>> It however adds complexity and likely forces us to add an additional
>> segment.
>>
>> Envelope.wraped_key.content.HMAC
>>
>> That's not optional complexity in my view.
>>
>>
>> You probably want the HMAC to be over all three proceeding elements, that is
>> why I put it on the end.
>>
>> That is too big a change to get in before the upcoming IETF meeting though
>> we should probably start that discussion.
>>
>> The alternative is getting GWC into a shipping version of openssl and other
>> libraries. (I think bouncy castle is OK)
>>
>> John
>>
>> On 2011-10-31, at 1:50 PM, Breno de Medeiros wrote:
>>
>> I remember repeatedly arguing that non-mac'ed symmetric encryption was
>>
>> not useful and that the JWE spec should _not_ specify how to do that.
>>
>> On Sat, Oct 29, 2011 at 10:26, Mike Jones <Michael.Jones at microsoft.com>
>> wrote:
>>
>> I don't have a specific patch proposal at this time. Nat or John or Axel
>> (or any of the rest of you!), if any of you are able to help Rob add GCM
>> support to the PHP release in the short term, that could be a huge win.
>>
>> -- Mike
>>
>> -----Original Message-----
>>
>> From: Rob Richards [mailto:rrichards at cdatazone.org]
>>
>> Sent: Saturday, October 29, 2011 3:17 AM
>>
>> To: Mike Jones
>>
>> Cc: Anthony Nadalin; Axel.Nennker at telekom.de; jbradley at mac.com;
>> openid-specs-ab at lists.openid.net
>>
>> Subject: Re: [Openid-specs-ab] Encryption
>>
>> Mike,
>>
>> Do you have a patch for the support already? As long as there's no BC issues
>> I might be able to get it into the 5.4 candidate before it's released. I had
>> just started looking at adding support due to the xml enc issue but would be
>> extremely helpful if you already had a patch.
>>
>> Also if you happen to know which openssl versions the patch works with as it
>> appears there are a number of ways to use GCM depending upon the version.
>>
>> Rob
>>
>> On 10/28/11 12:18 PM, Mike Jones wrote:
>>
>> We pretty much reached the same conclusion during the encryption working
>> group session at IIW. The only problem, as Nat pointed out, is that PHP
>> libraries, as currently distributed, do not support GCM (although the
>> underlying OpenSSL libraries that PHP uses do). Of course, maybe we can use
>> this as a forcing function to get PHP to support GCM by default (without
>> requiring recompilation, which is possible now).
>>
>> -- Mike
>>
>> -----Original Message-----
>>
>> From: openid-specs-ab-bounces at lists.openid.net
>>
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony
>>
>> Nadalin
>>
>> Sent: Friday, October 28, 2011 9:13 AM
>>
>> To: Axel.Nennker at telekom.de; jbradley at mac.com
>>
>> Cc: openid-specs-ab at lists.openid.net
>>
>> Subject: Re: [Openid-specs-ab] Encryption
>>
>> As I see it we need to require the GCM mode of operation (an authenticated
>> encryption mode) for AES (moving AES-GCM from option to mandatory).
>>
>> -----Original Message-----
>>
>> From: openid-specs-ab-bounces at lists.openid.net
>>
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>
>> Axel.Nennker at telekom.de
>>
>> Sent: Friday, October 28, 2011 8:55 AM
>>
>> To: jbradley at mac.com
>>
>> Cc: openid-specs-ab at lists.openid.net
>>
>> Subject: Re: [Openid-specs-ab] Encryption
>>
>> Here is the link to the paper:
>>
>> http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBr
>>
>> eakXMLenc.pdf
>>
>> The authors recommend "One possibility to avoid our attack is to use a
>> symmetric cryptographic primitive that does not only provide
>> confidentiality, but also integrity. This can for instance be achieved by
>> replacing the CBC mode of operation with a mode that provides message
>> integrity. Adequate choices have for instance been standardized in ISO/IEC
>> 19772:2009. We consider this solution as very recommendable for future
>> versions of the XML Encryption standard. Unfortunately, this may bring
>> deployment and backwards compatibility issues."
>>
>> http://www.iso.org/iso/catalogue_detail?csnumber=46345
>>
>> -Axel
>>
>> -----Original Message-----
>>
>> From: John Bradley [mailto:jbradley at mac.com]
>>
>> Sent: Freitag, 28. Oktober 2011 16:22
>>
>> To: Nennker, Axel
>>
>> Cc: Nat Sakimura; Michael Jones; openid-specs-ab at lists.openid.net
>>
>> Subject: Re: [Openid-specs-ab] Encryption
>>
>> We don't encryption it, but we do support it.
>>
>> I haven't seen the original paper only analysis of it.
>>
>> Mike should be able to get it.
>>
>> I don't think we should panic. I have known about this for a week or so.
>>
>> While the problem involves CBC it is not necessarily a CBC algorithm
>> vulnerability in itself.
>>
>> The problem is likely the xmlenc API error messages and having them reported
>> back over SOAP.
>>
>> As long as we are careful about not communicating too much in the error
>> message and implementers protect against side channel timing attacks, JWE
>> probably is OK as is with appropriate security considerations.
>>
>> I would be surprised if the attack works agains AES-CBC + RSA.
>>
>> It also probably is ineffective agains AES-CBC+keywrap.
>>
>> Yes GWC is better that is why it was created.
>>
>> We need the paper before trying to fix things that may not need fixing.
>>
>> John B.
>>
>>
>>
>>
>> On 2011-10-28, at 10:13 AM, Axel.Nennker at telekom.de wrote:
>>
>> Do we actually require encryption in the openid connect standards? I thought
>> we refer to JWS and JWS and that's it?
>>
>> Axel
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: openid-specs-ab-bounces at lists.openid.net
>>
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of
>>
>> sakimura
>>
>> Sent: Freitag, 28. Oktober 2011 13:36
>>
>> To: Mike Jones; John Bradley; Anthony Nadalin; Openid specs ab
>>
>> Subject: [Openid-specs-ab] Encryption
>>
>> So I was going over the recent XML Encryption vulnerability.
>>
>> http://www.informationweek.com/news/security/vulnerabilities/23190153
>>
>> 2
>>
>> The flaw is that of CBC mode of operation combined with
>>
>> unauthenticated encryption.
>>
>> It is a kind of padding oracle attack.
>>
>> We have two choices here:
>>
>> 1) Require authenticated encryption mode such as GCM
>>
>> 2) Require message authentication to be applied to the cipher text.
>>
>> Ideally 1) should be taken as operational efficiency is much greater
>>
>> than 2), but in reality we do not have support for GCM in many
>>
>> languages.
>>
>> Thus, while RECOMMENDing 1), we should REQUIRE HMAC to be applied on
>>
>> the encrypted text (cipher text) in CBC mode.
>>
>> Thus, we should make it REQUIRED to sig+enc+mac, instead of sig+enc,
>>
>> and REQUIRE the verifier to first verify the mac and if the mac is
>>
>> not correct the process should abend returning mac error.
>>
>> Also, although same public-private keypair can be used for encryption
>>
>> and signature in case of RSA, we should probably use two separate
>>
>> keypair. That is safer.
>>
>> Perhaps we would not REQUIRE it, but we should RECOMMEND it.
>>
>> =nat
>>
>> _______________________________________________
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
>>
>>
>>
>> _______________________________________________
>>
>> Openid-specs-ab mailing list
>>
>> Openid-specs-ab at lists.openid.net
>>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>> --
>>
>> --Breno
>>
>> _______________________________________________
>>
>> Openid-specs-ab mailing list
>>
>> Openid-specs-ab at lists.openid.net
>>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>>
>>
>> --
>> --Breno
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
>
> --
> --Breno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111031/9f856555/attachment.p7s>
More information about the Openid-specs-ab
mailing list