On 02/24/2016 01:48 PM, Nicolas George wrote: > Le sextidi 6 ventôse, an CCXXIV, Christian Seiler a écrit : >> Yes, I know what an HMAC is. But an HMAC is _utterly_ useless for a >> digital signature. > > Please stop commenting the finger when I try to show you the moon.
The problem is that you were being extremely vague. And if you are
not actually discussing the merits of the issue itself, but talking
about different use cases with different threat models, then you
can't come back and complain that you don't get your points across.
> You want an actual example of attack that a proper signing protocol
> prevents?
Yes, precisely. That is what I was asking for in the first place.
> 1. Alice generates harmless.iso and harmful.iso with a hash collision.
> 2. Bob generates harmless.iso.sha and signs it as harmless.iso.sha.sign.
> 3. Alice replaces harmless.iso by harmful.iso.
> 4. Eve checks the signature, the signature is valid.
>
> Compare to:
>
> 2. Bob signs harmless.iso as harmless.iso.sign.
> 3. Alice replaces harmless.iso by harmful.iso.
> 4. Eve checks the signature, the signature is invalid, the attack is foiled.
>
> The principle is that a proper signing protocol needs to include in the
> hashed message parts that the attacker can not control.
Thank you. Why didn't you say so from the beginning?
Yes, under that threat model (attacker controls what is signed)
using a simple hash is problematic.
And yes, preimage attacks are harder than collision attacks (as
we've seen with MD5).
Still, I don't think that's reason enough to discourage people from
signing hash lists, because:
1. In practical terms there's no known _feasible_ collision attack
for the SHA-2 family out there.
2. Current software doesn't actually do what you are suggesting.
For example, the only data added before hashing by GnuPG that's
_slightly_ difficult to predict is the timestamp. (OpenPGP
doesn't actually specify a subpacket type for something like a
salt.) The rest of the stuff added to the hash function is
completely predictable. (And it's appended, so as per your
comment about MD5, for at least that hash and possibly others,
it's also useless against such an attack.)
Yes, doing it differently (e.g. also signing each individual file)
would improve the security properties, but I don't think relying on
collision attack resistance for a decent hash function is _that_
problematic. (And it's not like there weren't warning against MD5
long before the known attacks were published; that people were still
using MD5 on such a widespread basis, even after it was expected to
be broken in the not too distant future, is a different problem.)
But to be more constructive:
Let's say one creates a tool akin to sha256sum that does the
following (let's call it ssha256sum):
- Generate two sufficiently large random numbers S1, S2
(Let's say 128bit each.)
- Output first line: those random numbers
- For each file generate output similar to sha256sum, but do
SHA256(S1 || filecontents || S2) instead
If one just signs the resulting file, in your opinion, would that
offer the same guarantees for the contents of all of the files as
signing the individual files themselves?
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
