[147192] in cryptography@c2.net mail archive
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
daemon@ATHENA.MIT.EDU (John Kemp)
Tue Sep 17 16:55:31 2013
X-Original-To: cryptography@metzdowd.com
From: John Kemp <john@jkemp.net>
In-Reply-To: <CAMm+LwgOdeqem90YGqB8MEtxBBbYCQB1H4Zrn_pkOsXTiY24dw@mail.gmail.com>
Date: Tue, 17 Sep 2013 16:52:26 -0400
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
--===============1966395945853149241==
Content-Type: multipart/alternative; boundary="Apple-Mail=_6401A69B-26A4-4571-9A80-AFF985BC1438"
--Apple-Mail=_6401A69B-26A4-4571-9A80-AFF985BC1438
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker <hallam@gmail.com> =
wrote:
> My phrase PRISM-Proofing seems to have created some interest in the =
press.
>=20
> PRISM-Hardening might be more important, especially in the short term. =
The objective of PRISM-hardening is not to prevent an attack absolutely, =
it is to increase the work factor for the attacker attempting ubiquitous =
surveillance.
>=20
> Examples include:
>=20
> Forward Secrecy: Increases work factor from one public key per host to =
one public key per TLS session.
How does that work if one of PRISMs objectives is to compromise data =
_before_ it is transmitted by subverting its storage in one way or =
another?
Forward secrecy does nothing to impact the "work factor" in that case.
>=20
> Smart Cookies: Using cookies as authentication secrets and passing =
them as plaintext bearer tokens is stupid. It means that all an attacker =
needs to do is to compromise TLS once and they have the authentication =
secret. The HTTP Session-ID draft I proposed a while back reduces the =
window of compromise to the first attack.
>=20
>=20
> I am sure there are other ways to increase the work factor.=20
I think that "increasing the work factor" would often result in =
switching the kind of "work" performed to that which is easier than =
breaking secrets directly. That may be good. Or it may not. =
"PRISM-Hardening" seems like a blunt instrument, or at least one which =
may only be considered worthwhile in a particular context (technical =
protection) and which ignores the wider context (in which such technical =
protections alone are insufficient against this particular adversary). =20=
- johnk
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
--Apple-Mail=_6401A69B-26A4-4571-9A80-AFF985BC1438
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
charset=iso-8859-1
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Sep 17, 2013, at 2:43 PM, Phillip Hallam-Baker <<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">My phrase PRISM-Proofing seems to have created some interest in the press.<div><br></div><div>PRISM-Hardening might be more important, especially in the short term. The objective of PRISM-hardening is not to prevent an attack absolutely, it is to increase the work factor for the attacker attempting ubiquitous surveillance.</div>
<div><br></div><div>Examples include:</div><div><br></div><div>Forward Secrecy: Increases work factor from one public key per host to one public key per TLS session.</div></div></blockquote><div><br></div>How does that work if one of PRISMs objectives is to compromise data _before_ it is transmitted by subverting its storage in one way or another?</div><div><br></div><div>Forward secrecy does nothing to impact the "work factor" in that case.</div><div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>Smart Cookies: Using cookies as authentication secrets and passing them as plaintext bearer tokens is stupid. It means that all an attacker needs to do is to compromise TLS once and they have the authentication secret. The HTTP Session-ID draft I proposed a while back reduces the window of compromise to the first attack.</div>
<div><br></div><div><br></div><div>I am sure there are other ways to increase the work factor. </div></div></blockquote><div><br></div>I think that "increasing the work factor" would often result in switching the kind of "work" performed to that which is easier than breaking secrets directly. That may be good. Or it may not. "PRISM-Hardening" seems like a blunt instrument, or at least one which may only be considered worthwhile in a particular context (technical protection) and which ignores the wider context (in which such technical protections alone are insufficient against this particular adversary). </div><div><br></div><div>- johnk<br><blockquote type="cite"><div dir="ltr"><div><br></div><div><br clear="all"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
_______________________________________________<br>The cryptography mailing list<br><a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>http://www.metzdowd.com/mailman/listinfo/cryptography</blockquote></div><br></body></html>
--Apple-Mail=_6401A69B-26A4-4571-9A80-AFF985BC1438--
--===============1966395945853149241==
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
--===============1966395945853149241==--
