Hi Eugen, On 10/3/12 7:05 AM, "Eugen Leitl" <eu...@leitl.org> 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. If the hash function is being used in a symmetric message authentication code, such as HMAC, then a good alternative would be to use a MAC that has the performance properties that you are looking for, such as AES-GMAC, which is supported on recent x86 systems <http://www.intel.com/content/www/us/en/communications/communications-ia-ga lois-counter-mode-paper.html>. AES-GCM is described as being supported in ZFS in Solaris 11 at <http://docs.oracle.com/cd/E23824_01/html/E24456/securedata-1.html#zfsencry pt-1>, though I don't see any details as to how that is implemented. Are the requirements for the security of ZFS and the use of cryptography in that filesystem documented anywhere? <https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data> mentions a Merkle tree of checksums, where the checksum function can be either Fletcher or SHA-256. A collision-resistant hash of an entire system is indispensable if asymmetric authentication is needed, but are there common scenarios where that is needed? If encryption is used in ZFS, then there is necessarily a symmetric encryption key that is being managed; why not use symmetric message authentication as well, and take advantage of the performance gain? Regards, David > >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-a25d >3366 >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
