[Cryptography] What is a secure conversation? (Was: online forums...)

[Jerry Leichter]

On Dec 29, 2013, at 11:28 PM, ianG <iang at iang.org> wrote:
>> Except that there is a line at synchronous vs. asynchronous
>> communication that divides mechanisms with fundamentally different
>> characteristics.  Synchronous communication can have perfect forward
>> security; asynchronous communications cannot.
> Is that really the case?  Synchronous comms can be recorded on or at the node, it is only "on the wire" that it is somewhat easy to do things like expunging ephemeral keys, but we've known for a long time that what we can on the wire does not mean that this is the security job done.
> 
> In the alternate, asynchronous comms can have the same characteristic, if the defence is deleting the keys.
After some more thinking about this:  Yes, the difference is fundamental; but the terms "synchronous" and "asynchronous" are almost incidental.

What's really different is whether there needs to be a round-trip communication before new data can be transmitted.  Consider basic DH, which is at the root of the PFS algorithms on the table.  (I'm using PFS as an acronym for Protocol-based (key) Forward Security.  :-) )  Alice, as the initiator, cannot send Bob any data before receiving Bob's initial response, since she only knows her exponent, not Bob's, hence doesn't know what key to encrypt with.  This is why chat with OTR can't be easily converted to "email with OTR", unless you're willing to go back to pre-SMTP, pre-queued messaging.  (Which, BTW, is not as absurd an idea as it appears.  The Internet isn't what it was back when SMTP was designed.  Most hosts are up most of the time; most connections are live most of the time.  Mobile hosts excepted - and they have other issues.)

When you look at it this way, the magic properties of PFS seem much less magic. If I'm communicating with you, we could establish a key, then after each message replace the key by its one-way hash and discard the previous key.  Compromise of an endpoint doesn't allow the decryption of anything sent earlier.  The receiver knows how to decrypt the next message that will arrive; the sender knows how to encrypt the next message to be send (but doesn't know how to decrypt any of its own previous messages).  The lockstep nature of OTR disappears:  A sender can pipeline a whole bunch of messages, each with its own key, without waiting for anything from the receiver.  It's kind of neat, actually, that in this scheme the sender can have an arbitrary number of encrypted buffers sitting in its own memory, but seizing it *does an attacker no good at all*:  The sender may have created those buffers, but it has no way to decrypt them!  Sure, having seized the sender, the attacker can send new data that the receiver will accept - but that's impossible to avoid under the assumption the "seizing the server" means grabbing all of the state that drives it.  (However, assuming the sender is using an authenticated mode, the attacker can't send any new information without first sending all the pending buffers.  If he sends nothing, the receiver will be out of sync on the key and nothing the attacker sends will authenticate.  If he sends garbage, it, too, will fail to authenticate.  Either way, the receiver will get suspicious.  He'd better hope that the sender didn't realize he was about to be captured and send an "under attack, ignore all after this" message as his last gasp!)

OTR-like protocols have an advantage if the attacker can clone all the state in one of the participants, but can't actually seize them (so they go on communicating as if nothing happened).  With OTR, the seized copy allows the decryption of data only up to the next DH exchange - which requires a round trip.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131230/18de788e/attachment.bin>