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

[ianG]

On 29/12/13 04:00 AM, Jon Callas wrote:
>
> On Dec 28, 2013, at 1:16 PM, Jerry Leichter <leichter at lrw.com
> <mailto: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.

Seems to be:
Donn Parker,
"Making the Case for Replacing Risk-Based Security"
ISSA Journal, May 2006.

But I am unable to find a copy, anyone got a link to hand?

What I read of that article is that it is talking about (against) 
risk-based security rather than best practices.  Maybe I've got the 
wrong one?


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


Oh, it's worse than that.  Best practices as a concept only applies when 
you have a large group of people who need a 'practice'.  As you point 
out, the game mechanics of such is that the worse one typically survives 
because it is by definition the only one that everyone can implement, 
once they've decided they need consensus.

So best practices is actually a misnomer of perfect (!) proportions, it 
is by consensus the worst practices, or more politely, the least they 
can all agree on.  The race to the bottom.

But even worse is that even the very notion of people coming together to 
document their 'best practices' means that every participant is unsure 
what they are about.  They lack the confidence to say, "my practices are 
good enough, I don't need to achieve consensus."  They need the 
insurance policy of saying "we're doing what everyone else is doing, 
therefore we can't be wrong."

So, by the same game mechanics, best practices are those that are shared 
by people who aren't confident enough to do it.  It's turtles all the 
way down, from there.


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


Inconvenient changes to threats need not apply, we're perfect!

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


To be fair, this speaks right back to another problem that 'pure' 
cryptology has.  Without an understanding of the business model, there 
is no way to differentiate 'perfect' from any other standard.

Without that input of value, only 'perfect' withstands scrutiny.  My 
algorithm must be perfect -- squillion bit security over a lifetime of 
packets against a pentagon of crunching.

Sometimes this makes things easy -- such as block encryption algorithms 
and message digests.  Just as often or more often, the drive for 
perfection makes for a complete mess, like endless discussions about PK 
algorithm keylengths & params, overweight HMACs, key negotiations, who 
signs what, etc.  Perfect then becomes a millstone around our necks.



iang