Re: AES-256 vs. AES-128

2015-12-01 Thread Wan-Teh Chang
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

2015-11-30 Thread Robert Relyea

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

2015-11-30 Thread Brian Smith
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

2015-11-30 Thread Robert Relyea

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

2015-11-30 Thread Julien Vehent

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

2015-11-25 Thread Reed Loden
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


AES-256 vs. AES-128

2015-11-25 Thread April King
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