On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote: > (I was asked to comment a few points in public by Jonathan.) > > I think this group can safely assume that SHA-256, SHA-512, BLAKE2, > K12, etc are all secure to the extent that I don't believe that making > comparisons between them on that axis is meaningful. Thus I think the > question is primarily concerned with performance and implementation > availability. > > I think any of the above would be reasonable choices. I don't believe > that length-extension is a concern here. > > SHA-512/256 will be faster than SHA-256 on 64-bit systems in software. > The graph at https://blake2.net/ suggests a 50% speedup on Skylake. On > my Ivy Bridge system, it's about 20%. > > (SHA-512/256 does not enjoy the same availability in common libraries however.) > > Both Intel and ARM have SHA-256 instructions defined. I've not seen > good benchmarks of them yet, but they will make SHA-256 faster than > SHA-512 when available. However, it's very possible that something > like BLAKE2bp will still be faster. Of course, BLAKE2bp does not enjoy > the ubiquity of SHA-256, but nor do you have to wait years for the CPU > population to advance for high performance. SHA-256 acceleration exists for some existing Intel platforms already. However, they're not practically present on anything but servers at the moment, and so I don't think the acceleration of SHA-256 is a something we should consider. The SUPERCOP benchmarks tell me that generally, on 64-bit systems where acceleration is not available, SHA-256 is the slowest, followed by SHA3-256. BLAKE2b is the fastest. If our goal is performance, then I would argue BLAKE2b-256 is the best choice. It is secure and extremely fast. It does have the benefit that we get to tell people that by moving away from SHA-1, they will get a performance boost, pretty much no matter what the system. BLAKE2bp may be faster, but it introduces additional implementation complexity. I'm not sure crypto libraries will implement it, but then again, OpenSSL only implements BLAKE2b-512 at the moment. I don't care much either way, but we should add good tests to exercise the implementation thoroughly. We're generally going to need to ship our own implementation anyway. I've argued that SHA3-256 probably has the longest life and good unaccelerated performance, and for that reason, I've preferred it. But if AGL says that they're all secure (and I generally think he knows what he's talking about), we could consider performance more. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature