If you thought RdRand caused a lot of chatter on this list, we've just
announced a new sister instruction.. RdSeed.
It's here.. http://software.intel.com/file/45207
RdSeed is SP800-90B C and X9.82 parts 2 4 compliant in the XOR
construction. But they're all draft specs so things could change.
On 2012-06-23 10:48 PM, ianG wrote: And, now it is possible to see a
case where even if we didn't need the
secrecy for administrative reasons, random number generation may want to
keep the seed input to the DRBG secret.
If we had the raw unwhitened semi random data, an attacker could
On 06/21/2012 09:05 PM, ianG wrote:
On 22/06/12 06:53 AM, Michael Nelson wrote:
At the output of the DRBG, through RdRand, you have no visibility
of these processes. We seek to limit the side channels through
which an attacker could determine the internal state of the DRNG.
Good answer!
Marsh,
Am I missing something?
On Fri, Jun 22, 2012 at 1:06 PM, Marsh Ray ma...@extendedsubset.com wrote:
On 06/21/2012 09:05 PM, ianG wrote:
On 22/06/12 06:53 AM, Michael Nelson wrote:
[snip]
It's a natural human question to ask. I want to see what's under the
hood. But it seems there is
On 2012-06-20 5:22 AM, Matthew Green wrote:
If you assume that every manufactured device will meet the standards of Intel's
test units, then you can live with the CRI/Intel review.
If you're /not/ confident in that assumption, the ability to access raw ES
output would be useful...
I see no
James A. Donald wrote:
I see no valid case for on chip whitening. Whitening looks like a classic
job for
software. Why
waste chip real estate on something that will only be used
On that Intel forum site someone pointed to, one of the Intel guys said with
respect to the whitening and
James A. Donald wrote:
I see no valid case for on chip whitening. Whitening
looks like a classic job for software. Why waste chip
real estate on something that will only be used 0.001% of
the time.
On 2012-06-22 6:53 AM, Michael Nelson wrote:
I suppose that if the rng was shared between
James A. Donald wrote:
James A. Donald wrote:
I see no valid case for on chip whitening. Whitening
looks like a classic job for software. Why waste chip
real estate on something that will only be used 0.001% of
the time.
On 2012-06-22 6:53 AM, Michael Nelson wrote:
I suppose that
Aloha!
On 2012-06-20 05:32 , James A. Donald wrote:
If intel told me how it worked, and provided low level access to raw
unwhitened output, I could find pretty good evidence that the low level
randomness generator was working as described, and perfect evidence that
the whitener was working as
On Jun 18, 2012, at 9:03 PM, Matthew Green wrote:
On Jun 18, 2012, at 4:21 PM, Jon Callas wrote:
Reviewers don't want a review published that shows they gave a pass on a
crap system. Producing a crap product hurts business more than any thing in
the world. Reviews are products. If a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 18, 2012, at 4:12 PM, Marsh Ray wrote:
150 clocks (Intel's figure) implies 18.75 clocks per byte.
That's not bad at all. It's in the neighborhood of what I remember my DRBG
running at with AES-NI. Faster, but not by a lot. However, I
And, to get back on topic after having gone dangerously off topic:
The market for cryptography is the market for silver bullets: Those
actually paying money cannot tell the difference between real experts
and salesmen, thus the incentive to actually be any good at this is not
high.
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote:
...
Right, 500 MB/s of random numbers out to be enough for anybody.
these rates often are not useful. even busy secure web or VPN servers
use orders of magnitude less.
initialization of full disk crypto across an SSD
coderman coder...@gmail.com writes:
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote:
...
Right, 500 MB/s of random numbers out to be enough for anybody.
these rates often are not useful. even busy secure web or VPN servers use
orders of magnitude less.
initialization
Aloha!
On 2012-06-19 11:30 , coderman wrote:
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com wrote:
So something is causing AES-NI to take 300 clocks/block to run this DRBG.
Again, more than 3x slower than the benchmarks I see for the hardware
primitive. My interpretation
On Mon, Jun 18, 2012 at 09:58:59PM -0700, coderman wrote:
this is very useful to have in some configurations (not just testing).
for example: a user space entropy daemon consuming raw, biased,
un-whitened, full throughput bits of lower entropy density which is
run through sanity checks,
Hi!
The interesting discussion induced me to look again to the actual report
[1]. When I initially did, I came up with the impression that the RNG
design is sound to the extent that a) any system based on sampling an
unpredictable physical phenomenon has some intrinsic limitations, and b)
Aloha!
On 2012-06-19 11:30 , coderman wrote:
On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray ma...@extendedsubset.com
wrote:
So something is causing AES-NI to take 300 clocks/block to run this
DRBG.
Again, more than 3x slower than the benchmarks I see for the hardware
primitive. My
On Tue, Jun 19, 2012 at 9:02 AM, d...@deadhat.com wrote:
...
It is not using AES-NI. It is a self contained unit on chip with a built
in HW AES encrypt block cipher.
thanks for the clarification; is this documented somewhere? i am
curious if the die space consumed for two implementations of
On 06/19/2012 01:59 PM, coderman wrote:
thanks for the clarification; is this documented somewhere? i am
curious if the die space consumed for two implementations of AES in
negligable on these very large cores, or if there is another reason to
intentionally keep them separate.
It sounds to me
On Tue, Jun 19, 2012 at 6:17 AM, Thor Lancelot Simon t...@panix.com wrote:
...
Sanity checks, entropy estimates, and other vetting *which the output
of a DRBG keyed in a known way by your adversary will pass without
a hint of trouble*.
absolutely; after it has gone through DRBG you have zero
i'll concede the point that you'd only want raw bits to validate CRI
and Intel assurances, and they've done due diligence.
this is something i like to verify myself; no fault with the Intel
design or CRI analysis implied.
If you assume that every manufactured device will meet the standards
I would really love to hear some examples from the security world.
The canonical example I was thinking of was Arthur Anderson, which
doesn't meet your definition, I'm sure.
I would not wait for such clarity; the bond rating agencies still
live while the sovereigns they rated are busily
On 06/19/2012 02:11 PM, coderman wrote:
the sanity checks, being on die, are limited. you can't run DIEHARD
against this in a useful manner because the DRBG obscures anything
useful.
I don't think there's anything useful diehard (specifically) is going to
tell you.
The raw entropy source
On 2012-06-19 4:51 AM, Matthew Green wrote:
1. Private evaluation report (budgeted to, say, 200 hours)
probabilistically identifies N serious vulnerabilities. We
all know that another 200 hours could turn up N more. In
fact, the code may be riddled with errors. Original N
vulnerabilities are
On 06/19/2012 02:11 PM, coderman wrote:
the sanity checks, being on die, are limited. you can't run DIEHARD
against this in a useful manner because the DRBG obscures anything
useful.
I don't think there's anything useful diehard (specifically) is going to
tell you.
The raw entropy source
On Tue, Jun 19, 2012 at 07:35:03PM -0700, coderman wrote:
is there any literature on the typical failure modes of TRNG/entropy
sources in deployed systems?
my understanding is that they tend to fail catastrophically, in a way
easily detected by FIPS sanity checks. E.g. clearly broken.
I
On 2012-06-19 7:02 AM, Jack Lloyd wrote:
You're
not saying that CRI would hide things, you're just saying that
accepting payment sets the incentives all the wrong way and that all
companies would put out shoddy work so long as they got paid,
especially if giving a bad review would make the
On 2012-06-19 9:07 AM, d...@deadhat.com wrote:
It does tell you that if it is your chip and you don't let
someone else pull the lid off, scrape off the passivation and apply a pico
probe to it, it will certainly provide you with good random numbers
regardless of the FIPS mode.
I don't know
On 20/06/12 13:25 PM, James A. Donald wrote:
On 2012-06-19 7:02 AM, Jack Lloyd wrote:
You're
not saying that CRI would hide things, you're just saying that
accepting payment sets the incentives all the wrong way and that all
companies would put out shoddy work so long as they got paid,
On 6/19/2012 7:35 PM, coderman wrote:
On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray ma...@extendedsubset.com wrote:
... Just a sanity check that the output is
actually changing once in a while would go a long way towards
eliminating the most common failure modes.
On Tue, Jun 19, 2012 at 6:58 PM,
On Tue, Jun 19, 2012 at 2:30 AM, coderman coder...@gmail.com wrote:
...
as for stating that it should never run dry, or fail to not return
bits as long as the instruction is working...
i was incorrect; developers should expect this instruction to
infrequently encounter transitory failures
.
-Original Message-
From: cryptography-boun...@randombit.net
[mailto:cryptography-boun...@randombit.net] On Behalf Of Francois Grieu
Sent: Monday, June 18, 2012 11:04 AM
To: cryptography@randombit.net
Subject: Re: [cryptography] Intel RNG
d...@deadhat.com wrote:
CRI has published
for Common Criteria certification of your
product.
-Original Message-
From: cryptography-boun...@randombit.net
[mailto:cryptography-boun...@randombit.net] On Behalf Of Francois Grieu
Sent: Monday, June 18, 2012 11:04 AM
To: cryptography@randombit.net
Subject: Re: [cryptography] Intel RNG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 18, 2012, at 5:26 AM, Matthew Green wrote:
The fact that something occurs routinely doesn't actually make it a good
idea. I've seen stuff in FIPS 140 evaluations that makes my skin crawl.
This is CRI, so I'm fairly confident nobody is
On Mon, Jun 18, 2012 at 10:20:35AM -0700, Jon Callas wrote:
On Jun 18, 2012, at 5:26 AM, Matthew Green wrote:
The fact that something occurs routinely doesn't actually make it a good
idea. I've seen stuff in FIPS 140 evaluations that makes my skin crawl.
This is CRI, so I'm fairly
On Mon, Jun 18, 2012 at 2:51 PM, Matthew Green matthewdgr...@gmail.comwrote:
I think that Jack said most of what I would. The incentives all point in
the wrong direction.
While this is all true, it's also why manufacturers who want persuasive
analysis of their products hire consulting vendors
Indeed. We're confident that the DRNG design is sound, but asking the
world to trust us, it's a sound design is unreasonable without us
letting someone independently review it. So being a cryptographic design
that people need some reason to trust before they use it, we opened the
design to a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 18, 2012, at 11:15 AM, Jack Lloyd wrote:
On Mon, Jun 18, 2012 at 10:20:35AM -0700, Jon Callas wrote:
On Jun 18, 2012, at 5:26 AM, Matthew Green wrote:
The fact that something occurs routinely doesn't actually make it a good
idea. I've
There's no [non-trivial] system in the world with zero bugs [for some value of
trivial]
:)
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
On Mon, Jun 18, 2012 at 01:21:20PM -0700, Jon Callas wrote:
I am not in any way suggesting that CRI would hide weaknesses or
perform a lame review.
But that is *precisely* what you are saying.
Jon Stewart could parody that argument far better than I can. You're
not saying that CRI would
On Mon, Jun 18, 2012 at 11:58:56AM -0700, Kyle Hamilton wrote:
So what can we do to solve it? Create our own reputable review service?
Who would pay for it? Who could pay for it? Who *should* pay for it?
At first it seems like irony that buyer-pays is likely the process
best aligned with
What they're actually saying is that they don't think that FIPSing the RNG
will materially impact the security of the RNG -- which if you think
about it, is pretty faint praise.
But true. The FIPS mode enforces some boundary controls (external config
and debug inputs are disabled) but the
On 06/18/2012 12:20 PM, Jon Callas wrote:
A company makes a cryptographic widget that is inherently hard to
test or validate. They hire a respected outside firm to do a review.
What's wrong with that? I recommend that everyone do that.
Un-reviewed crypto is a bane.
Let's accept that the
On Mon, Jun 18, 2012 at 7:12 PM, Marsh Ray ma...@extendedsubset.com wrote:
On 06/18/2012 12:20 PM, Jon Callas wrote:
A company makes a cryptographic widget that is inherently hard to
test or validate. They hire a respected outside firm to do a review.
What's wrong with that? I recommend that
On 19/06/12 08:49 AM, Jack Lloyd wrote:
I've never heard about someone trying to talk past, say, an AES
implementation that didn't actually work, or a bad RSA, that's a
pretty bright line.
I had a bit of an epiphany in two parts.
The first part is that AES and block algorithms can be quite
Tim Dierks t...@dierks.org writes:
While this is all true, it's also why manufacturers who want persuasive
analysis of their products hire consulting vendors with a brand and track
record strong enough that the end consumer can plausibly believe that their
reputational risk outweighs the
On Jun 18, 2012, at 11:21 52PM, ianG wrote:
Then there are RNGs. They start from a theoretical absurdity that we cannot
predict their output, which leads to an apparent impossibility of
black-boxing.
NIST recently switched gears and decided to push the case for deterministic
PRNGs.
On Jun 18, 2012, at 4:21 PM, Jon Callas wrote:
Reviewers don't want a review published that shows they gave a pass on a crap
system. Producing a crap product hurts business more than any thing in the
world. Reviews are products. If a professional organization gives a pass on
something that
On 06/18/2012 10:21 PM, ianG wrote:
The first part is that AES and block algorithms can be quite tightly
defined with a tight specification, and we can distribute test
parameters. Anyone who's ever coded these things up knows that the test
parameters do a near-perfect job in locking
On Mon, Jun 18, 2012 at 9:46 PM, Marsh Ray ma...@extendedsubset.com wrote:
...
One thing they could do is provide a mechainsm to access raw samples from
the Entropy Source component. I.e., the data that Intel provided [to
Cryptography Research] from pre-production chips. These chips allow
CRI has published an independent review of the RNG behind the RdRand
instruction:
http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
Intel has published more details of the new rdrand instruction and the
random number generator behind it.
In case this is useful to anyone, here's the Windows code to use rdrand, to
complement the gcc version for Unix systems. It'll also be present in the
next release of the cryptlib RNG code, available under a GPL, LGPL, or BSD
license, depending on which you prefer.
#if defined( _MSC_VER )
PG == Peter Gutmann pgut...@cs.auckland.ac.nz writes:
PG Does this mean it's unavailable in 32-bit mode?
Unlikely; see below.
PG What does the notation 0F C7 /6 indicate in terms of encoding? It
PG looks like RdRand r16 and r32 have the same encoding, or do you
PG encode (for example) r16 vs.
JL == Jack Lloyd ll...@randombit.net writes:
JL It's also supported in (very very recent) GNU binutils.
The sample code Intel provided on that page compiled/assembled
correctly here, using binutils-2.21.
Noting again that the registers are ordered ax, cx, dx, bx, sp,
bp, si, di, then the
Intel has published more details of the new rdrand instruction and the
random number generator behind it.
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
http://software.intel.com/file/36945
56 matches
Mail list logo
