[148816] in cryptography@c2.net mail archive
Re: [Cryptography] What is a secure conversation? (Was: online
daemon@ATHENA.MIT.EDU (Jon Callas)
Sat Dec 28 20:18:58 2013
X-Original-To: cryptography@metzdowd.com
From: Jon Callas <jon@callas.org>
In-Reply-To: <E6A1EB29-18EF-47DF-8D61-4D315084158C@lrw.com>
Date: Sat, 28 Dec 2013 17:00:27 -0800
To: Jerry Leichter <leichter@lrw.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Phillip Hallam-Baker <hallam@gmail.com>, Jon Callas <jon@callas.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4263745742875068923==
Content-Type: multipart/signed;
boundary="PGP_Universal_99E3C712_344DCFAB_96041314_D3AF3028";
protocol="application/pgp-signature";
micalg="pgp-sha1"
--PGP_Universal_99E3C712_344DCFAB_96041314_D3AF3028
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D7BA337-59ED-4677-99F1-B28FF2EEF7E5"
--Apple-Mail=_9D7BA337-59ED-4677-99F1-B28FF2EEF7E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Dec 28, 2013, at 1:16 PM, Jerry Leichter <leichter@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.
>=20
> 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.
>=20
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
--Apple-Mail=_9D7BA337-59ED-4677-99F1-B28FF2EEF7E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"><meta http-equiv=3D"Content-Type" content=3D"text/html=
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Dec 28, 2013, at 1:16 PM, Jerry =
Leichter <<a href=3D"mailto:leichter@lrw.com">leichter@lrw.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; "><div><div>On Dec 28, =
2013, at 11:49 AM, Phillip Hallam-Baker wrote:</div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><font =
class=3D"Apple-style-span">...</font>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....</div>
</div></blockquote>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.</div><div><br></div><div>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.</div><div><br></div></div></blockquote><br></div><div>For =
starters, we need to stop using the word =
"perfect."</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>"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."</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> =
</span>Jon</div><div><br></div></body></html>=
--Apple-Mail=_9D7BA337-59ED-4677-99F1-B28FF2EEF7E5--
--PGP_Universal_99E3C712_344DCFAB_96041314_D3AF3028
Content-Type: application/pgp-signature;
x-mac-type=70674453;
name=PGP.sig
Content-Disposition: attachment; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.2.0 (Build 1672)
iQA/AwUBUr90MbE3nVmTg94GEQJC4ACgqObq30DAM3QDFudWrtFF/7TdxEYAnAgr
9RIoeM7bV2IjWG4onWQDpx6s
=Q9CO
-----END PGP SIGNATURE-----
--PGP_Universal_99E3C712_344DCFAB_96041314_D3AF3028--
--===============4263745742875068923==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============4263745742875068923==--
