So, the underlying issue is not a poor design choice in OpenSSL, but
poor seeding in some applications.
That's why we're putting it on-chip and in the instruction set from Ivy
Bridge onwards. http://en.wikipedia.org/wiki/RdRand
___
cryptography
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.
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
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
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 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
http://eprint.iacr.org/2013/338.pdf
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Am Freitag, 29. November 2013, 19:05:00 schrieb coderman:
Hi coderman,
On Fri, Nov 29, 2013 at 4:54 PM, coderman coder...@gmail.com wrote:
...
0. extract_buf() - 'If we have a architectural hardware random number
generator [ED.: but only RDRAND], mix that in, too.'
the work that you have done to make hardware entropy sources readily
available in Intel chips should be commended, and i certainly
appreciate it. i will however continue to complain until it is even
better, with configurable access to the raw entropy samples for those
who wish to evaluate
Management Systems
(CKMS)
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-152
Released 7 Jan 2014, comments due by March 5, 2014
I will probably be there causing trouble.
DJ
___
cryptography mailing list
cryptography@randombit.net
SP 800-152
Don't forget to look at SP 800-130 in parallel.
Overall, an endless list of requirements that may be useful as a barrier
to entry in the US Federal Government IT security market.
That's why I'm going. To try and trim the obstructive requirements. If
we're building on-chip key
or get out your soldering
iron. Bill Cox has been discussing his interesting design for such a thing
right here.
DJ
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Rather than me listing names, why not just let it rip and run your own
randomness tests on it?
Because that won't tell me if you are performing entropy extraction.
Jytter assumes an x86 machine with multiple asynchronous clocks and
nondeterministic physical devices. This is not a safe
OK, if you think my Jytter TRNG is weak,
I did not say it was weak. I said Jytter (and any other algorithm) is
deterministic when run on an entropy free platform. This is a simple fact.
By all meas design new and interesting ways to extract platform entropy,
but condition your claims on that
On Tue, May 12, 2015 at 1:56 AM, Thierry Moreau
thierry.mor...@connotech.com wrote:
With ECC, I have less confidence in NIST ability to leverage the
cryptographic community contributions.
One hopes they will recommend the same elliptic curve standards that the
IRTF's CFRG is
On the lightweight side, I get the impression that block ciphers are
also a big topic, but that there isn't a ton of work being done
there... besides the NSA ciphers, SIMON and SPECK. John Kelsey
mentioned these at RWC. The NSA came to NIST and said Check out these
ciphers! and NIST said
There is a very simple way around this. Block XXTEA introduced a new
method
[snip]
Although for the internet and smart cards, data packets are small enough
for 64 bit blocks not to matter as long as you rekey between packets.
To paraphrase Bowman: Oh my God. It's full of integer adders!
Are there any password managers that let the user specify where to
store a remote copy of the passwords (FTP server, scp, Dropbox,
whatever) while keeping the crypto and the master password on the end
devices?
Seems to me that would limit the cloudy trust problem while still
addresssing the
> I guess it was all just a matter of time.
>
>
A matter of time until the authors of this and certain other related
papers realize that recreating new mask sets for deep sub wavelength
silicon imaging isn't like running things through a plotter.
It's certainly worth considering these attack
>On 13/05/2016 10:43, Krisztián Pintér wrote:
>
>> okay, let me rephrase, because i was not very clear. what i tried to
>> say is: if we assume a precision with which we can possibly measure
>> the initial conditions, then there is a time interval after which the
>> system is in total uncertainty.
it can guarantee entropy sources are available. It
will work on some platforms and will certainly fail on some platforms,
particularly lightweight platforms with Linux kernels on CPUs with no
deliberately designed source of entropy which is where lightweight SSL
libraries are used most.
DJ
__
>
> This was pretty much my thinking (though idk Intel thought similar). If
> this is debatable, that's fine as long as my view isn't totally
> batt-shit-crazy :)
>
I'm the RNG Tzar and I approve this message.
___
cryptography mailing list
>
> Russell Leidich (at Friday, May 6, 2016, 10:16:12 PM):
>> Most of the entropy in a system is manifest in terms of the clock
>> skew between direct memory access (DMA) transfers from external
>> devices and the CPU core clocks, which unfortunately does not
>> traverse the kernel in any directly
> Hi!
>
> A true random number generation strategy is no better than its
> trustworthiness. Here is a suggestion for a simple scheme which rests on
> a common digital electronic design.
>
[...]
> Unavoidable current noise source:
> - thermal noise
> - excess current noise caused by the above
24 matches
Mail list logo
