Le quintidi 5 ventôse, an CCXXIV, Christian Seiler a écrit : > But if you say what Debian is doing is a mistake, then this _is_ what > you are talking about.
I am quite sure of what I am talking about and what I am not talking about. > This is decisively not true when we are talking about signing files. If > you look at RFC 4880 [1], if you sign a normal file ("binary document", > type 0x00), what is signed with the asymmetric algorithm is [2]: > > asym_input = H(contents || trailer) > > In OpenPGP v4, the trailer is given by [3] > > trailer = 0x04 || sigtype || pkalg || hashalg || hsplen || hspdata > sigtype = 0x00 (binary document) > pkgalg = public key algorithm, e.g. 0x01 (RSA) > hashalg = hash algorithm, e.g. 0x08 (SHA256) > > hsplen: two octets denoting the length of hspdata (may be 0) > hspdata: subpackets, containing e.g. signature date and time > > So a valid way to construct an OpenPGP v4 signature would be to > use > > H(contents || 0x04 0x00 0x01 0x08 0x00 0x00) > > as the input for the RSA algorithm (and then pack that up in a > nice OpenPGP packet). I did not have the reference of what OpenPGP does near at hand, I was more referring to the way hashes are used to build HMACs: H(K^opad || H((K^ipad) || message)) As you can see, choosing the message does not leave you enough freedom to exploit a collision. > Furthermore, what you are saying doesn't make much sense: even if > you add some random nonce (maybe in a subpacket, which at least > GnuPG doesn't appear to do), what does that protect against? > > If you have a signature by a given key, and you have a feasible > preimage attack against the hash algorithm used in that specific > signature, you only need to find a preimage collision against your > chosen file contents concatenated with the trailer used in that > specific signature. Since _any_ preimage attack needs to deal with > prefixes and suffixes anyway (file formats that are processed have > certain things that need to exist in the right places for programs > processing these files to accept them), I don't see how that makes > this any more difficult. > > Basically: if there's a preimage attack against a hash, you are > able to forge OpenPGP signatures on files using that hash function > in the same way as you are able to break a simple hash. Between a hash that has no known attacks and a full working preimage attack, there is a lot of space for limited collision attacks. Even if it does not apply to the simplified example I gave, a well crafted protocol will be able to mitigate some of these attacks. Not all, not perfectly, but still some, and that is better than nothing. > Actually, scrambling passwords is more complicated than what you > describe I did not describe how to scramble passwords, I just explained why one side of the process was necessary. The requirement of expensive computations exists too, but it is irrelevant for the current discussion.
signature.asc
Description: Digital signature