Counter length-extension attacks

[ross-spencer]

Matt left some important info on the OPF blog:

One more issue. Hash functions like MD5 rely on applying their state iteratively. You can add something to an existing hash by taking the hash and just running the digest with it and the new content.

So this does not protect against someone adding things to an archive. This is known as a length extension attack in cryptography:

https://en.wikipedia.org/wiki/Length_extension_attack

The defence is to use a slightly more convoluted function that is immune to length extension. The HMAC algorithm can do this. This also works:

H’ = H(H(0b || m)), where you first take the hash of the message with some zeros prepended to it, and then take the hash of that hash.

This looks like something that can be added easily.

[ross-spencer]

The fix for #6 took about 8 hours. To add a secure hash algorithm, such as described here, we would either need to redo much of the testing work around that, or add some new tests. Consider adding this feature via a --secure flag. As this utility is a proof of concept, it's probably a good idea to allow both methods and for folks to see it working purely, and with the counter-length-extension attacks mitigated as well.

[ross-spencer]

This looks like a good blog to explain this a little bit more: https://www.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks