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

ianG iang at iang.org
Thu Jan 2 00:19:29 EST 2014


On 30/12/13 23:35 PM, Jerry Leichter wrote:
> 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.


Yes, they are almost implementation terms.  At the core is the 
coordination problem, aka 2 generals.  Where they get mushed up is that 
the user experience is either synchronous or async (when i'm sending 
email or chat, I think differently), but underneath it's both or 
neither, it's just what we do with protocols.


> 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.  :-) )


Nice!  Let's capture that term and use it!  Protocol Forward Security, 
PFS, repeat 3 times while brushing teeth...


> 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.

Indeed.  The assumption of asynch, not the reality.

> (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.)


This begs the question why email innovators haven't tried this more ... 
and reminds me that email is as dead as a dodo when it comes to future 
enhancements.

Which is why certain smart people are saying that their future email 
will be like email but won't be email as the techies know it.


> 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).


Hmmm...  So, yes, we could do this.  In essence it is a plausible 
defence against node compromise, stopping backwards decryption from some 
point of compromise.  It doesn't stop forwards decryption, afaics.

We are presuming that the messages on the node aren't kept?  As a 
compromise on the node that can pick up a key can also likely pick up 
any stored messages.  So we are postulating that a compromise on the 
node is a snapshot which exfiltrates a single key in a short inexpensive 
operation.

It also requires the protocol to have a pretty good idea of message 
number, so it can calculate which hash position in the chain to use, in 
case messages arrive out of order.

Now, if you're going to do that -- hash the key forward and both sides 
then have a very good idea of each message sequence so the receiver can 
accurately decrypt based on position in hash chain -- could we also do 
something else?

Would it be plausible to simple negotiate a new ADH pair for each 
messsage sequence?

For some reason in my mind I can't shake the notion that this is like a 
block cipher in CTR mode, where the message sequence number is the 
counter, and if we know the full secrets, we can restart the suite at 
that point.


> The lockstep nature of OTR disappears:


( OTR, there's another unfortunate TLA that cries out for a new phrase 
to celebrate its successes not its failures.  c.f., the sad tale of Pvt. 
Manning is now very much on the record. )


> 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 
 h
ope 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!)


Right, you're assuming the sender is offline, "email batch" mode.  And 
can stack up the messages encrypted with a hash-chained key.

Now, if the protocol accepted say N forward hash positions, and could 
also reset to position P,Q ADH key, would it achieve the best of both 
worlds?

Where N is a sequence in Alice->Bob comms, and P is Alice->Bob and Q is 
Bob->Alice.


> 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.


Right, got it.  Our threat model is one of single state node compromise, 
such that long term private key can be exfiltrated, either/or short term 
session keys.

And our job is complete if this only compromises a few time-local 
messages, +/-.  Which then forces the attacker to abandon the attempt as 
it's not cost-effective.  The attacker must then go for total node 
compromise, which is a ratchet upwards in cost & risk.

I think it is valuable, but it is no panacea.  If we look at both the 
history of private sector attacks (server breaches) and intel sector 
attacks (thanks Ed & Jake) we see that there is a dominance of node 
attacks.  Hence, without an accompanying SnapChat like approach, it is 
pretty much worthless because the node attack is actually a lot more 
likely, and the goal that seems to be expressed is total node dominance, 
as that provides the flexibility for the attacker.

iang


More information about the cryptography mailing list