Fail better in extra::crypto::sha1::add_input()

[catamorphism]

There's a bare fail and a FIXME saying "need better failure mode".

[nikomatsakis]

This should... probably use a condition? I don't really understand the conditions that would lead to this failure. Is this an assertion? @graydon?

[sonwow]

Even if it is fixed to use a condition, there is a problem about using conditions from another crate. (#5446)

[bblum]

nominating production-ready

[graydon]

just a bug, removing milestone/nomination.

[omasanori]

@nikomatsakis This is essentially an overflow check. len_low and len_high emulates u64 and are stored the length of a message in bits. The result will be broken when overflow occurs. FYI.

[huonw]

It seems that this is a fundamental limitation of the SHA1 algorithm: it cannot hash more than 2^64 - 1 bits. Personally, I think just changing it to something like fail!("SHA1 does not support hashing more than 2^64 - 1 bits") is a decent solution.

(cc @DaGenix.)

[DaGenix]

I agree.

The only part of Sha1 that can't handle messages that size is the bit count field which is a 64 bit field. MD5 is defined to allow that bit count to wrap around. Sha1, on the other hand, is simply not defined for inputs bigger than 64 bits. So, one option is to simply ignore that part of the spec and just silently allow that bit count to wrap around. That seems like a bad idea, though, since its non-compliant with the spec. I don't think there really is anything that the caller can do to correct the issue - if the caller needs a Sha1 digest for an input that's too big, that seems like an application / protocol issue and task failure seems appropriate to me.

[emberian]

Closing; said crypto stuff has been removed.

[huonw]

(Carrying out the long-delayed closure @cmr threatened...)

[emberian]

Heh, oops.