Re: [openpgp] Followup on fingerprints

[Phillip Hallam-Baker <[e-mail]>]

OK one thing from the meeting I forgot to mention, the security
considerations have to address the use of a birthday attack by someone
generating keys.

If we are doing ECC, it is quite practical for someone to generate 2^50
keys and then pick the two that match in the first 100 bits. This can then
be used for attacks, particularly if the keys are not enrolled in some sort
of blockchain.

The other bit I left out is the idea of compression. The idea here being
that the person generating the key looks for a fingerprint that has 0s for
the first n bits. Then the fingerprint starts with a version number that
says 'the first 32 bits are 0s' or whatever.

Yet another bit that should be mentioned in the security considerations is
vanity fingerprints which are going to be more popular with all 26 Latin
letters to choose from. And those are a bad idea for the reason given in
the meeting. If my key starts off 'MERLI-Nxxxx' there is a temptation to
only check those bits.

Two important advantages of compression is that it provides an alternative
to vanity fingerprints (shorter is better than fancy for most folk) and the
work factor is not reduced by the birthday attack.


Without compression, a 100 bit fingerprint is 20 characters and 150 bits is
30. The work factor for a birthday attack are 2^50 and 2^75 respectively

With 32 bits of compression, the same strength against third party attack
is achieved. with 14 and 24 characters. The work factor for a birthday
attack are 2^66 and 2^81 respectively


On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch <[e-mail]> wrote:

> On Tue, 28 Jul 2015 16:52, [e-mail] said:
>
> > * Contact some usability types to ask about usability and changing up the
> > block sizes.
>
> OpenPGP does not specify a user interface but the wire format.
> Obviously we use the most compact format there which is the plain binary
> format.  The questions are
>

That is how we used to work in the 1990s. Since then we have had to do
internationalization and such.

As I started saying back then, the hardest part of a transaction to secure
is the first/last two feet between the user's head and the screen.



>   - Do we need to explicity indicate the fingerprinting scheme (SHA-1 or
>     SHA-256, or whatever) in the binary represenation.
>

Yes, totally. I am suggesting we put code points in for the SHA-2-512
digest and the SHA-3-512 digest.

The reason for going for the big digest even though we plan to truncate is
that gives us maximal insurance against a compromise. These are the trust
axioms of the system.



>   - Do we need truncation and how do we indicate a fingerprint scheme
>     then given that it can't be deduced from the length.
>

My preference is to just truncate and use the inferred length. That allows
us to minimize the amount of data we need to put in front of the user
without compromising security.

Lets say that in 2020 Alice meets Bob and they exchange their fingerprints
via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the
corresponding profile which has Bob's key and full 512 bit fingerprint. The
phone then stores the big fingerprint for Bob in her contacts directory.

I cannot imagine wanting to rely on a contract signature without pulling
the full record.



>   - Should we bind a certain fingerprint scheme to a public key packet
>     versions as we did in the past (v3 = MD5, v4 = SHA1, maybe v5 =
>     SHA256 with keyid being the leftmost octets).  Or is it okay to
>     allow for multipe fingerprint schemes for the same key.


This is the 'domain separation' issue that was mentioned in the meeting.

I believe that we have to be able to revise the algorithm used to revise
the fingerprint and the format of the data being formatted independently.

As far as OpenPGP goes, the version indication inside the key packet should
be sufficient for v5. The only reason the version indication would not be
sufficient would be if a completely radical change to the format was being
considered such as moving all the structures to YANG, CBOR, JSON or JSON-B.

The proposal I have made is capable of dealing with that type of change
with clean cryptographic separation of the content domains.