[messaging] Forward secrecy and multiple devices

[Ximin Luo]

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" <infinity0 at pwned.gg>
> To: "messaging" <messaging at moderncrypto.org>
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141031/2db99bc2/attachment.sig>