[148814] in cryptography@c2.net mail archive
Re: [Cryptography] What is a secure conversation? (Was: online
daemon@ATHENA.MIT.EDU (Natanael)
Sat Dec 28 16:55:38 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <E6A1EB29-18EF-47DF-8D61-4D315084158C@lrw.com>
Date: Sat, 28 Dec 2013 22:53:39 +0100
From: Natanael <natanael.l@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>,
Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1259641907028528291==
Content-Type: multipart/alternative; boundary=001a11c28aca4e61fe04ee9f3e1f
--001a11c28aca4e61fe04ee9f3e1f
Content-Type: text/plain; charset=UTF-8
Den 28 dec 2013 22:28 skrev "Jerry Leichter" <leichter@lrw.com>:
>
> 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
Moxie is trying to fix that, have you seen the "axolotl" ratcheting scheme
(not sure on the spelling) that he and another guy developed, with the
intent to establish PFS like security for asynchronous communication? I'd
say it's something more like a very long latency version of regular PFS.
The session keys becomes short term secrets instead.
--001a11c28aca4e61fe04ee9f3e1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Den 28 dec 2013 22:28 skrev "Jerry Leichter" <<=
a href=3D"mailto:leichter@lrw.com">leichter@lrw.com</a>>:<br>
><br>
> On Dec 28, 2013, at 11:49 AM, Phillip Hallam-Baker wrote:<br>
>><br>
>> ...At some point it is going to be easier to design one protocol t=
hat supports all the different messaging modes with security built in rathe=
r than working out how to back-fit security into each legacy protocol separ=
ately....<br>
><br>
> Except that there is a line at synchronous vs. asynchronous communicat=
ion that divides mechanisms with fundamentally different characteristics. =
=C2=A0Synchronous communication can have perfect forward security; asynchro=
nous communications cannot.<br>
><br>
> This division bothers me. =C2=A0It seems to me there's something m=
issing in our descriptions so that we fail to capture the nature of this di=
stinction. =C2=A0It feels as if there should be a continuum here, where you=
get full PFS for communications with an arbitrarily short lifetime, degene=
rating into the usual more limited guarantees for things that are stored lo=
ng term. =C2=A0And I suppose you could come up with a simple theory along t=
hat line, where you need to retain keying material only as long as some mes=
sage isn't delivered. =C2=A0But this seems very forced and unnatural. =
=C2=A0I think we're missing something.<br>
><br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Jerry</p>
<p dir=3D"ltr">Moxie is trying to fix that, have you seen the "axolotl=
" ratcheting scheme (not sure on the spelling) that he and another guy=
developed, with the intent to establish PFS like security for asynchronous=
communication? I'd say it's something more like a very long latenc=
y version of regular PFS. The session keys becomes short term secrets inste=
ad. <br>
</p>
--001a11c28aca4e61fe04ee9f3e1f--
--===============1259641907028528291==
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
--===============1259641907028528291==--
