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.
Attachment:
signature.asc
Description: Digital signature