Re: [openpgp] Followup on fingerprints

On 8/9/15 at 9:23 AM, iang(_at_)iang(_dot_)org (ianG) wrote:

> > There has also been an undertone of, "If we can't come up with an
> > attack, there aren't any." in this thread.
>
> I disagree with that characterisation.  I would rather see it like this:
>
> If we can't come up with an attack,
> then we should not defend against it.
> We should *accept the risk*.
The specific issue I was addressing was PHB's source code 
checkin attack. Most of us, me included, thought that specific 
attack was not very convincing. However, to my mind, there may 
be other, more serious attacks using the same basic mechanism. 
Just because we can't think of them doesn't mean we shouldn't 
defend against them.
Using all the bits of the key fingerprint hash is probably good 
a good enough defense against these unanticipated attacks, and 
we should state that in the security considerations section. A 
better defense would be to use the key itself, but that is 
probably overkill in most situations.
> > I find this attitude very
> > dangerous as new classes of attacks (e.g. power analysis) are constantly
> > being discovered.
>
> 1. when that information develops, we can "come up with the 
> attack." This stops us drifting into lab myopia.
> 2. How is power analysis going to effect a hash?  Surely, if I 
> can do power analysis, I'm not that concerned about the hash, 
> I'd rather suck the key bits?  OK, I know it was an example... 
> but this is an example of "not an attack."
Power analysis was an example of a class of attack that came up 
late in the security analysis field and exposed a significant 
number of vulnerabilities. It is not a attack against hashes. 
Those are more likely to be new mathematical techniques.

> > I would suggest wording in the security considerations section something
> > like:
> >
> > "During the design process, any application using key fingerprints
> > SHOULD characterize the consequences of a fingerprint collision on the
> > application's security and implementation integrity, particularly when
> > using fewer bits than the output of the fingerprint hash."
>
> If we're talking about a mid-range published key fingerprint of 
> say 100 bits, then there is a capability for collisions and 
> perhaps preimages in the future, sure.
> But we have a built in mechanism for that already;  increase to 150 then 200.  
> So how about:
>
>
> "During the design process of any application using shortened 
> key fingerprints, attention should be paid to a recovery 
> strategy in the event that the shortened fingerprint becomes 
> subject to collisions or preimage attacks."
My problem with that statement is that there is no incentive to 
analyse the failure mode of the application should a collision 
occur. I agree that a collision is far more likely to be due to 
a hardware or software error than a hash failure, but performing 
the analysis can make the application more robust.
Let me return to my straw man example of a application that 
routes messages based on key fingerprint. If it assumes that 
there is only one routing address/fingerprint, and there is a 
collision, then it will route all the colliding messages to one 
address. If it assumes that there may be more than one address, 
then it will route all colliding messages to all the address. In 
the later case, the receivers will not be able to decrypt all 
the messages, but the messages encrypted to them will get 
through, a more robust situation.
Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Security is like Government  | Periwinkle
(408)356-8506      | services. The market doesn't | 16345 
Englewood Ave
www.pwpconsult.com | want to pay for them.        | Los Gatos, 
CA 95032
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp