On 02/23/2016 07:52 PM, Nicolas George wrote:
> 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.
But if you say what Debian is doing is a mistake, then this _is_ what
you are talking about.
> 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.
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).
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.
The _only_ way I can see that a signed simple hash is less secure
than a direct signature is that you can play around with padding,
which will reduce the effort for preimage attacks. For this reason
Debian also encodes (and checks) the length of the files in the
archive summary files.
> 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.
Actually, scrambling passwords is more complicated than what you
describe, and simply salting them is still not sufficient, you need
to actually make it hard for brute-forcing (because the entropy of
a password is typically low), so you actually want something that's
computationally expensive and not easily done on GPUs an such, e.g.
scrypt or bcrypt.
> 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.
OpenPGPv4 can't protect against hash collisions (see my reasoning
above) - and I seriously doubt you could construct a mechanism that
works offline which does protect against hash collisions.
There are _other_ use cases where collision resistance of a hash is
not that important; preimage attacks are still quite expensive, so
attacking HMACs with session keys for a live TLS session (as long
as rekeying happens often enough) is probably not feasible even for
weaker hash functions. But you were saying that Debian's use of
hash lists is a mistake, and I still don't see how that is the case.
Regards,
Christian
[1] http://tools.ietf.org/html/rfc4880
[2] http://tools.ietf.org/html/rfc4880#section-5.2.4
"For binary document signatures (type 0x00), the document data
is hashed directly." [...] "Once the data body is hashed, then
a trailer is hashed."
[3] http://tools.ietf.org/html/rfc4880#section-5.2.4
"A V4 signature hashes the packet body starting from its first
field, the version number, through the end of the hashed
subpacket data. Thus, the fields hashed are the signature
version, the signature type, the public-key algorithm, the hash
algorithm, the hashed subpacket length, and the hashed subpacket
body."
Attachment:
signature.asc
Description: OpenPGP digital signature