[146825] in cryptography@c2.net mail archive
Re: [Cryptography] In the face of "cooperative" end-points,
daemon@ATHENA.MIT.EDU (Marcus D. Leech)
Sun Sep 8 13:25:37 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 07 Sep 2013 23:16:22 -0400
From: "Marcus D. Leech" <mleech@ripnet.com>
To: cryptography@metzdowd.com
In-Reply-To: <090EAD00-E00C-48FE-B217-3E12CB042A56@mac.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============8802146158154934668==
Content-Type: multipart/alternative;
boundary="------------050003010603040104000307"
This is a multi-part message in MIME format.
--------------050003010603040104000307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 09/07/2013 06:57 PM, james hughes wrote:
>
> PFS may not be a panacea but does help.
>
There's no question in my mind that PFS helps. I have, in the past,
been very in much favor of turning on PFS support in various protocols,
when it has
been available. And I fully understand what the *purpose* of PFS is.
But it's not entirely clear to me that it will help enough in the
scenarios under discussion. If we assume that mostly what NSA are doing
is acquiring a site
RSA key (either through "donation" on the part of the site, or
through factoring or other means), then yes, absolutely, PFS will be a
significant roadblock.
If, however, they're getting session-key material (perhaps through
back-doored software, rather than explicit cooperation by the target
website), the
PFS does nothing to help us. And indeed, that same class of
compromised site could just as well be leaking plaintext. Although
leaking session
keys is lower-profile.
I think all this amounts to a preamble for a call to think deeply,
again, about end-to-end encryption. I used OTR on certain chat
sessions, for example,
because the consequences of the "server in the middle" disclosing the
contents of those conversations protected by OTR could have dire
consequences
for one of the parties involved.
Jeff Schiller pointed out a little while ago that the crypto-engineering
community have largely failed to make end-to-end encryption easy to
use. There are
reasons for that, some technical, some political, but it is
absolutely true that end-to-end encryption, for those cases where "end
to end" is the obvious
and natural model, has not significantly materialized on the
Internet. Relatively speaking, a handful of crypto-nerds use end-to-end
schemes for e-mail
and chat clients, and so on, but the vast majority of the Internet
user-space? Not so much.
--------------050003010603040104000307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/07/2013 06:57 PM, james hughes
wrote:<br>
</div>
<blockquote cite="mid:090EAD00-E00C-48FE-B217-3E12CB042A56@mac.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
<div>PFS may not be a panacea but does help.</div>
<div><br>
</div>
</blockquote>
There's no question in my mind that PFS helps. I have, in the past,
been very in much favor of turning on PFS support in various
protocols, when it has<br>
been available. And I fully understand what the *purpose* of PFS
is. <br>
<br>
But it's not entirely clear to me that it will help enough in the
scenarios under discussion. If we assume that mostly what NSA are
doing is acquiring a site<br>
RSA key (either through "donation" on the part of the site, or
through factoring or other means), then yes, absolutely, PFS will be
a significant roadblock.<br>
If, however, they're getting session-key material (perhaps
through back-doored software, rather than explicit cooperation by
the target website), the<br>
PFS does nothing to help us. And indeed, that same class of
compromised site could just as well be leaking plaintext. Although
leaking session<br>
keys is lower-profile.<br>
<br>
I think all this amounts to a preamble for a call to think deeply,
again, about end-to-end encryption. I used OTR on certain chat
sessions, for example,<br>
because the consequences of the "server in the middle" disclosing
the contents of those conversations protected by OTR could have dire
consequences<br>
for one of the parties involved.<br>
<br>
Jeff Schiller pointed out a little while ago that the
crypto-engineering community have largely failed to make end-to-end
encryption easy to use. There are<br>
reasons for that, some technical, some political, but it is
absolutely true that end-to-end encryption, for those cases where
"end to end" is the obvious<br>
and natural model, has not significantly materialized on the
Internet. Relatively speaking, a handful of crypto-nerds use
end-to-end schemes for e-mail<br>
and chat clients, and so on, but the vast majority of the Internet
user-space? Not so much.<br>
<br>
<br>
</body>
</html>
--------------050003010603040104000307--
--===============8802146158154934668==
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
--===============8802146158154934668==--
