[148044] in cryptography@c2.net mail archive
Re: [Cryptography] What's a Plausible Attack On Random Number
daemon@ATHENA.MIT.EDU (David Mercer)
Wed Nov 6 00:18:24 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20131104233241.14C6DE0A0@a-pb-sasl-quonix.pobox.com>
Date: Wed, 6 Nov 2013 12:00:18 +0800
From: David Mercer <radix42@gmail.com>
To: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8529840401012091632==
Content-Type: multipart/alternative; boundary=047d7b6250a4f7e62204ea7a2fd6
--047d7b6250a4f7e62204ea7a2fd6
Content-Type: text/plain; charset=UTF-8
On Sat, Nov 2, 2013 at 2:33 PM, Bill Stewart <bill.stewart@pobox.com> wrote:
> At 07:21 AM 11/1/2013, Jerry Leichter wrote:
>
>> On Nov 1, 2013, at 7:04 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>> > It sounds like a quick addition to DHCP - an extension that gets you
>> 256 bits from the server, would solve 99% of the problem we have with
>> embedded devices. It will not be sufficient for high-security environments,
>> because an attacker might be listening on the local LAN....
>> Ahem. This is *exactly* the kind of reasoning I started this thread to
>> investigate. (Though I certainly agree that a *single* DHCP packet
>> containing a random bit string is easily attacked.)
>>
>
> It's slightly backwards as far as timing goes - if you're trying to run a
> pure client, you normally have physical input from the user and access to a
> sound card before running anything that needs to generate encryption keys,
> so you don't really need it, and if you're running a server, you almost
> always want a fixed IP address rather than a random one from the DHCP pool,
> so you're probably not going to ask for DHCP. Also, if you're starting a
> brand-new-out-of-the-box server, it doesn't matter if it takes a few
> minutes before there's enough entropy to generate keys, because it's new,
> while the case where you care most about startup time is restarting a
> previously running server that was shut down, so you would have saved a
> seed by then. I guess that Cloud World may have occasion to care about how
> long it takes to provision a brand-new server from a canned image, and need
> to generate an ssh key so a user can log in to update the rest of their
> software, because they're paying by the millisecond, but are they likely to
> use DHCP as opposed to having Chef/Puppet give them an address?
Actually, in most of CloudWorld, as you put it, DHCP is used for servers
with fixed IP addresses. The provisioning system knows the "hardware" MAC
address, and plops the private IP into the DHCP config. Amazon AWS does
this, as do most other large cloud or VM hosts. It is hand installed VM's
that will not use DHCP for static IP address allocation, and in that case
you have keyboard and mouse events.
-David Mercer
--047d7b6250a4f7e62204ea7a2fd6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Nov 2, 2013 at 2:33 PM, Bill Stewart <span dir=3D"ltr"><<a href=
=3D"mailto:bill.stewart@pobox.com" target=3D"_blank">bill.stewart@pobox.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">At 0=
7:21 AM 11/1/2013, Jerry Leichter wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Nov 1, 2013, at 7:04 AM, Yaron Sheffer <<a href=3D"mailto:yaronf.ietf=
@gmail.com" target=3D"_blank">yaronf.ietf@gmail.com</a>> wrote:<br>
> It sounds like a quick addition to DHCP - an extension that gets you 2=
56 bits from the server, would solve 99% of the problem we have with embedd=
ed devices. It will not be sufficient for high-security environments, becau=
se an attacker might be listening on the local LAN....<br>
Ahem. =C2=A0This is *exactly* the kind of reasoning I started this thread t=
o investigate. =C2=A0(Though I certainly agree that a *single* DHCP packet =
containing a random bit string is easily attacked.)<br>
</blockquote>
<br></div></div>
It's slightly backwards as far as timing goes - if you're trying to=
run a pure client, you normally have physical input from the user and acce=
ss to a sound card before running anything that needs to generate encryptio=
n keys, so you don't really need it, and if you're running a server=
, you almost always want a fixed IP address rather than a random one from t=
he DHCP pool, so you're probably not going to ask for DHCP. =C2=A0Also,=
if you're starting a brand-new-out-of-the-box server, it doesn't m=
atter if it takes a few minutes before there's enough entropy to genera=
te keys, because it's new, while the case where you care most about sta=
rtup time is restarting a previously running server that was shut down, so =
you would have saved a seed by then. =C2=A0I guess that Cloud World may hav=
e occasion to care about how long it takes to provision a brand-new server =
from a canned image, and need to generate an ssh key so a user can log in t=
o update the rest of their software, because they're paying by the mill=
isecond, but are they likely to use DHCP as opposed to having Chef/Puppet g=
ive them an address?</blockquote>
<div><br></div><div>Actually, in most of CloudWorld, as you put it, DHCP is=
used for servers with fixed IP addresses. =C2=A0The provisioning system kn=
ows the "hardware" MAC address, and plops the private IP into the=
DHCP config. =C2=A0Amazon AWS does this, as do most other large cloud or V=
M hosts. =C2=A0It is hand installed VM's that will not use DHCP for sta=
tic IP address allocation, and in that case you have keyboard and mouse eve=
nts.<br>
<br><br>-David Mercer</div><div><br></div></div></div></div>
--047d7b6250a4f7e62204ea7a2fd6--
--===============8529840401012091632==
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
--===============8529840401012091632==--
