Re: [OTR-dev] OMEMO, PFS
Thijs Alkemade writes: > Suppose Bob's ephemeral keys are compromised by an attacker at a specific > time, then the attacker can decrypt all messages from Alice since the last > time Bob sent Alice a message before the compromise, up to (and including? I'm > not clear on that) the first time Bob sent a message after the compromise. > Once Bob sends a new message, the key material changes and the ephemeral key > becomes useless. Thanks. That makes perfect sense. So you have PFS that has issues in time, but reset once you ratchet forward -- and actually erase the previous cases from all places in which they were persisted. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
> On 13 nov. 2015, at 17:43, Greg Troxel wrote: > > > Nathan of Guardian writes: > >> On Tue, Nov 10, 2015, at 04:15 PM, Greg Troxel wrote: >>> >>> I am curious if anyone from OTR-land has comments about the pros and >>> cons of OMEMO vs OTR. >>> >>> http://conversations.im/omemo/ >>> >>> In using smssecure as well as OTR, I notice an interesting property >>> which is more about the implementation than the protocol, which is that >>> keymat is stored persistently. So after having an smssecure session >>> with Alice (not her real name :-) in early June, and no texts since, I >>> was able to send one just now, and have both of our devices still have >>> the keymat and have it work. Of course that means it has persisted in >>> flash across reboots. >> >> 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 key is persisted on permanent storage (and potentially backed up multiple times in unerasable locations), but the protocol is designed to make sure that compromising a single ephemeral key has the smallest impact possible. Suppose Bob's ephemeral keys are compromised by an attacker at a specific time, then the attacker can decrypt all messages from Alice since the last time Bob sent Alice a message before the compromise, up to (and including? I'm not clear on that) the first time Bob sent a message after the compromise. Once Bob sends a new message, the key material changes and the ephemeral key becomes useless. [1] probably explains this a lot better. Prekeys have nothing to do with this, they are only used to create new sessions when the other side is offline. Once the session is set up, they shouldn't need to use each-other's Prekeys again. Regards, Thijs [1] = https://whispersystems.org/blog/advanced-ratcheting/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Ruben Pollan writes:
> Quoting Greg Troxel (2015-11-13 17:43:06)
>> Nathan of Guardian 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.
signature.asc
Description: PGP signature
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Quoting Greg Troxel (2015-11-13 17:43:06) > Nathan of Guardian 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/ -- Ruben Pollan | http://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: http://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Nathan of Guardian writes: > On Tue, Nov 10, 2015, at 04:15 PM, Greg Troxel wrote: >> >> I am curious if anyone from OTR-land has comments about the pros and >> cons of OMEMO vs OTR. >> >> http://conversations.im/omemo/ >> >> In using smssecure as well as OTR, I notice an interesting property >> which is more about the implementation than the protocol, which is that >> keymat is stored persistently. So after having an smssecure session >> with Alice (not her real name :-) in early June, and no texts since, I >> was able to send one just now, and have both of our devices still have >> the keymat and have it work. Of course that means it has persisted in >> flash across reboots. > > 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. > In addition, for ChatSecure, we proactively generate session keys for > OTR, so that if you have an open conversation thread with someone, and > they are online AND we detect they have a compatible XMPP resource, we > start the OTR negotiation process. If you receive a message you cannot > decrypt, we renegotiate the session, and then thanks to delivery > receipts, the sender should then know to re-send the previous > undelivered messages. The goal is to make OTR as automatic as possible, > while still maintaining PFS, as much as possible. We only keep OTR > session keys in RAM. That makes sense. I didn't realize delivery receipts were wrapped up in that, but it makes sense to reuse that vs rolling your own inside OTR. Probably chatsecure is doing this better than other clients; I tend to use OTR more with Adium and pidgin, just because I don't tend to xmpp on my phone. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
On Tue, Nov 10, 2015, at 04:15 PM, Greg Troxel wrote: > > I am curious if anyone from OTR-land has comments about the pros and > cons of OMEMO vs OTR. > > http://conversations.im/omemo/ > > In using smssecure as well as OTR, I notice an interesting property > which is more about the implementation than the protocol, which is that > keymat is stored persistently. So after having an smssecure session > with Alice (not her real name :-) in early June, and no texts since, I > was able to send one just now, and have both of our devices still have > the keymat and have it work. Of course that means it has persisted in > flash across reboots. > > So it seems obvious that PFS is not a binary property; presumanbly the > keys are overwritten (seems hard with flash wear leveling) when new > messages happen, but there is a perhaps-months "short term key", vs a > maybe-years "long term key", and PFS or not becomes blurry. > > Keeping the keys definitely helps usability, but part of that is how OTR > (in adium) doesn't necessarily recover from a half-closed session > seamlessly. 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. In addition, for ChatSecure, we proactively generate session keys for OTR, so that if you have an open conversation thread with someone, and they are online AND we detect they have a compatible XMPP resource, we start the OTR negotiation process. If you receive a message you cannot decrypt, we renegotiate the session, and then thanks to delivery receipts, the sender should then know to re-send the previous undelivered messages. The goal is to make OTR as automatic as possible, while still maintaining PFS, as much as possible. We only keep OTR session keys in RAM. That said, we really do like OMEMO, and do have plans to support it in our next-generation app, Zom. -- Nathan of Guardian nat...@guardianproject.info ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Ximin Luo writes: > Hi Greg, allow me to refer you to a previous post I wrote: > > https://moderncrypto.org/mail-archive/messaging/2015/001877.html > > The TL;DR is that to achieve "forward-secrecy for in-transit messages" > you need to have some sort of timeout mechanism, as opposed to using > cryptographic techniques. I'm not sure if people have engineered this > specifically into any protocols, but it would be more of an > engineering task than a cryptography task. That's a good point. I think timeouts are independent of persistence, except that without persistence you need to have a way to recover from sooner-than-intended loss of keymat. In the OTR world, is there a notion that implementations MUST NOT persist keys in ways that could survive a power cycle? (more or less - not trying to argue RAM permanence, but more that RAM and flash are very different points in the space) Or is this a local option for implementors? signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Date: Tue, 10 Nov 2015 17:10:21 -0500 From: Greg Troxel Taylor R Campbell writes: > PFS is indeed not a binary property. Aside from confusion arising > from the loaded word `perfect' in `perfect forward secrecy', some > people argue against using the term at all in favour of `key erasure', > and of stating when the relevant keys are erased. A fair point. I would argue, though, that most people would consider that "PFS" is only achieved when the keys that need to be erased are never written to permanent storage. So I'd add "where stored" to "when erased". I personally, am not confident that I can erase flash. Yes -- that's part of the point of emphasizing the concept of key erasure. There are qualitative differences between: - a per-conversation key that persists in RAM for an on-line conversation, - a per-conversation key replaced after every message like OTR, and - a key that is written to permanent storage. Another relevant part of it is /what/ key? Does the OMEMO key enable decryption of any past messages, or only the very next message that you might send two months later? Either possibility is conceivable. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Taylor R Campbell writes: >Date: Tue, 10 Nov 2015 16:15:58 -0500 >From: Greg Troxel > >So it seems obvious that PFS is not a binary property; presumanbly the >keys are overwritten (seems hard with flash wear leveling) when new >messages happen, but there is a perhaps-months "short term key", vs a >maybe-years "long term key", and PFS or not becomes blurry. > > PFS is indeed not a binary property. Aside from confusion arising > from the loaded word `perfect' in `perfect forward secrecy', some > people argue against using the term at all in favour of `key erasure', > and of stating when the relevant keys are erased. A fair point. I would argue, though, that most people would consider that "PFS" is only achieved when the keys that need to be erased are never written to permanent storage. So I'd add "where stored" to "when erased". I personally, am not confident that I can erase flash. signature.asc Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
Date: Tue, 10 Nov 2015 16:15:58 -0500 From: Greg Troxel So it seems obvious that PFS is not a binary property; presumanbly the keys are overwritten (seems hard with flash wear leveling) when new messages happen, but there is a perhaps-months "short term key", vs a maybe-years "long term key", and PFS or not becomes blurry. PFS is indeed not a binary property. Aside from confusion arising from the loaded word `perfect' in `perfect forward secrecy', some people argue against using the term at all in favour of `key erasure', and of stating when the relevant keys are erased. ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] OMEMO, PFS
On 10/11/15 22:15, Greg Troxel wrote: > So it seems obvious that PFS is not a binary property; presumanbly the > keys are overwritten (seems hard with flash wear leveling) when new > messages happen, but there is a perhaps-months "short term key", vs a > maybe-years "long term key", and PFS or not becomes blurry. > Hi Grey, allow me to refer you to a previous post I wrote: https://moderncrypto.org/mail-archive/messaging/2015/001877.html The TL;DR is that to achieve "forward-secrecy for in-transit messages" you need to have some sort of timeout mechanism, as opposed to using cryptographic techniques. I'm not sure if people have engineered this specifically into any protocols, but it would be more of an engineering task than a cryptography task. X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
