[146779] in cryptography@c2.net mail archive
Re: [Cryptography] In the face of "cooperative" end-points,
daemon@ATHENA.MIT.EDU (james hughes)
Sat Sep 7 19:00:27 2013
X-Original-To: cryptography@metzdowd.com
From: james hughes <hughejp@mac.com>
In-reply-to: <522B9180.1020505@zen.co.uk>
Date: Sat, 07 Sep 2013 15:57:45 -0700
To: Peter Fairbrother <zenadsl6186@zen.co.uk>
Cc: cryptography@metzdowd.com, "Marcus D. Leech" <mleech@ripnet.com>,
james hughes <hughejp@mac.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1795241518099323882==
Content-type: multipart/alternative;
boundary="Apple-Mail=_54BB8AEB-9DDE-40E4-B507-584266CEBDE0"
--Apple-Mail=_54BB8AEB-9DDE-40E4-B507-584266CEBDE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Sep 7, 2013, at 1:50 PM, Peter Fairbrother <zenadsl6186@zen.co.uk> =
wrote:
> On 07/09/13 02:49, Marcus D. Leech wrote:
>> It seems to me that while PFS is an excellent back-stop against NSA
>> having/deriving a website RSA key, it does *nothing* to prevent the =
kind of
>> "cooperative endpoint" scenario that I've seen discussed in other
>> forums, prompted by the latest revelations about what NSA has been up =
to.
>=20
> True.
>=20
> But does it matter much? A cooperative endpoint can give plaintext no =
matter what encryption is used, not just session keys.
+1.=20
Cooperative endpoints offer no protection to any cryptography because =
they have all the plaintext. One can argue that the subpoenas are just =
as effective as cooperative endpoints. The reductio ad absurdum argument =
is that PFS is not good enough in the face of subpoenas? I don't think =
cooperative endpoints is a relevant point.=20
Passive monitoring and accumulation of cyphertext is a good SIGINT =
strategy. Read about the VENONA project.=20
http://en.wikipedia.org/wiki/Venona_project
> Most decipherable messages were transmitted and intercepted between =
1942 and 1945. [=85] These messages were slowly and gradually decrypted =
beginning in 1946 and continuing [=85] through 1980,
Clearly, the traffic was accumulated during which time there was no =
known attack.
While reusing OTP is not the fault here, PFS makes recovering =
information with future key recovery harder, since a single key being =
recovered with whatever means, does not make old traffic more =
vulnerable.=20
This is not a new idea. The separation of key exchange from =
authentication allows this. A router I did the cryptography for (first =
produced by Network Systems Corporation in the 1994) was very careful =
not to allow any old (i.e. recorded) traffic to be vulnerable even if =
one or both end points were stolen and all the key material extracted. =
The router used DH (both sides ephemeral) for the key exchange and RSA =
for authentication and integrity. This work actually predates IPSEC and =
is still being used.
=
http://www.blueridge.com/index.php/products/borderguard/borderguard-overvi=
ew
I am getting from the list that there have been or are arguments that =
doing two public key operations is too much. Is it really?=20
PFS may not be a panacea but does help.
--Apple-Mail=_54BB8AEB-9DDE-40E4-B507-584266CEBDE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" =
content=3D"text/html charset=3Dwindows-1252"></head><body =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Sep 7, 2013, =
at 1:50 PM, Peter Fairbrother <<a =
href=3D"mailto:zenadsl6186@zen.co.uk">zenadsl6186@zen.co.uk</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span style=3D"font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; display: inline !important; float: none; =
">On 07/09/13 02:49, Marcus D. Leech wrote:</span><br =
style=3D"font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
"><blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; ">It seems to me that while PFS is an =
excellent back-stop against NSA<br>having/deriving a website RSA key, it =
does *nothing* to prevent the kind of<br> "cooperative =
endpoint" scenario that I've seen discussed in other<br>forums, prompted =
by the latest revelations about what NSA has been up =
to.<br></blockquote><br style=3D"font-family: Helvetica; font-size: =
medium; font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: =
normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; "><span style=3D"font-family: Helvetica; =
font-size: medium; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: =
inline !important; float: none; ">True.</span><br style=3D"font-family: =
Helvetica; font-size: medium; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br =
style=3D"font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
"><span style=3D"font-family: Helvetica; font-size: medium; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; display: inline !important; float: none; =
">But does it matter much? A cooperative endpoint can give plaintext no =
matter what encryption is used, not just session keys.</span><br =
style=3D"font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
"></blockquote></div><br><div>+1. </div><div><br></div><div>Cooperati=
ve endpoints offer no protection to any cryptography because they have =
all the plaintext. One can argue that the subpoenas are just as =
effective as cooperative endpoints. The reductio ad absurdum =
argument is that PFS is not good enough in the face of subpoenas? I =
don't think cooperative endpoints is a relevant =
point. </div><div><br></div><div>Passive monitoring and =
accumulation of cyphertext is a good SIGINT strategy. Read about the =
VENONA project. </div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span><a =
href=3D"http://en.wikipedia.org/wiki/Venona_project">http://en.wikipedia.o=
rg/wiki/Venona_project</a></div><div></div><blockquote style=3D"margin: =
0 0 0 40px; border: none; padding: 0px;"><blockquote type=3D"cite">Most =
decipherable messages were transmitted and intercepted between 1942 and =
1945. [=85] These messages were slowly and =
gradually decrypted beginning in 1946 and continuing [=85] =
through 1980,</blockquote></blockquote><div>Clearly, the traffic was =
accumulated during which time there was no known =
attack.</div><div><br></div><div>While reusing OTP is not the fault =
here, PFS makes recovering information with future key recovery harder, =
since a single key being recovered with whatever means, does not make =
old traffic more vulnerable. </div><div><br></div><div>This is not =
a new idea. The separation of key exchange from authentication allows =
this. A router I did the cryptography for (first produced by Network =
Systems Corporation in the 1994) was very careful not to allow any old =
(i.e. recorded) traffic to be vulnerable even if one or both end points =
were stolen and all the key material extracted. The router used DH (both =
sides ephemeral) for the key exchange and RSA for authentication and =
integrity. This work actually predates IPSEC and is still being =
used.</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span><a =
href=3D"http://www.blueridge.com/index.php/products/borderguard/borderguar=
d-overview">http://www.blueridge.com/index.php/products/borderguard/border=
guard-overview</a></div><div><br></div><div>I am getting from the list =
that there have been or are arguments that doing two public key =
operations is too much. Is it really? </div><div><br></div><div>PFS =
may not be a panacea but does =
help.</div><div><br></div><div><br></div></body></html>=
--Apple-Mail=_54BB8AEB-9DDE-40E4-B507-584266CEBDE0--
--===============1795241518099323882==
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
--===============1795241518099323882==--
