[guardian-dev] Messaging Moving Forward

[Timur]

On 19.05.2013 22:26, Michael Rogers wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 18/05/13 19:11, Hans-Christoph Steiner wrote:
>> I like the general idea of the actual contact address being
>> something that changes frequently, and is then communicated to
>> contacts when there is a live connection between them, something
>> like "next time we talk, call me at 987239871ef1b123b".  There are
>> two hard problems here:
>>
>> 1) how do you find new contacts?  If you give a new contact the
>> address 908a80a8b10810fe0, then you need to keep that one active
>> until that contact makes the connection.  What if they never do, or
>> it takes them a few months? Then you have something that is
>> basically the same as the standard long-lived registration.
>>
>> 2) what about contacts that are not regularly talking to each
>> other?  Or there is a long gap in correspondance?  Its again the
>> problem above, you need to keep a long lived ID, otherwise you'll
>> loose contact.
> I guess you could take an approach similar to the one used for forward
> secrecy in Briar: each pair of contacts would establish a shared
> secret and use it to generate identical pseudo-random sequences, from
> which they could derive each other's temporary identities for any
> given period.
>
> So Alice and Bob would both know that on 20 May 2013, Alice would be
> dvnbwvveirbvhbrjshdgebok at example.com and Bob would be
> jahgkjgdkjadvbjhbvekwrbc at example.org, but nobody else would be able to
> link those identities to Alice and Bob's other temporary identities.
>
> (Someone wiretapping the conversation would, however, be able to tell
> that Alice and Bob were using the same long-term OTR keypairs.)
>
> Cheers,
> Michael

If someone, situated "close to the chat infrastructure" and able to 
wiretap all conversations would (say, years later) get access to a 
shared secret - they would be able to refit the pseudo-random sequence 
and find out that in all cases A was A and B was B. At least in theory.

My counter proposal would be, to have the clients create ID's for, say, 
1,000 sessions and share them off-line. My preferred solution would be a 
NFC+Bluetooth (or NFC+WiFi Direct) based solution. "Beaming over" 1,000 
random session ID's (16 KB for 16 byte ID's) would only take a few 
seconds. And, if not fully renewed at an upcoming rendezvous, these 
session ID's could be reused in round-robin fashion, (I think) without 
exposing any identity. However, I would prefer to delete them after use.

I implemented a similar NFC+Bt/WiFiDirect experiment a while back: 
http://www.youtube.com/results?search_query=anymime
The code is on: https://github.com/mehrvarz

- Timur

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130520/d268a909/attachment.html>