Re: AES-256 vs. AES-128
Julien Vehent wrote: > > The discussion above was biased in favor of what was best for FirefoxOS > and > > FxAndroid. > > AES-NI has also removed mosts concerns around bad implementations of > AES, so it seems that the attacks we were concerned about two years ago > do not apply anymore. > I think they still do apply to ARM devices and to low-end Intel/AMD devices. > ChaCha20 is a different topic entirely, It is relevant here because there are many CPUs that can't do constant-time AES. > ARMv8 added support for it, so I'm guessing all apple and android mobiles > now support AES-NI, but I am no CPU architecture expert... > There are many Android devices, at least, that aren't ARMv8. > I haven't followed these discussions closely. You're proposal in those > threads > concerns tls1.3 specifically. Are we concerned about the nonce handling in > 1.1 and 1.2? There are no AEAD cipher suites in TLS 1.0 or 1.1. For TLS 1.2, it's something that needs to be figured out. Because of the 4-byte implicit part of the nonce in TLS 1.2, the statistics in DJB's batch attack need to be adjusted by some number <= 2^32. Cheers, Brian -- https://briansmith.org/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
On Tue, Dec 1, 2015 at 8:55 AM, Julien Vehent wrote:
>
> AES-NI is fast enough that we shouldn't have to care:
>
> $ openssl speed -evp aes-256-gcm
> type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
> aes-256-gcm 385250.93k 983154.24k 2011460.35k 2620519.76k 3048865.79k
Intel's low-end CPUs don't have AES-NI. For example, Pentium G3258
("Anniversary Edition"), launched in Q2 2014, doesn't have AES-NI:
http://ark.intel.com/products/82723/Intel-Pentium-Processor-G3258-3M-Cache-3_20-GHz
Neither does this Pentium model, launched in Q1 2015:
http://ark.intel.com/products/87358/Intel-Pentium-Processor-G3470-3M-Cache-3_60-GHz
Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
On Mon 30.Nov'15 at 11:37:18 -1000, Brian Smith wrote: > Julien Vehent wrote: > > > The original thread [1] had a long discussion on this topic. The DJB batch > > attack redefines the landscape, but does not address the original concerns > > around AES-256 resistance. To me, the main question is to verify whether > > AES-256 implementations are at least as resistant as AES-128 ones, in which > > case the doubled key size provides a net benefit, and preferring it is a > > no-brainer. > > > > [1] > > http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html > > > The discussion above was biased in favor of what was best for FirefoxOS and > FxAndroid. AES-NI has also removed mosts concerns around bad implementations of AES, so it seems that the attacks we were concerned about two years ago do not apply anymore. > That discussion also didn't account for the emergence of ChaCha20-Poly1305. > I believe it makes more sense for the server to prefer 256-bit cipher > suites than when I wrote in the discussion above, but ChaCha20-Poly1305 > needs to be taken into consideration to account for ARM clients. And > unfortunately most software (OpenSSL in particular) isn't ready for > ChaCha20-Poly1305 yet. ChaCha20 is a different topic entirely, but yes, it's being added to the modern guidelines in the V4 proposal, as the prefered cipher. We will be ready when NSS and OpenSSL are ;) > It may be useful to compare the processing cost of AES-128, AES-256, and > gzip/deflate when making your case. In particular, if you are compressing > every response then the difference between AES-128 and AES-256 probably > doesn't matter much to you. AES-NI is fast enough that we shouldn't have to care: $ openssl speed -evp aes-256-gcm type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-gcm 385250.93k 983154.24k 2011460.35k 2620519.76k 3048865.79k ARMv8 added support for it, so I'm guessing all apple and android mobiles now support AES-NI, but I am no CPU architecture expert... > Regarding the batch attack mentioned by DJB, make sure you understand how > it does and does not apply to TLS. See [1] and [2] and note how > client_write_IV/server_write_IV are used. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html > [2] https://www.ietf.org/mail-archive/web/tls/current/msg16088.html I haven't followed these discussions closely. You're proposal in those threads concerns tls1.3 specifically. Are we concerned about the nonce handling in 1.1 and 1.2? - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
Julien Vehent wrote: > The original thread [1] had a long discussion on this topic. The DJB batch > attack redefines the landscape, but does not address the original concerns > around AES-256 resistance. To me, the main question is to verify whether > AES-256 implementations are at least as resistant as AES-128 ones, in which > case the doubled key size provides a net benefit, and preferring it is a > no-brainer. > > [1] > http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html The discussion above was biased in favor of what was best for FirefoxOS and FxAndroid. That discussion also didn't account for the emergence of ChaCha20-Poly1305. I believe it makes more sense for the server to prefer 256-bit cipher suites than when I wrote in the discussion above, but ChaCha20-Poly1305 needs to be taken into consideration to account for ARM clients. And unfortunately most software (OpenSSL in particular) isn't ready for ChaCha20-Poly1305 yet. It may be useful to compare the processing cost of AES-128, AES-256, and gzip/deflate when making your case. In particular, if you are compressing every response then the difference between AES-128 and AES-256 probably doesn't matter much to you. Regarding the batch attack mentioned by DJB, make sure you understand how it does and does not apply to TLS. See [1] and [2] and note how client_write_IV/server_write_IV are used. [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html [2] https://www.ietf.org/mail-archive/web/tls/current/msg16088.html Cheers, Brian -- https://briansmith.org/ -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
On 11/30/2015 12:07 PM, Julien Vehent wrote: On 2015-11-30 12:47, Robert Relyea wrote: I've always found the 128 bit prioritized over 256 a silly recommendation, I support reordering. Can you expand on why you think it is silly? The argument went that 128 bit was 'sufficient' and there was a performance 'hit' doing 256. Sufficient changed our criteria from objective (stronger first, then performance) to subjective (random definition for sufficient). At one point DES 56 was considered 'sufficient'. The case in point, we've subjectively decided 128 bit isn't sufficient. That was highly predictable (attacks get better, the subjective line will move again). At Red Hat, we've already reordered this. We were having problems connecting to servers who had the following logic: SSL connect to client. Check to see if the key strength was sufficient. If not display an error message through the SSL connection. The server was assuming if a client connected with a 128 cipher, then it must not be able to do a 256 bit cipher because why would it prioritize 128 bits over 256 bits? The server didn't turn off the weaker ciphers because the server wanted to give the weaker clients a reasonable error message. The original thread [1] had a long discussion on this topic. Yes, which is why I didn't push it. I gave my reasons for disagreeing. They weren't accepted. I saw no reason to get religious about it. Still didn't mean I didn't think the decision was silly. I find life goes better if you only fight against patently wrong decisions and let silly ones go with just giving notice. bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
On 2015-11-30 12:47, Robert Relyea wrote: I've always found the 128 bit prioritized over 256 a silly recommendation, I support reordering. Can you expand on why you think it is silly? The original thread [1] had a long discussion on this topic. The DJB batch attack redefines the landscape, but does not address the original concerns around AES-256 resistance. To me, the main question is to verify whether AES-256 implementations are at least as resistant as AES-128 ones, in which case the doubled key size provides a net benefit, and preferring it is a no-brainer. [1] http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html - Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
On 11/25/2015 02:01 PM, April King wrote: My colleague Julien Vehent and I are in the process of updating the Mozilla Server Side TLS documentation: https://wiki.mozilla.org/Security/Server_Side_TLS One of the topics of conversation was whether or not the Modern TLS configuration should prefer AES-256 over AES-128. Recently, there has been some doubt cast over the security of AES-128, between posts by security researchers like djb, as well as the recent decision by the NSA to recommend AES-256 over AES-128, due to its increased resistance against quantum cryptography: http://blog.cr.yp.to/20151120-batchattacks.html https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml I've always found the 128 bit prioritized over 256 a silly recommendation, I support reordering. bob The general consensus was to bring the conversation to the dev.tech.crypto group prior to updating the standards either way. There hasn't been any claim that AES-128 is actually broken, but the idea behind the Modern guidelines is to stay ahead of the cryptographic research curve. One thing to keep in mind is that the Modern guidelines are intended for modern systems that don't require any kind of backwards compatibility or necessarily need to be friendly towards old, underpowered systems (such older smartphones). For reference, this is the current state of preference order for the four major browser manufacturers: Firefox: AES-128-GCM > AES-256-CBC > AES-256-CBC (doesn't include AES-256-GCM in list of cipher suites) Chrome: AES-128-GCM > AES-256-CBC > AES-128-CBC (also does not request AES-256-GCM) Safari: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC Edge: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC Proposal for Modern: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC If the general agreement is to move Modern to AES-256, it may also be worthwhile considering whether or when we move that recommendation down to the Intermediate level, which is intended for general purpose websites that don't have a need for backwards compatibility with very old clients (such as IE6/Win XP SP2). smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: AES-256 vs. AES-128
Other recommended reading when discussing this: https://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-and-128-bit-versions https://www.schneier.com/blog/archives/2009/07/another_new_aes.html https://www.reddit.com/r/crypto/comments/39211m/is_really_aes256_less_secure_than_aes128/ https://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/ "Are 256-bit keys less secure than 128-bit keys?" ~reed On Wed, Nov 25, 2015 at 2:01 PM, April King wrote: > My colleague Julien Vehent and I are in the process of updating the > Mozilla Server Side TLS documentation: > > https://wiki.mozilla.org/Security/Server_Side_TLS > > One of the topics of conversation was whether or not the Modern TLS > configuration should prefer AES-256 over AES-128. Recently, there has been > some doubt cast over the security of AES-128, between posts by security > researchers like djb, as well as the recent decision by the NSA to > recommend AES-256 over AES-128, due to its increased resistance against > quantum cryptography: > > http://blog.cr.yp.to/20151120-batchattacks.html > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > > The general consensus was to bring the conversation to the dev.tech.crypto > group prior to updating the standards either way. There hasn't been any > claim that AES-128 is actually broken, but the idea behind the Modern > guidelines is to stay ahead of the cryptographic research curve. One thing > to keep in mind is that the Modern guidelines are intended for modern > systems that don't require any kind of backwards compatibility or > necessarily need to be friendly towards old, underpowered systems (such > older smartphones). > > For reference, this is the current state of preference order for the four > major browser manufacturers: > Firefox: AES-128-GCM > AES-256-CBC > AES-256-CBC (doesn't include > AES-256-GCM in list of cipher suites) > Chrome: AES-128-GCM > AES-256-CBC > AES-128-CBC (also does not request > AES-256-GCM) > Safari: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC > Edge: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC > > Proposal for Modern: > AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC > > If the general agreement is to move Modern to AES-256, it may also be > worthwhile considering whether or when we move that recommendation down to > the Intermediate level, which is intended for general purpose websites that > don't have a need for backwards compatibility with very old clients (such > as IE6/Win XP SP2). > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
