[146851] in cryptography@c2.net mail archive
[Cryptography] Points of compromise
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sun Sep 8 15:37:48 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 8 Sep 2013 13:53:49 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1083276477370905292==
Content-Type: multipart/alternative; boundary=001a11c34b483d39a304e5e2f4b5
--001a11c34b483d39a304e5e2f4b5
Content-Type: text/plain; charset=ISO-8859-1
I was asked to provide a list of potential points of compromise by a
concerned party. I list the following so far as possible/likely:
1) Certificate Authorities
Traditionally the major concern (perhaps to the point of distraction from
other more serious ones). Main caveat, CA compromises leave permanent
visible traces as recent experience shows and there are many eyes looking.
Even if Google was compromised I can't believe Ben Laurie and Adam Langley
are proposing CT in bad faith.
2) Covert channel in Cryptographic accelerator hardware.
It is possible that cryptographic accelerators have covert channels leaking
the private key through TLS (packet alignment, field ordering, timing,
etc.) or in key generation (kleptography of the RSA modulus a la Motti
Young).
3) Cryptanalytic attack on one or more symmetric algorithms.
I can well believe that RC4 is bust and that there is enough RC4 activity
going on to make cryptanalysis worth while. The idea that AES is
compromised seems very less likely to me.
4) Protocol vulnerability introduced intentionally through IETF
I find this rather unlikely to be a direct action since there are few
places where the spec could be changed to advantage an attacker and only
the editors would have the control necessary to introduce text and there
are many eyes.
5) Protocol vulnerability that IETF might have fixed but was discouraged
from fixing.
Oh more times than I can count. And I would not discount the possibility
that there would be strategies based exploiting on the natural suspicion
surrounding security matters. It would have been easy for a faction to
derail DNSSEC by feeding the WG chair's existing hostility to CAs telling
him to stand firm.
One concern here is that this will fuel the attempt to bring IETF under
control of the ITU and Russia, China, etc.
--
Website: http://hallambaker.com/
--001a11c34b483d39a304e5e2f4b5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was asked to provide a list of potential points of compr=
omise by a concerned party. I list the following so far as possible/likely:=
<div><br></div><div><br></div><div>1) Certificate Authorities</div><div><br=
>
</div><div>Traditionally the major concern (perhaps to the point of distrac=
tion from other more serious ones). Main caveat, CA compromises leave perma=
nent visible traces as recent experience shows and there are many eyes look=
ing. Even if Google was compromised I can't believe Ben Laurie and Adam=
Langley are proposing CT in bad faith.</div>
<div><br></div><div><br></div><div>2) Covert channel in Cryptographic accel=
erator hardware.</div><div><br></div><div>It is possible that cryptographic=
accelerators have covert channels leaking the private key through TLS (pac=
ket alignment, field ordering, timing, etc.) or in key generation (kleptogr=
aphy of the RSA modulus a la Motti Young).=A0</div>
<div><br></div><div><br></div><div>3) Cryptanalytic attack on one or more s=
ymmetric algorithms.</div><div><br><div>I can well believe that RC4 is bust=
and that there is enough RC4 activity going on to make cryptanalysis worth=
while. The idea that AES is compromised seems very less likely to me.</div=
>
<div><br></div><div><br></div><div>4) Protocol vulnerability introduced int=
entionally through IETF</div><div><br></div><div>I find this rather unlikel=
y to be a direct action since there are few places where the spec could be =
changed to advantage an attacker and only the editors would have the contro=
l necessary to introduce text and there are many eyes.</div>
<div><br></div><div><br></div><div>5) Protocol vulnerability that IETF migh=
t have fixed but was discouraged from fixing.</div><div><br></div><div>Oh m=
ore times than I can count. And I would not discount the possibility that t=
here would be strategies based exploiting on the natural suspicion surround=
ing security matters. It would have been easy for a faction to derail DNSSE=
C by feeding the WG chair's existing hostility to CAs telling him to st=
and firm.</div>
<div><br clear=3D"all"><div><br></div><div>One concern here is that this wi=
ll fuel the attempt to bring IETF under control of the ITU and Russia, Chin=
a, etc.</div><div><br></div><div><br></div>-- <br>Website: <a href=3D"http:=
//hallambaker.com/">http://hallambaker.com/</a><br>
</div></div></div>
--001a11c34b483d39a304e5e2f4b5--
--===============1083276477370905292==
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
--===============1083276477370905292==--
