[Freedombox-discuss] Follow up to the FreedomBox 'bump/hi-five' challenge

erik.e.harmon at gmail.com erik.e.harmon at gmail.com
Fri Jun 24 00:58:39 UTC 2011


Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

>On 06/23/2011 07:58 PM, Erik Harmon wrote:
>> Why not just generate an ephemeral 256-bit AES key, encode that as a
>> code, then the freedombox owner transmits their ip address and entire
>> including sigs using that key?
>We need to move away from thinking of an IP address as any sort of
>permanent or identifiable resource, so i don't think that necessarily
>belongs in the information we're talking about here, unless we're
>talking about an acknowledged-to-be-volatile address.

Not that it's permanent, but I figured it would ease the first time connection to the person's freedombox without any sort of lookup.

>> Via bluetooth, nfc, wifi, or whatever. The qr
>> code becomes of reasonable size, there's very low chance of
>> and the you can transmit as much as you want right then and there.
>this works assuming both parties have the same set of bluetooth, nfc,
>wifi, or whatever technologies available at the same time.  In my
>to this list on 2011-06-14, you'll note that i suggested the same

Woops, sorry about that. Also sorry for top-posting, list.

>on 2011-06-14, in Message-ID: <4DF7F072.7090606 at fifthhorseman.net>, dkg
>>> If you want to avoid snooping as well as spoofing, you could
>transmit a
>>> session nonce within the QR code, and broadcast the key encrypted
>>> the session nonce.
>However, I don't think this absolves the handshake of the need to
>transmit the public key fingerprint in *addition* to the ephemeral AES
>key (which i called more generically the "session nonce") in the
> Getting the fingerprint via a non-spoofable channel (the line-of-sight
>QRcode) is a critical double-check that the information received via
>spoofable means (wifi, bluetooth, etc) is actually the data from the
>intended sender.

I think this is perfectly reasonable. My reason for going back to the nonce is, while qr codes can hold an unsigned 2048 bit public key, the qr code will be unwieldy and hard to photograph. Extra onscreen verifiable information is great, I just want to prevent huge qr codes if possible since I've had trouble with those.

Maybe a negotiation of how to transmit could be included in a few bits of the qr code, set by phone capabilities and mutual security concern, including qr-code only?


>for a concrete example:  let's say Alice shows Bob a QRCode which just
>contains the ephemeral AES key.  If Mallory can sneak a peak at the
>QRCode, she can broadcast (via the same means as Alice any arbitrary
>information, encrypted with that same session key.
>But if Alice's QRCode shows both a session key and her fingerprint,
>any faulty information provided by Mallory will be flagged immediately
>by Bob's client as invalid, because the fingerprint does not match.  In
>this case, Mallory can still snoop on the transaction (because she
>caught a glimpse of the QRCode) but she can't reliably inject malicious
>content;  Bob's client is protected from malicious content because it
>discards anything that does not match the message digest (the
>	--dkg

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

More information about the Freedombox-discuss mailing list