

Random Numbers - someone_here
http://www.boallen.com/random-numbers.html?=resubmit

======
tptacek
All real crypto keys come from PRNGs (if they don't, you have bigger
problems). If your PRNG sucks, you're in trouble. You aren't as secure as AES;
you're as secure as your RNG.

Bernstein used a similar visualization to show diffusion in his stream cipher
over multiple rounds:

<http://cr.yp.to/snuffle/diffusion.html>

~~~
hga
Well ... the last time I had to generate real crypto keys for an application I
used a 300 US$ (in 1996) TRNG pod that used thermal noise to provide truly
random data.

We can be rather sure that TRNGs are used to make one time pads for the
intelligence community ... although strangely enough the Venona decrypts are
based on the Soviets having reused pages of random numbers, probably due to
the high demand that developed after they were invaded by Nazi Germany.

But your point about the need for a high quality (and well seeded) PNRG is
well taken, far too many crypo _system_ failures have been due to that.

As I tell people, don't worry about the cipher, you will not do better than
the experts, but make sure your whole system is sound.

And speaking of seeds, in the brave new world of cloud computing we've got to
be careful about where we get our entropy.

~~~
tptacek
Then, due respect, but the last time you had to generate real crypto keys for
an application you did so in a very unrepresentative setting. Virtually all
real-world crypto ends up depending on a CSPRNG.

I'm sure PRNGs have been used to make "one time pads"[1]. And as you know,
those aren't actually one time pads. They're stream ciphers based on PRNGs,
and are as secure as the underlying PRNG --- meaning, probably not secure at
all. Calling them OTP's perpetuates a misconception about the applicability of
OTPs to real crypto.

People have been saying "don't worry about the cipher, think about the whole
system" for two decades now, but that message has been attenuated down to "use
AES, don't try to design your own block cipher". Frankly? At this point? I
think you'd do _better_ if you started by actually designing a simple Fiestel
cipher. At least then you'd be assured some basic understanding of what these
algorithms actually do.

If you want to think scary thoughts about crypto and cloud computing, remember
that I can now spend a couple bucks to get access to a machine that has
nanosecond timing resolution to your secure app by nature of it being a single
switched gigE hop away.

Sorry about tit-for-tatting your reply, which was interesting, but I think I
had at least 2 worthwhile things to add to the discussion there. Thanks for
giving me the vector to do that.

[1] _(By way of backstory for the rest of you: one time pads are
"theoretically unbreakable" cryptosystems where you and your counterparty
somehow securely exchange blocks of truly random data, and encrypt/decrypt by
combining that random key matter with data on a 1:1 basis. They have no
relevance to real-world crypto, since they depend on you having a way to
reliably and securely exchange and retain key material that is as long as the
messages you're actually sending)._

~~~
hga
You overstate the situation with one time pads: they eliminate the decryption
issue by shifting it entirely to key distribution.

As for "real-world crypto", they've certainly been used in the 20th century
and the continued existence of number stations as mentioned on HN in the last
couple of days suggests that such simple systems might still be in use. It's
hard to get more simple than a booklet of TRNG data printed on flash paper and
a shortwave receiver.

~~~
tptacek
Instead of annoying everyone by arguing definitions for the rest of the day,
let's just stipulate that we're talking about "crypto done by computers using
products that you can actually buy and conceivably deploy in a commercial
setting".

Unless you have a physically secure channel to distribute keys (in which case,
why bother with OTPs), the fact that OTPs move the security model entirely to
"key distribution" is an academic point. Any online key distribution system
you'd come up with for your OTP is (a) going to become the fulcrum of your
entire system, and (b) by nature of feeding an OTP, going to permit a far more
restricted set of designs than any key distribution system for a
"conventional" protocol.

The reality is, OTPs are entirely unsuitable for commercial information
security. That's a strong claim, but not a slippery one, and I'm willing to
back it up.

The arguments around OTPs are surprisingly isomorphic to the arguments around
Javascript crypto.

~~~
hga
I agree with your strong claim, with the single exception of "TRNG data that
you can physically hide (i.e. in a PCIe card) may be a useful source of keys
or entropy". Which was the sort of thing I was using it for in 1996.

As for your last point, I'd personally substitute "intuitively obvious" for
"surprisingly", but I will admit I've been playing this game on and off for a
_long_ time

~~~
tptacek
You do have an awesome resume.

Why is the relationship between OTPs and Javascript crypto (apart from them
being routine signifiers of crank cryptography) intuitive to you?

~~~
hga
Perhaps for the same reason I run NoScript ( 1/2 :-) ?

OPTs obviously devolve to the key distribution problem.

The environment of client side Javascript is obviously to me a superset of the
key distribution problem. After all, you start out by distributing your code
to the (insert your favorite derogatives here) client.

Simson Garfinkel likes to refer to the whole https game as something like
transferring a valuable from a cardboard box in an alley via an armored car to
a park bench. I'd end with the end of a Matt Groening _Love is Hell_ quote:
"At night, the ice weasels come."

------
DCoder
Author, please check your site for hacks. ESET Security detects malware and
blocks connection, and bogus JS is returned after the </html> tag.

Edit: it's loading scripts and iframes from harpear.ru, which is on a lot of
known malware domain blacklists.

~~~
theboos
Avast Personal also detects a bunch of javascript trojans.

------
jmhobbs
Wrote a similar script a while back to vizualize any binary data.
[http://www.velvetcache.org/2010/03/15/bin2img-data-
visualiza...](http://www.velvetcache.org/2010/03/15/bin2img-data-
visualization-with-php)

------
esponapule
blocked at my work...Detected possible botnet command and control traffic.

