Hello,
It's a bit of a long stretch perhaps... but it is probably the simplest
thing we can do, and it is completely backward compatible. Suggested
text fragments follow.
The problem of the fingerprints and other hard-coded SHA1 apps are not
solved by this, of course.
Should we add a remark about subliminal channels caused by incorporating
random bytes?
Cheers,
-Rick
------------ 8< ------------ 8< ------------ 8< ------------ 8< ------------
The value of the subpacket type octet may be:
2 = signature creation time
...
32 = embedded signature
33 = hash collision shield
...
4.2.3.27. Hash Collision Shield
(N random octets)
Hash functions are important to digital signatures, and breaking them
means breaking a signature schema. The first collision against hashes
is usually the collision attack, because these are computationally the
least expensive form of attack.
After a collision attack to a hash algorithm, the time to come up with
an attack that can completely reverse a given hash value is incredibly
long. This means that shielding against collision attacks is a very
practical method of prolonging the secure use of hash functions. This
is useful for applications such as timestamps and non-revocable
signatures, because these may have to be valid for very long periods.
An attacker could mount a collision attack by predicting the signature
calculation and preparing two documents with colliding hash values.
One document would be signed by someone other than the attacker, the
other document would be exploited with that signature attached.
Such attacks can be avoided if the signer makes the signing process
unpredictable to the attacker. The simples way to do that is to
generate random octets per signature, under full control of the signer,
and include them in the hashed subpackets of a signature packet.
The number of random octets SHOULD match the length of the hash used in
the signature. This subpacket MUST NOT be flagged as critical and MAY
remain without interpretation in the verification process.