I should clarify a bit - it's more directly to do with *storing* decryptable ciphertext (or plaintext, even) somewhere, and indirectly to do with multiple devices. If you log your 2-party OTR conversations, it kind of defeats the point of forward secrecy too - the adversary might not be able to decrypt the ciphertext, but if they can compromise your long term key they can probably just compromise your logs. Again, this risk is dependent on your own preference; storing data *is* convenient and useful.
With multiple devices, you can do forward secrecy if you know in advance which devices you want to encrypt to - then this is just the mpOTR group chat problem. (The "maximum you can achieve" I mentioned in the last post.) Then you hope no-one else logs - if any single person logs, then it screws the forward secrecy for everyone else. So it's harder and less reliable, but not impossible. But if you want a scheme where any device that you might want to connect to your account (in the future) can decrypt old history, then I don't think you can get true forward secrecy, since this would likely involve storing the history somewhere with a key that doesn't get destroyed. There's no impossibility result that I know of, but no "breakthrough" yet either.. X On 31/10/14 14:41, Nadim Kobeissi wrote: > Dear Ximin, > Thanks very much for your explanation. Unfortunately, it only confirms my > pessimistic assumptions regarding the possibility of true forward secrecy on > multiple devices. I was hoping this list would be aware of some kind of > breakthrough I've missed out on, but that doesn't seem to be the case. > > Hope you're doing well. :-) > > NK > > ------ Original Message ------ > From: "Ximin Luo" <[email protected]> > To: "messaging" <[email protected]> > Sent: 2014-10-31 10:14:04 AM > Subject: Re: [messaging] Forward secrecy and multiple devices > >> Forward secrecy is the inability to decrypt ciphertext after it's been >> decrypted the first time, by throwing away (enough of) the decryption >> key-material. If you want to be able to decrypt it indefinitely onwards, it >> defeats the point. >> >> If you want to encrypt a message to multiple devices in a forward-secret >> way, the maximum you can achieve is to have it decryptable (i.e. not forward >> secret) until the last device that reads the message throws away its >> ephemeral decryption key, at which point you gain the property of "forward >> secrecy". >> >> As long as key material exists somewhere to be able to decrypt whatever >> ciphertext you store wherever, *by definition* this situation is not >> forward-secret. Sorry... >> >> The schemes other people described are forward-secret for only *part* of the >> message lifetime. It may be the case that these "partial" forward-secrecy >> schemes make sense for certain use cases. For example, if the (re-encrypted) >> ciphertext is only exposed on private infrastructure e.g. locally on each >> target device, or on "trusted third-party infrastructure" (lol), this may >> arguably be a bit safer than simply storing the original ciphertext (that >> was seen by the adversary) and ephemeral key. This is dangerous territory to >> go into, though. >> >> X >> >> On 31/10/14 13:04, Nadim Kobeissi wrote: >>> Hi everyone, >>> I've been wondering about how to make asynchronous forward-secret >>> messaging systems work when the user is accessing message history from >>> multiple devices. >>> >>> Say I send a bunch of messages from computer A to another user's computer >>> U. >>> Later, I buy myself a new computer B on which I want to download and >>> decrypt my message history. >>> >>> If the messages I sent all relied on my long-term identity, then I can >>> just use my long-term key pair to decrypt the messages on computer B and >>> there wouldn't be a problem. >>> >>> However, I am wondering how that would work in case I was using >>> forward-secret session keys that changed message by message. How would the >>> session secrets be communicated across devices? How would computer B be >>> able to decrypt my forward-secret messages sent from computer A? >>> >>> It would be great to hear the opinion of the many experts on this list >>> regarding this matter. >>> >>> Regards, >>> NK >>> >> >> -- >> GPG: 4096R/1318EFAC5FBBDBCE >> git://github.com/infinity0/pubkeys.git >> > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
