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

Jon Callas jon at callas.org
Sat Dec 28 20:00:27 EST 2013


On Dec 28, 2013, at 1:16 PM, Jerry Leichter <leichter at lrw.com> wrote:

> On Dec 28, 2013, at 11:49 AM, Phillip Hallam-Baker wrote:
>> ...At some point it is going to be easier to design one protocol that supports all the different messaging modes with security built in rather than working out how to back-fit security into each legacy protocol separately....
> 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.
> 
> This division bothers me.  It seems to me there's something missing in our descriptions so that we fail to capture the nature of this distinction.  It feels as if there should be a continuum here, where you get full PFS for communications with an arbitrarily short lifetime, degenerating into the usual more limited guarantees for things that are stored long term.  And I suppose you could come up with a simple theory along that line, where you need to retain keying material only as long as some message isn't delivered.  But this seems very forced and unnatural.  I think we're missing something.
> 

For starters, we need to stop using the word "perfect."

There are many, many sins created because of fetishism over "perfect." Look at all the people who try to figure out how to use one-time-pads, and end up with horrid systems because they were seduced by the word "perfect." Forward serecy is a Good Thing. But forward secrecy is a key management property, not a crypto property, and confusing key management with crypto is also the source of many errors. It's the same sort of problem as thinking about indistinguishability and then oopsing on ECB mode or nonce errors that I alluded to earlier today.

A long time ago, I was dazzled by a rant by Donn Parker. That particular rant was about the foolishness of "Best Practices" but really applies to any use of "best" or "perfect." A summary of his rant is that "best" is a comparative, not a standard. If you have three bad practices, the least bad is best, yet none of them are good. In contrast, if you have three good practices, trying to figure out which one is best is a waste of time. They're all good. Just pick one. His summary was that we should stop talking about best and talk about good.

"Perfect" has all the problems that "best" does -- and in fact, since "perfect" literally means that it cannot be improved on, it's merely a synonym for "best."

Forward secrecy is a good thing. If you're doing communications of any sort, it's relatively easy to get some degree of forward secrecy -- just throw the keys away -- and that's how all PFS protocols work. However, the more you focus on forward secrecy, the harder the authenticity problem is. There's less linkage between the messages, which is great if you assume a passive adversary. But if you assume an *active* adversary who might try to throw in a bogus message, then  linkage between messages has a different set of goodnesses. Independence of messages advantages the adversary.

If you look at a system like full disk encryption, the equivalent of forward secrecy is hard and harder the bigger your disk is because you get forward secrecy by re-encrypting the whole darned thing. But the key management is easy. If you build a per-file encryption system for storage, you get better forward secrecy, but a more complex key management system.

Many (most? all?) systems are ones where you have to pick your poison. Words like "best" and "perfect" shape thought into a certain set of reality-tunnels that imply and presuppose things that just aren't necessarily so.

	Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131228/a1123eea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131228/a1123eea/attachment.pgp>


More information about the cryptography mailing list