(comment to Saso's email forwarded by Eugen): Well I think it would be fairer to say SHA-3 was initiatied more in the direction of improving on the state of art in security of hash algorithms given that SHA1 was demonstrated to have alarming short-falls, and given that the only remaining FIPS alternative, SHA-2, was in the same family having a very similar design to SHA-1, it was a very understandable and rational worry that SHA-2 might start to show cracks under the same kind of attacks. (And that the attack against SHA1 (and method of attack) may improve in effectiveness a bit also).
In that you see the selection of Keecak, focusing more on its high security margin, and new defenses against existing known types of attacks. If the price of that is slower, so be it - while fast primitives are very useful, having things like MD5 full break and SHA-1 significant weakening take the security protocols industry by surprise is also highly undesirable and expensive to fix. To some extent for the short/mid term almost unfixable given the state of software update, and firmware update realities. So while I am someone who pays attention to protocol, algorithm and implementation efficiency, I am happy with Keecak. And CPUs are geting faster all the time, the Q3 2013 ivybridge (22nm) intel i7 next year is going to be available in 12-core (24 hyperthreads) with 30GB cache. Just chuck another core at if if you have problems. ARMs are also coming out in more cores. And AMD 7970 GPU has 2048 cores. For embedded and portable use, a reasonably fast and energy frugal 32-bit or 64-bit processor is really cheap these days. OK I know there's always a market for 8-bit processors, on the extreme cheap/low power end, but the validity of the cost complaint is diminishing even there. Adam On Wed, Oct 03, 2012 at 01:05:10PM +0200, Eugen Leitl wrote:
----- Forwarded message from Sašo Kiselkov <skiselkov...@gmail.com> ----- From: Sašo Kiselkov <skiselkov...@gmail.com> Date: Wed, 03 Oct 2012 08:22:26 +0200 To: "<z...@lists.illumos.org>" <z...@lists.illumos.org> Subject: [zfs] SHA-3 winner announced User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Reply-To: z...@lists.illumos.org Hi All, As many of you are probably aware, NIST has just announced the SHA-3 winner: Keccak. Wonderful, so now we can go ahead and implement it in ZFS as the next-gen hash algo for dedup, right? Sadly, no. As I predicted, NIST could, and it seems did, choose a candidate that fits their criteria, not ours. Keccak, you see, is slow. Mighty slow. It's comparable to and at times even slower than the current SHA-2. See: http://bench.cr.yp.to/graph-sha3/1536-thumb.png Of course, I already hear people object: "But, it'll become faster once we get hardware implementations!" Sadly, no. Here are a few reasons why the "HW FTW!" argument is invalid: 1) x86 currently lacks even an implementation of SHA-2, which is over a decade old, so I do not expect SHA-3 to come along any time soon. 2) The UltraSPARC T2 and higher are currently the only CPUs capable of running Illumos that also have the algo in hardware and they got the capability after 6 years from the release of the algorithm (and Illumos doesn't even support that, but that's another story). Even considering an optimistically fast design cycle, I don't expect SHA-3 to appear in SPARC before the T6 (considering the T5 is slated for release pretty soon, so feature additions to the silicon are currently highly unlikely), which is on track for release in 2013/2014. My personal guess is that it's more likely to appear in the next release cycle after the T6, some time in 2014 or 2015. 3) Illumos runs on a wide variety of platforms, most of which will probably never get SHA-3 in hardware for the foreseeable future. I know I'm going to get a lot of flack for saying so, but the hard reality is that SHA-3 is over and that they've chosen an algorithm that's essentially useless to ZFS. Sure it has a nice security margin, much better than SHA-2, but we were already happy with the security margin we had before, so what we wanted next is more speed, and sadly, that's not something Keccak improves on. In conclusion, I'd like to propose a course of action: mainline one (or multiple) of the algorithms which I submitted patches for: Edon-R, BMW or Skein. All of them have a security margin that's better than SHA-2 and much, much better performance. Cheers, -- Saso ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography