Le quintidi 5 ventôse, an CCXXIV, Christian Seiler a écrit : > You have _emphasized_ it, but you haven't _explained_ it, nor provided > any search term one could use to look up an explanation for it. Explaining takes time, I do not want to do it if nobody will read it. > Why is what Debian does a mistake? Debian stores both the hash value > and the file size in the Packages, Sources and Release files. (Packages > references e.g. the .deb packages, Release references the "Packages" > file and Release itself is signed.) Assuming that there's no feasible > preimage attack against the hash function, and the file containing the > hashes + sizes is signed via GnuPG, how is that problematic, as long as > you check everything along the way? > > Also note that the Tor project (and I believe they do know something > about security) uses hash lists for reproducibility: > https://www.torproject.org/docs/verifying-signatures.html.en > (To be fair, they also sign each file individually, but the > instructions to verify builds w.r.t. reproducibility specifically > talk about hash lists.) > > Also, note: > http://crypto.stackexchange.com/questions/24224/signing-files-vs-signing-file-hashes > The person writing the top answer to that question has his own blog > about cryptography: https://www.chosenplaintext.ca/ > > Since what you are talking about is apparently non-obvious to people > who do crypto for a living, your characterization of _beginner's_ > mistake is definitely wrong. If it's a mistake, it's apparently a > highly non-trivial one. What you quote is about signing a summary of files at once versus signing each file individually. This is not what I was talking about. What I was talking about was signing the file contents itself versus signing the hash of the file. Do not get things wrong: signing a file involves a hash of that file, because asymmetric ciphers, the keystone for building signing protocols, are way too slow to be used on large files, and also for a few other considerations. But the cipher is not simply applied to the hash. If you build a wall, you do not just stack stones together, you fit them so that strengths of some stones will compensate weaknesses of others. The same goes for cryptography. If you just stack the cryptographic primitives together, the resulting protocol compounds the weaknesses of its components. In particular, any collision in the hash function is directly a fake signature. I suppose it would be acceptable, but the crux is: we know how to do better without extra computational costs. Of course, if the hash function and the asymmetric cipher both are flawless, then their simple stacking would be secure. But flaws are discovered in algorithms frequently. The protocol used for cryptographic signatures builds and encrypts the hash in a way that protects from most attacks against the hash algorithm itself. For example, even though we know how to craft MD5 collisions easily, these collisions can not be used to make fake signatures even with protocols that use MD5, because these protocols make sure that variable octets are inserted in front of the payload. The core of the issue is that hash functions have properties that are not needed in a signing protocol. More precisely, the same hash function applied to the same file yields always the same result, of course. But we do not need that in a signing protocol. Quite the contrary, in fact. All we need is to be able to check the signature, but generating a different signature each time can be considered a plus in many situations. The same goes for other uses of crypto primitives. Consider scrambled passwords for example? Do you agree that just hashing a password is a beginner's mistake? A correct protocol requires a random salt: that way, password can be checked individually, but not brute-forced collectively; if attackers gets hold of a database of millions of scrambled passowrds, with a proper salt they have to build a dictionary attack for each password, without a salt they can attack the whole database at once. All this is quite orthogonal to the issues you quoted, which were about signing not only the files' individual contents but also the files' metadata and the global information about what files are in the collection. Signing the hash file protects against that but is wide open for collision attacks. A proper protocol can protect both. Regards, -- Nicolas George
Attachment:
signature.asc
Description: Digital signature