Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100: > On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote: > > I really like this idea. > > > > And we could take a copy of APR's sha1 code, and rejigger it to perform > > *both* hashes during the same scan of the raw bytes. I would expect the > > time taken to extend by (say) 1.1X rather than a full 2X. The inner loop > > might cost a bit more, but we'd only scan the bytes once. Very handy, when > > you're talking about megabytes in a stream-y environment. > > > > (and medium-term, push this dual-sha1 computation back into APR) > > The idea is nice and I would support its application.
I would not. Using two variants of sha1 is fine for supporting webkit's use-case, or to protect admins from disgruntled employees who commit the known collision to DoS their employer. However, when the attacker model is a competent/resourceful attacker, using two variants of sha1 only increases the attack's complexity by a factor of about 2⁷ ([1, §4.1]), and might in fact cause collisions to be _easier_ to find (since additional state is output). So let's not add a variant of sha1. Instead, if we're concerned about disgruntled employees, we should detect collisions; and if we're concerned about competent attackers, we should use a stronger/longer industry-standard hash function. (Note that we already have both md5 and sha1, so we check (or can check) both of them. And there's always full byte-by-byte comparisons...) Cheers, Daniel [1] https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf > Note however that it does not help with fixing current releases. > We would need to store this second hash somewhere, which implies a format > and/or protocol change, depending on where the idea is applied (rep-cache, > ra-serf, pristine store, ...) > > For now, we should focus on solutions that can be backported because that's > what our users need most. Our current formats and protocols will only > store/send MD5 and SHA1 of the full content so for 1.8 and 1.9 we will > have to find something that works within these restrictions. > One option would be to disable affected features. But some features can't > just be disabled, such as the pristine store. > > In theory the existing system should work as it is as long as only one side > of the collision is allowed to survive. We will need format changes only to > allow storing both PDFs. We could delay 1.10 a bit to gain time for working > out long-term solutions which imply format changes.
