Re: [openpgp] Fingerprints and their collisions resistance

[ianG <[e-mail]>]

On 3/01/13 10:18 AM, Andrey Jivsov wrote:

> As a remedy to the problem note that the collision resistance only
> arises when the original "document" is not available. Fortunately, keys
> are small, and therefore, the suggested enhancement to the RFC4880 to
> remedy the collision dependence of fingerprints on SHA-1 is to store the
> original key. Continuing the above example with non-repudiation, the
> non-repudiation claims will be made against the application logs (i.e.
> audit trails), thus it will be necessary to include complete keys in
> addition to fingerprints in logs that record protocol exchanges that are
> dependent on public key identification.
>
> This concern will need to be communicated somehow to developers that are
> relying on RFC4880.


I agree with this approach.  It means no change to the tech in the short 
term, just a note that is distributed (perhaps added in any next 
revision or additional ID):  to insure against future key collision 
possibilities in high-security application, store the full key with any 
fingerprint.

> An alternative method is outlined next. We introduce a new hardwired
> fingerprint, for example, based on SHA-3. The above-mentioned
> application logs can simply state that "SHA-3 fingerprint is XXX" and
> not bother with storing the whole key (which is unfortunately allowed to
> change, for example, by acquiring new userIDs, making it hard to compare
> the revisions). Any subpacket that currently takes the fingerprint will
> be able to take the new SHA-3 fingerprint as well. Applications will be
> expected to calculate two fingeprints in parallel and perform a match
> with either of them. In addition, we might consider a features packet
> forcing or preferring SHA-3 fingeprint (similar to the MDC feature).
> KeyIDs in messages can also use 8 bytes of the new fingerprint.


Now that SHA-3 is settled, it seems reasonable to clean out all of the 
SHA-1s.

It would be nice if this were to take place within an overall 
refurbishment of the entire suite, e.g., OpenPGP 5 or whatever one calls 
it.  Any change is going to be disruptive, and confusion out in userland 
with different feature/time/brand sets leads to loss of users, which 
isn't really any good compensation for the illusory security advantage 
of replacing SHA1.


...
> I will appreciate your comments on this feature. I don't expect this to
> be a task that needs an urgent resolution. In my mind this is something
> that we agree on, have a simple spec, and then take a few years to
> implement and deploy it in a least disruptive way.


+1  It would be ideal if we could select a single small fixed suite of 
everything that would last for the next 2 decades.

> If there is a more elegant/simpler solution? I would like to hear about it.


On another related point - have the MD numbers been allocated for SHA3 
in its various guises?

iang