[guardian-dev] Messaging Moving Forward

[Hans-Christoph Steiner]

On 05/19/2013 04:26 PM, Michael Rogers wrote:
> 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

Right, of course!  So the server would see the traffic, and be able to see the
OTR keys that were used, so then we really don't gain much at all with all
this extra complicated system of generating temporary registrations unless
everything else is similarly randomized.

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 939 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130519/754ee74b/attachment.pgp>