[148812] in cryptography@c2.net mail archive
Re: [Cryptography] What is a secure conversation? (Was: online
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Sat Dec 28 16:28:05 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAMm+LwizUptasSyhx0jpfLxQ6-qDtvB3OZrpz6bt+G=nMk5_7g@mail.gmail.com>
Date: Sat, 28 Dec 2013 16:16:38 -0500
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2664204282331885709==
Content-Type: multipart/alternative; boundary="Apple-Mail=_03C163E7-7601-4D53-8469-6385723A5EE1"
--Apple-Mail=_03C163E7-7601-4D53-8469-6385723A5EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
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.
-- Jerry
--Apple-Mail=_03C163E7-7601-4D53-8469-6385723A5EE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head></head><body 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" =
color=3D"#000000">...</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><div> =
=
=
-- =
Jerry</div><div><br></div></div></body></html>=
--Apple-Mail=_03C163E7-7601-4D53-8469-6385723A5EE1--
--===============2664204282331885709==
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
--===============2664204282331885709==--
