[147887] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] /dev/random initialisation
daemon@ATHENA.MIT.EDU (John Kelsey)
Wed Oct 30 00:01:33 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <a01b5c23966a3ea68eeaf97e6dd75d05.squirrel@www.deadhat.com>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Tue, 29 Oct 2013 23:59:53 -0400
To: "dj@deadhat.com" <dj@deadhat.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3347372029853513959==
Content-Type: multipart/alternative;
boundary=Apple-Mail-16C7C3AE-3736-483F-A8F7-227873E04A1B
Content-Transfer-Encoding: 7bit
--Apple-Mail-16C7C3AE-3736-483F-A8F7-227873E04A1B
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Oct 28, 2013, at 5:28 PM, dj@deadhat.com wrote:
...
> But the specifications (SP800-90x & FIPS 140-2) make it spectacularly hard=
> to mix in multiple sources in a compliant way. SP800-90 gives a way to mix=
> in "additional entropy" and "personalization strings", but FIPS 140-2
> states that all sources must be authenticated. All configuring entities
> must be authenticated. Try authenticating hardware on one end of chip
> against hardware at the other end of the chip. It is the mother of all
> chicken and egg problems.
Wait, the FIPS labs refuse to let you put your own stuff into those addition=
al inputs? That's the whole *point* of having them in the DRBGs. If you ca=
ll generate with an additional input that is not guessable to the attacker, s=
tarting with a DRBG state the attacker knows, the DRBG is put into an ungues=
sable-to-the-attacker state before the output bits are generated. =20
> The 'per instance' nature of the additional entropy data provided during
> the SP800-90A instantiation algorithm is entirely incompatible with
> hardware implementations that have fixed state.
\
> The solution is to not use or permit any of these extraneous inputs and
> don't permit instantiation other than at reset time, then you don't need
> to go about 'authenticating' the caller, whatever that means in the
> context of one circuit on a chip talking to another circuit on a chip.
> Just so you can take it in for FIPS certification.
> SP800-90A defines a reseed as a callable function and defines the caller
> as being the thing that provides the fresh entropy. FIPS 40-2 requires
> that the caller be authenticated. That's what I call a mess.
One thing that's probably causing some confusion somewhere is that 800-90A r=
eally just specifies deterministic algorithms. 90B (which is still being wo=
rked on) specifies entropy sources, and 90C (also still being worked on) spe=
cifies how to combine the two kinds of components to get a working random bi=
t generator. I gather the FIPS guys are trying to impose some kinds of requ=
irements while they wait for these to be done. But there is no way it makes=
sense to restrict the DRBG additional inputs to only coming from an authent=
icated on-device location. =20
> If NIST want people to make compliant paranoia RNGs, that accept all
> sources, authenticated or not, and mix them, then that is what the specs
> should say, but they do not. All sources have to have been designed in
> ahead of time. All entities it interacts with have to have been
> provisioned with authentication credentials.
> So the 'mix everything in' RNGs give one model of security (Only 1 of N
> sources need be good). The NIST RNGs give another (We designed the one
> true source to be good). But there is no overlap. One cannot be both a
> NISTesque RNG and a 'mix everything in' RNG.
Our goal is to have a trusted entropy source in there somewhere, since other=
wise you can't really know you are starting up into a secure state. But the=
re should not be any restrictions on where the additional inputs can come fr=
om. =20
There's also an idea of combining entropy sources, which we're working on in=
90C, but I don't think it made it into the current out-for-comment draft. =20=
> I have heard this complaint from multiple people on multiple projects -
> paraphrasing: "We had to make our RNG less secure to get it through FIPS -=
> We had to take out the additional mix in sources".
All three 800-90 documents are out for public comment right now. If you wan=
t to make sure it's included in the official comments (which we will definit=
ely be going through and addressing), email exactly what you did here to RBG=
_Comments@nist.gov
More broadly to everyone: If you see problems with how the FIPS validation p=
rocess plays with the DRBGs, or other problems, email a formal comment in. =20=
--John=
--Apple-Mail-16C7C3AE-3736-483F-A8F7-227873E04A1B
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>On Oct 28, 2013, at 5:28 PM, <a href=3D=
"mailto:dj@deadhat.com">dj@deadhat.com</a> wrote:</div><div><br></div><div>.=
..</div><blockquote type=3D"cite"><div><span>But the specifications (SP800-9=
0x & FIPS 140-2) make it spectacularly hard</span><br><span>to mix in mu=
ltiple sources in a compliant way. SP800-90 gives a way to mix</span><br><sp=
an>in "additional entropy" and "personalization strings", but FIPS 140-2</sp=
an><br><span>states that all sources must be authenticated. All configuring e=
ntities</span><br><span>must be authenticated. Try authenticating hardware o=
n one end of chip</span><br><span>against hardware at the other end of the c=
hip. It is the mother of all</span><br><span>chicken and egg problems.</span=
><br></div></blockquote><div><br></div><div>Wait, the FIPS labs refuse to le=
t you put your own stuff into those additional inputs? That's the whol=
e *point* of having them in the DRBGs. If you call generate with an ad=
ditional input that is not guessable to the attacker, starting with a DRBG s=
tate the attacker knows, the DRBG is put into an unguessable-to-the-attacker=
state before the output bits are generated. </div><div><br></div><blo=
ckquote type=3D"cite"><div><span>The 'per instance' nature of the additional=
entropy data provided during</span><br><span>the SP800-90A instantiation al=
gorithm is entirely incompatible with</span><br><span>hardware implementatio=
ns that have fixed state.</span><br></div></blockquote><div>\</div><blockquo=
te type=3D"cite"><div><span>The solution is to not use or permit any of thes=
e extraneous inputs and</span><br><span>don't permit instantiation other tha=
n at reset time, then you don't need</span><br><span>to go about 'authentica=
ting' the caller, whatever that means in the</span><br><span>context of one c=
ircuit on a chip talking to another circuit on a chip.</span><br><span>Just s=
o you can take it in for FIPS certification.</span><br></div></blockquote><b=
r><blockquote type=3D"cite"><div><span>SP800-90A defines a reseed as a calla=
ble function and defines the caller</span><br><span>as being the thing that p=
rovides the fresh entropy. FIPS 40-2 requires</span><br><span>that the calle=
r be authenticated. That's what I call a mess.</span><br></div></blockquote>=
<div><br></div><div>One thing that's probably causing some confusion somewhe=
re is that 800-90A really just specifies deterministic algorithms. 90B=
(which is still being worked on) specifies entropy sources, and 90C (also s=
till being worked on) specifies how to combine the two kinds of components t=
o get a working random bit generator. I gather the FIPS guys are tryin=
g to impose some kinds of requirements while they wait for these to be done.=
But there is no way it makes sense to restrict the DRBG additional in=
puts to only coming from an authenticated on-device location. </div><b=
r><blockquote type=3D"cite"><div><span>If NIST want people to make compliant=
paranoia RNGs, that accept all</span><br><span>sources, authenticated or no=
t, and mix them, then that is what the specs</span><br><span>should say, but=
they do not. All sources have to have been designed in</span><br><span>ahea=
d of time. All entities it interacts with have to have been</span><br><span>=
provisioned with authentication credentials.</span><br></div></blockquote><b=
r><blockquote type=3D"cite"><div><span>So the 'mix everything in' RNGs give o=
ne model of security (Only 1 of N</span><br><span>sources need be good). The=
NIST RNGs give another (We designed the one</span><br><span>true source to b=
e good). But there is no overlap. One cannot be both a</span><br><span>NISTe=
sque RNG and a 'mix everything in' RNG.</span></div></blockquote><div><br></=
div><div>Our goal is to have a trusted entropy source in there somewhere, si=
nce otherwise you can't really know you are starting up into a secure state.=
But there should not be any restrictions on where the additional inpu=
ts can come from. </div><div><br></div><div>There's also an idea of co=
mbining entropy sources, which we're working on in 90C, but I don't think it=
made it into the current out-for-comment draft. </div><br><blockquote=
type=3D"cite"><div><span>I have heard this complaint from multiple people o=
n multiple projects -</span><br><span>paraphrasing: "We had to make our RNG l=
ess secure to get it through FIPS -</span><br><span>We had to take out the a=
dditional mix in sources".</span><br></div></blockquote><div><br></div><div>=
All three 800-90 documents are out for public comment right now. If yo=
u want to make sure it's included in the official comments (which we will de=
finitely be going through and addressing), email exactly what you did here t=
o <a href=3D"mailto:RBG_Comments@nist.gov">RBG_Comments@nist.gov</a></d=
iv><div><br></div><div>More broadly to everyone: If you see problems with ho=
w the FIPS validation process plays with the DRBGs, or other problems, email=
a formal comment in. </div><div><br></div><div>--John</div></body></h=
tml>=
--Apple-Mail-16C7C3AE-3736-483F-A8F7-227873E04A1B--
--===============3347372029853513959==
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
--===============3347372029853513959==--
