[147134] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] Security is a total system problem (was Re:

daemon@ATHENA.MIT.EDU (Tony Arcieri)
Sat Sep 14 21:52:33 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130913152353.71e849ff@jabberwock.cb.piermont.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Sat, 14 Sep 2013 17:30:00 -0700
To: "Perry E. Metzger" <perry@piermont.com>
Cc: Eugen Leitl <eugen@leitl.org>, Crypto <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============3074806324066818368==
Content-Type: multipart/alternative; boundary=047d7b86f53255082e04e661314e

--047d7b86f53255082e04e661314e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 13, 2013 at 12:23 PM, Perry E. Metzger <perry@piermont.com>wrote:

> I strongly suspect that delivering them securely to the vast number
> of endpoints involved and then securing the endpoints as well would
> radically limit the usefulness. Note that it appears that even the
> NSA generally prefers to compromise endpoints rather than attack
> crypto.
>

Yes, even airgapping keys within an organization scales poorly (I say this
as an employee of a company that has built a high availability encryption
service around HSMs). While USB drives are certainly large enough to store
huge pads, the fact remains that OTP is only better than other systems if
we can keep the keys off the wire. This means that we need a sneakernet to
move keys around.

The payments industry in the US has done this somewhat successfully. They
do things like shipping fragments of the keys through different shipping
companies, having the recipient reassemble them at their end. Even then
it's difficult to know if they've been intercepted: you can encrypt them,
and put the drives in tamper evident bags, but at least the latter can be
thwarted.

Obviously the Public Key Infrastructure scales a lot better than this
approach.

-- 
Tony Arcieri

--047d7b86f53255082e04e661314e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Sep 13, 2013 at 12:23 PM, Perry E. Metzger <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:perry@piermont.com" target=3D"_blank" oncl=
ick=3D"window.open(&#39;https://mail.google.com/mail/?view=3Dcm&amp;tf=3D1&=
amp;to=3Dperry@piermont.com&amp;cc=3D&amp;bcc=3D&amp;su=3D&amp;body=3D&#39;=
,&#39;_blank&#39;);return false;">perry@piermont.com</a>&gt;</span> wrote:<=
br>


<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">I strongly suspect that delivering them securely to the vast numb=
er<br>



of endpoints involved and then securing the endpoints as well would<br>
radically limit the usefulness. Note that it appears that even the<br>
NSA generally prefers to compromise endpoints rather than attack<br>
crypto.<br></blockquote><div><br></div><div>Yes, even airgapping keys withi=
n an organization scales poorly (I say this as an employee of a company tha=
t has built a high availability encryption service around HSMs). While USB =
drives are certainly large enough to store huge pads, the fact remains that=
 OTP is only better than other systems if we can keep the keys off the wire=
. This means that we need a sneakernet to move keys around.</div>

<div><br></div><div>The payments industry in the US has done this somewhat =
successfully. They do things like shipping fragments of the keys through di=
fferent shipping companies, having the recipient reassemble them at their e=
nd. Even then it&#39;s difficult to know if they&#39;ve been intercepted: y=
ou can encrypt them, and put the drives in tamper evident bags, but at leas=
t the latter can be thwarted.</div>

<div><br></div><div>Obviously the Public Key Infrastructure scales a lot be=
tter than this approach.</div><div><br></div></div>-- <br>Tony Arcieri<br>
</div></div>

--047d7b86f53255082e04e661314e--

--===============3074806324066818368==
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
--===============3074806324066818368==--

home help back first fref pref prev next nref lref last post