>> 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.
Yes, I know what an HMAC is. But an HMAC is _utterly_ useless for a
digital signature. An HMAC relies on a shared _secret_ (in your
notation K) between parties to authenticate data. And I fully agree:
an HMAC is much less susceptible to hash function weaknesses than
other uses of hash functions.
The problem is: a digital signature in asymmetric cryptography cannot
(by definition) rely on a shared secret, because it must be verifiable
with publicly available information.
>> 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.
If you look at current cryptosystems:
- TLS certificates (the only part of TLS that _is_ offline signed)
use plain hashes over the data to be signed. (See RFC 3447; it
then does more complicated things _with_ that hash, but if you
have a collision, then you can forge a signature.)
- OpenPGP uses a hash of the data to be signed plus a trailer
(see my previous email), etc.
(RFC 3447 even says:
"For the signature schemes in this document, a collision
attack is easily translated into a signature forgery."
See <https://tools.ietf.org/html/rfc3447#appendix-B.1>)
For the integrity of an _encrypted_ message (where there is a secret)
OpenPGP does use something akin to an HMAC (they call it MDC), which
does not require the same level of resistance to collisions. But that
doesn't apply to pure signatures.
[ Original thing I responded to ]
>>>>>> If the SHA512SUMS.sign
>>>>> Stop right there. Signing a bunch of hashes is a beginner's mistake, I have
>>>>> already emphasized that in this thread. It is rather sad that Debian made
>>>>> that mistake.
And I still haven't seen any reasoning why that is the case. All what
you've done is claimed that a digital signature of the contents of a
file is somehow more secure than the signature of a hash. When pressed
for explanations, you simply claimed:
>>> The protocol used for cryptographic signatures builds and encrypts the hash
>>> in a way that protects from most attacks against the hash algorithm itself.
When asked for specifics, you mentioned unrelated examples such as
scrambling passwords and HMACs, both of which do not apply to digital
signatures such as made by Debian. Don't get me wrong, I agree that
simply using a hash is sometimes the wrong thing to do, and your
reasoning applies to the examples you provided, but not the use case
you were initially referring to.
But again: you claimed that Debian is making a mistake with the way
APT handles signatures, because it's similar to SHA256SUMS.asc. I
still haven't heard any explanation as to why what is a mistake - and
all you've brought up are examples as to why for _other_ use cases
there are good protocol designs that don't rely so heavily on hash
function properties.
What good design is there for offline asymmetric digital signatures?
A keyword would suffice, as long as it's specific enough.
But even if I grant you that there are algorithms for signatures out
there that don't suffer from hash collisions: it's one thing to point
out that using SHA256SUMS.asc relies on the collision resistance of
SHA256, it's another to say that using a scheme like that is a mistake.
At the moment SHA256 is considered to be collision resistant for
crypto purposes by the broader community, and while it's objectively
better to have something that doesn't rely on collision resistance (if
all else is equal), it does not mean that signing a list of hashes is
inherently problematic at the moment, as long as the hash function
you're using is sufficiently strong. So instead of using using
derisive language such as "beginner's mistake" (which is laughable,
because I wouldn't call the people designing modern crypto we all rely
on beginners), you could be much more specific and say "here, look,
there's a much better solution out there called X and it will improve
what you're doing". That would be far more constructive. Just
saying...
Regards,
Christian
Attachment:
signature.asc
Description: OpenPGP digital signature