On Wed, May 8, 2013 at 7:33 PM, Rui Ueyama <ruiu at google.com> wrote:> On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> On 5/8/2013 11:35 AM, Chandler Carruth wrote: >> >>> Interestingly newer, supposedly "more secure" digest algorithms are also >>> very often significantly faster. I don't think we want any of the ones >>> mentioned here, I think we want one of the candidates is the SHA3 >>> competition which had truly stellar software implementation throughput. I'm >>> hoping to add support for such a digest algorithm to LLVM soon, as there >>> are many folks who want to consume this information: modules, merge >>> function pass, debug info, and the linker. >>> >> Nice, Is it performant in size as well as speed too ?. Because lld would >> need to store this information for every atom thats mergeable. >> > > How about using only the first 80 (or 96 or 128) bits of the digest? >This is exactly the right pattern (although the chunk size is usually 32, 64, 128, 256, 512). You trade off collision resistance against space. I think for atoms, you want to burn space in order to *not* compare them at all. I would suggest storing 256 bits at least.> > >> What are the SHA-3 variants that you think would suite these needs ? > >I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at.> >> >> Thanks >> >> Shankar Easwaran >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/ff705a02/attachment.html>
On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote:> > What are the SHA-3 variants that you think would suite these needs ? > > I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at.If your primary criterion is through-put on large, desktop-class CPUs, Skein is likely to be the winner. Keccak (the official SHA3) is also pretty fast on CPUs (and significantly better in hardware implementations, not that it matters here), and has the advantage of having the official designation. --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/287b7494/attachment.html>
On Wed, May 8, 2013 at 9:13 PM, Owen Anderson <resistor at mac.com> wrote:> On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > >> >>> What are the SHA-3 variants that you think would suite these needs ? >> >> > I want to look at the implementation complexity. The winner (and the > official SHA3 algorithm), BMW and Skein are all worth looking at. > > > If your primary criterion is through-put on large, desktop-class CPUs, > Skein is likely to be the winner. Keccak (the official SHA3) is also > pretty fast on CPUs (and significantly better in hardware implementations, > not that it matters here), and has the advantage of having the official > designation. >I was moderately certain that BMW had a significantly higher throughput in software, and was only disqualified due to fairly long-tail security concerns that wouldn't apply here. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/c4758600/attachment.html>