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

Aaron Zauner azet at azet.org
Mon Nov 25 17:13:23 CET 2013

On 25 Nov 2013, at 16:27, <Daniel.Kovacic at a-trust.at> <Daniel.Kovacic at a-trust.at> wrote:

> 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.
Can you provide further information on this? Just out of curiosity.

> 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.
Yeah well. The discussion was/is: Are certain curves flawed and should thus be excluded in the paper. Not: Is ECC unacceptable. Since NIST itself is doing a review, I would not feel comfortable to recommend any NIST curves. See also: http://safecurves.cr.yp.to/

As for the Key and Cipherlenght discussion in this thread and the Lenstra quote:

Determining the newly proposed security levels requires a trained professional.
This considerably raises the bar for uneducated guesswork and thereby signi
cantly diminishes the risk of insecure parameter choices. Worldwide adoption of
these intuitive security levels will have a bene
cial eff
ect on Internet security.


I’m not sure how some of you came up with those ciphersuites - I mean they are OK - but just adding stronger ciphers (as in bitlenght) does not necessarily make a ciphersuite more secure. In the contrary: As many have noted already - with some ciphers there are more attacks known (for example due to more rounds) as with the lower-bit equivalents.  This fact also will make the paper unusable to real-world internet traffic as well as large traffic sites (as i repeatedly remarked). Our recommendations should be for those guys not for some small tinfoilhat-websites. We want wide adoption, no?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131125/1a827b02/attachment.sig>

More information about the Ach mailing list