y goes in, 512bit hashes will be seen as standard over the next decade
or so. I don't think that this should be involved in this discussion,
presently. I'm just saying that not unlike the time when SHA1 was selected, I
think that the replacement of a 256bit hash is on the horizon as well.
Thanks,
Dan Shumow
; Dan Shumow
; Junio C Hamano ; Git Mailing List
Subject: Re: [PATCH] Put sha1dc on a diet
On Thu, Mar 16, 2017 at 07:22:14PM +0100, Marc Stevens wrote:
> Today I merged the perf-branch into master after code review and correctness
> testing.
> So master is now more performant and sa
From: Junio C Hamano [mailto:gits...@pobox.com]
> As you and Marc seemed to be still working on speeding up, such a
> customization work to fully adjust your code to our codebase was premature,
> so I tentatively queued what we saw on the list as-is on our 'pu' branch so
> that people can have
I played around tweaking the code a bit more and I got our performance down to
a 2.077182x slowdown with check and a 1.055961x slowdown without checking.
However, that slowdown is basically with the check turned off through our API.
If I rip extraneous code for storing states and checking if w
> - Dan timed the sha1dc implementation with and without the collision
> detection enabled. The sha1 implementation is only 1.33x slower than
>block-sha1 (for raw sha1 time). Adding in the detection makes it
>2.6x slower.
>So there's some potential gain from optimizing the sha1
out that there
will be subsequent cryptanalytic developments later. Marc can comment more
here.
Basically, some of it could be improved. In particular, the "generate code for
80 different recompression cases, but only ever use two of them" really looks
like it would blow up the cod
6 matches
Mail list logo
