[OTR-dev] OMEMO, PFS

Greg Troxel gdt at ir.bbn.com
Fri Nov 13 14:21:43 EST 2015


Ruben Pollan <meskio at sindominio.net> writes:

> Quoting Greg Troxel (2015-11-13 17:43:06)
>> Nathan of Guardian <nathan at guardianproject.info> writes:
>> > Are you sure it was persisting key material? I think the idea with OMEMO
>> > is to support the Axolotl/TextSecure pre-key technique using XMPP
>> > infrastructure. This means, you can create a valid session key without
>> > the other party needing to be online.
>> 
>> I guess I need to go reread the protocol.  I don't understand how one
>> can create a session key that is used to send a message to a
>> perhaps-offline party can work unless the other party is persisting the
>> key needed to decrypt.
>
> The basic idea is that you generate a bunch of pre-keys (your part of the 
> diffie-hellman protocol) and store them in a server. When someone wants to 
> communicate with you and you are not online fetch an unused pre-key from the 
> server and write you a message with it and her part of the shared key:
> https://whispersystems.org/blog/asynchronous-security/

That makes sense.  But when you generate the prekeys which are something
like x_i, g^{x_i) and publish g^{x_i}, then presumably you have to hang
onto x_i, which may mean storing it in flash vs ram.  Or have some
long-term secret that is used to derive it, but no one seems to be doing
that.

I am not trying to complain about this - I see it as a hard-to-avoid
PFS-strength vs availability tradeoff, which then gets into whether the
keys get into backups, and how one overwrites flash I would just like to
be clear about it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20151113/a290098e/attachment.sig>


More information about the OTR-dev mailing list