[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