[Ach] General agreement on cipher and hash strength and choice

Mon Nov 25 16:27:20 CET 2013

Hi,

Thank you for contributing to this discussion!

I would like to emphasize that such decisions are much harder than the
feeling that something is likely to be more secure by having an larger key
space or image space size.
I try to give some numbers and implications to get an feeling for what we
are talking about here: (might be a bit messy. Sorry about that)

How "hard" are these key sizes?
Today an key size of 128 is by far sufficient for about all use cases I
think 90+ is already sufficient and 128 is much much more.

AES128 is an 10 Round SPN and AES256 14 Round SPN construction (excluding
the negligible overhead in key expanding) this means about 40% slower
encryption/decryption) (ok, no game changer in a lot of situations, but
definitely worth considering)

If you compare cipher key size to rsa moduli you get something like that:
80bit <-> 1024 bits (RSA) <-> 160 bit (ECC) (Relatively new news I ve heard
about is, that nsa might be able to break an 1024 bit RSA key in one year,
putting in an huge effort.  Think about how much harder 128 actually is!)
128 bit <-> 3072 bits 
256 bit <-> 15360 bits
 This means that if you use RSA for key exchange, you need an 15360 bit rsa
key to maintain the security of your shiny aes 256 bit key! (This is absurd)
By the way, this is a strong argument to not just throw ecc out of the
window without thinking about) So using aes256 in tls gives you much less
than you think most of the time even nothing! So, why by default?
Furthermore: Doubling an RSA Key leads to an 6 to 7 time slower decryption
speed due to handling the high private exponent (huge impact in protocols
like ssl)
Moreover: think about ephemeral key exchanges

SHA:
What does it mean to be more secure (under which conditions) or acceptable?
In the paper, most of the time we are discussing sha in an hmac
construction. There sha or md5 works as a reduction algorithm and the whole
construction is not flawed by possible collisions like the pure hash itself.
In fact: Even HMAC-MD5 might be sufficient while md5 is clearly outdated.
Considering here SHA512 would be ridicules because in reality you gain
almost nothing and pay the cost for bloated message size.

Long term keys like root certificates:
I think this is a bit enthusiastic, regarding the actual Mozilla and
Microsoft root stores (last time I browsed through we were one of very few
cas providing that)
Little note for Austria: In Austria it isn’t even allowed to provide an ca
certificate which is valid more than 5 years.

Remarks on ECC:
On the deepsec I heard a lot of people throwing out ecc saying the nsa
clearly flawed it. Consider that this actually has further implications!
First of all that would mean that there is a completely new type of curves
which is I think remarkable and that either there are a lot of them or the
nsa is able to break sha1! I think the whole parameter debate is very
serious and important but it might not be so easy one might think.

Sorry, if this sounds a bit rude. I didn’t mean it like that :-). My point
is, that is very noble to go for high numbers but the price might be
unproportional for the non-enthusiastic people. By the way I is absolutely
ok for me if we go for them, I only would like to mansion the implications.

Best regards
Daniel

-----Ursprüngliche Nachricht-----
Von: Philipp Gühring [mailto:pg at futureware.at] 
Gesendet: Montag, 25. November 2013 14:20
An: Daniel Kovacic; ach at lists.cert.at
Betreff: Re: [Ach] General agreement on cipher and hash strength and choice

Hi,

>From my point of view, there is no clear preferance regarding AES128 vs.
AES256 from the security point of view, it depends on your subjective
attacker.
Therefore, I don´t mind that we aren´t consistent in a preferrance at the
moment regarding AES128 vs. AES256.

Regarding SHA256 vs. SHA512, I think SHA512 is likely more secure than
SHA256, but both are acceptable at the moment.
Regarding RSA, my current suggestion is to use 4096 for long-term keys like
root-certificates, and to use 2048 bits for normal applications.

Best regards,
Philipp Gühring

-----Original Message-----
From: <Daniel.Kovacic at a-trust.at>
To: <ach at lists.cert.at>
Date: Sun, 24 Nov 2013 17:49:54 +0000
Subject: [Ach] General agreement on cipher and hash strength and choice

> Hi,
> 
> I am currently revicing the gpg (cipher suite) section and I noticed 
> that we are very inconsistent in ordering ciphers and hashes in our 
> configs. Especially AES{128|256}, SHA{256|512} etc attracted me. To be 
> precise we have no consensus whether we prefer aes128 over aes256,
> sha256 over sha512 and so on. Same with RSA key lenght. I personally 
> dont like that and I think we should get to an agreement here. I 
> prefer recommending the most compatible, wide spread, fastest etc 
> algorithm we agree on being absolutely recommendable at the point of 
> writing. So I would always list aes128 before aes256 and sha256 before 
> sha512 per default. I also think that just preferring the bigger 
> numbers for the sake of being bigger looks a bit dubious and one who 
> reads rsa 4096 might ask 'why?'
> 
> best regards
> Daniel
> 
> PS.: Sorry, if this message arrives multiple times. something here in 
> our outlook is tricking me :-/ 
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4580 bytes
Desc: not available
URL: <http://lists.cert.at/pipermail/ach/attachments/20131125/c871ac3f/attachment.bin>