[Freedombox-discuss] Tap-to-share PGP key exchange

[Boaz]

On 10/04/2011 04:45 PM, Timur Mehrvarz wrote:
>But we may be there already.
>
>Excerpts from "BLUETOOTH SPECIFICATION Version 3.0 + HS":
>
>--- quote ---


On 10/04/2011 05:02 PM, Nick Daly wrote:
>A bluetooth pairing offers a 1 in 10^6 bruteforce chance.  A PGP key offers a 1 in 2^1024 (or smaller) bruteforce chance. PGP keys are built for long term security against extended >bruteforce attacks.

On 10/05/2011 01:46 AM, John Gilmore wrote:
>Bluetooth has never been better than a pain for me, and its security
>is close to nil - a 4 digit number at best, often set to "0000".)

Please don't assume that because the verification string is low
entropy, that it necessarily does not serve its function.

While the excerpt from BLUETOOTH SPECIFICATION Version 3.0 + HS that
Timur has quoted is not detailed enough to really know what they've
done, I want to stress the following:

Cryptographically, It is possible to securely initiated a connection
(with the property that the worst a MITM can accomplish is prevent the
connection from successfully going through), based on verification of
a very low entropy verification string.

This is done, for example, in ZRTP (
https://secure.wikimedia.org/wikipedia/en/wiki/ZRTP ), where
comparison by voice of two words packing just 16 bits of entropy
prevents a MITM attack.

It works by each side committing to the fullness of their key via a
hash, before transmitting the key itself.  In this way, the attacker
doesn't get to sit there and try zillions of possibilities looking for
one that produces the right verification string (as he does when
trying to attack a traditional key fingerprint, which is why they must
be very high entropy).  Instead, the attacker must guess once and
guess right what to do hoping it will randomly result in the right
verification string.  I hope important distinction between "how many
computations the attacker needs to do" (for which 10^6 or 2^16 is
hopelessly inadequate and something like 2^160 is needed), and "among
how many possibilities must the attacker pick a single one randomly"
(for which 10^6 or 2^16 will do just fine) is clear.

Personally, I think that this "short authentication string"
verification by a secure means (e.g. physical proximity or familiarity
of voice) holds tremendous promise.  I fear that people are dismissing
it because they don't understand how it can actually work,
cryptographicly.

If you're curious to learn more about how this principle works, as
implemented in ZRTP, please write me on or off the list and I'll be
happy to provide additional explanation and links to further
information (there are some sources out there which explain this very
well).

That said, I'm not trying to plug the security or other merits of
Bluetooth generally or the authentication method described in the
excerpt Timur quoted specifically. In fact, the same excerpt revealed
that the protocol uses (for the part that does need to be high
entropy), a pathetic 95 bits, and I seem to recall reading that
Bluetooth can be reliably attacked with off the shelf solutions
(perhaps I'm mistaken about that).  Not to mention that Bluetooth is
severely patent encumbered.