lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1504022256490.327@debian>
Date: Thu, 2 Apr 2015 23:26:18 +0200 (CEST)
From: Stefan.Lucks@...-weimar.de
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] OMG we have benchmarks

On Thu, 2 Apr 2015, Marsh Ray wrote:

> Rijndael with a block size of 256 bits would fit many applications 
> better than AES, too. But the world has generally agreed with NIST that 
> having fewer choices makes a better standard than being perfectly 
> flexible to fit all situations.

This is correct, but not the full picture. At some Fast Software 
Encryption (FSE) conference, a representative from the NIST (I believe, it 
was Bill Burr, but I am not sure) had been asking us cryptographers about 
our wish-list for a DES-successor. The answer was quite clear: support for 
128-bit and 256-bit keys, and for 128- and 256-bit blocks. Two key sizes, 
two block sizes would have made four variants. I never understood why some 
bureaucrats at the NIST decided that four was too much, but three would be 
great, and then gave us the useless variant with 192-bit keys(*), instead 
of a 256-bit block size. This is one of the worst cryptographic choices 
the NIST ever made(**), IMHO. Even two variants (128-bit keys and blocks, 
and 256-bit keys and blocks) would have made more sense(***) than any 
support for the intermediate key length of 192 bit. But a standard is a 
standard is a standard ...

Back to PHC:

Reducing the number of choices makes make a good standard.

But beware of offering too few or the wrong choices!

So long

Stefan


----------

(*) I know plenty of applications of AES with 128-bit keys, and plenty of 
applications of AES with 256-bit keys. But I haven't heard of any 
application with specific support for 192-bit AES and no other AES 
variant. Of course, applications with a variety of "cipher suite" options 
usually support all three AES variants, for the sake of completeness.

(**) The decision to standardize DUAL-EC-DRBG is far out of comparison!

(***) For what its worth: There would not have been much need for the 
SHA-3 competition, if there had been an AES variant with 256-bit block 
size when SHA-1 was attacked. A block cipher based hash function could 
have provided a decent "backup", for the case that the attacks on SHA-1 
would have endangered the SHA-2 family as well.


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ