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

[Ted Smith]

Sorry, I don't generally click links I get from list emails when there
are as many as there were in your initial email. 

So, it seems that your app uses Bluetooth to transfer key material, and
then relies on users manually verifying fingerprints. In contrast, the
QR-code app maintained by the Monkeysphere team uses QR codes to
transmit fingerprints, and then fetches those keys from the keyserver
network (dkg, does monkeysign do anything after that to verify the key
that's been downloaded?).

It seems like monkeysign is a fingerprint verification app that lacks a
good transport mechanism (personally, I think going to the keyserver
network is fine, but others have complained, and I know some people who
want to use OpenPGP but not depend on keyservers), while anymime-ksp is
a transport mechanism that lacks a good fingerprint verification system.
I think we can win the most by integrating the two apps.

Is it possible to use Intents from another app to transfer files over
anymime? Or is it possible to do the same to allow monkeysign to verify
fingerprints from anymime-ksp? I'm not an android expert, but that seems
like the best way of going about doing this. 

On Fri, 2011-09-30 at 16:09 +0200, Timur Mehrvarz wrote:
> I provided this with my original post: http://timur.mobi/anymime-ksp/
> Can you please phrase your concern relative to the fingerprint
> verification example?
> 
> On 30.09.2011 15:50, Ted Smith wrote:
> > So, how can a user verify that the key material comes from the expected
> > peer? I know nothing of bluetooth and NFC, so instead of describing
> > low-level protocols (which in most cases are NOT implemented using free
> > software and CANNOT be naively trusted), please describe what I'd see
> > using your app.
> > 
> > On Fri, 2011-09-30 at 13:46 +0200, Timur Mehrvarz wrote:
> >> DKG, your impression that there is no security in place when using
> >> Bluetooth and NFC is not true. Anymime uses encrypted and
> >> authenticated communications only. And NFC does not just make the
> >> procedure much more usable, it also removes the weakest spot with
> >> "long range" Bluetooth: device discovery. What is needed now is that
> >> people play with it and try to break it. And more devices with NFC
> >> chips must become available.
> >>
> >> I will prepare another reply with more info, just need a bit more
> >> time. My impression is, that those who specify and implement the lower
> >> layers are honest about security. Also keep in mind that payment is
> >> one important use case here. Why not benefit from the effort?
> >>
> >> I'm following this list long enough to be aware of the QR discussion.
> >> I think both technologies need to be implemented for key exchange. If
> >> someone comes to you with QR code printed on a business card, your NFC
> >> chip won't help much.
> >>
> >> Thank you Stefano + Michael for your encouraging words.
> >> Timur
> >>
> >> On 29.09.2011 17:45, Daniel Kahn Gillmor wrote:
> >>> i'm concerned that bluetooth and NFC don't provide much protection
> >>>  against spoofing.  that is, can the operator of a device using 
> >>> these technologies verify that the communication comes from the 
> >>> expected peer? or is it possible for a nearby attacker with
> >>> control over the RF spectrum to inject messages into the
> >>> communication?
> >>>
> >>> The advantage of the optical approach (QR codes and webcams) 
> >>> discussed some months ago on this list (see posts about 
> >>> "monkeysign" and "manus vexo") is that a (sighted) human user can 
> >>> observe the communication between devices directly and ensure that 
> >>> there is no tampering.
> >>>
> >>> Is there some mechanism with bluetooth or NFC that offers 
> >>> equivalent protection from network interference?
> >>>
> >>> --dkg
> >>>
> > 
> > 
> > 
> > _______________________________________________
> > Freedombox-discuss mailing list
> > Freedombox-discuss at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110930/65a107ed/attachment-0001.pgp>