Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Random Numbers

boallen.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Random Numbers

#11

Post by tptacek »

hga wrote: post #9
tptacek wrote: post #2

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

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 develop…

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).

Re: Random Numbers

#12

Post by tptacek »

ktsmith wrote: post #10
tptacek wrote: post #4

Earlier quoted context omitted.

The only conclusion you can draw from Reddit is that his pictures would be less interesting if you use mt_rand() instead of rand(). mt_rand() is still insecure. Since published research on RNGs seems to severely lag research on block ciphers and even hash functions, it seems like a really bad idea to build anything that needs to be safe on an RNG that was never designed to be secure.

I certainly wasn't trying to debate the value of mt_rand or it's implementation of the Mersenne Twister. I was simply trying to point out this is an extremely old issue, and that the problem specified in the article (a visible problem with rand()) is removed by using mt_rand(). Also, the issue only occurs due to problems with the PRNG on Windows specifically and was not present on other operating systems. The use of…

You managed to point out how extremely old this issue was in a manner that implied that mt_rand() was safe for use for security. Since this is an extremely, extremely common problem in PHP code, your comment did more harm than good.

Re: Random Numbers

#13

Post by hga »

tptacek wrote: post #11
hga wrote: post #9

Earlier quoted context omitted.

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 develop…

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…

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.

Re: Random Numbers

#14

Post by tptacek »

hga wrote: post #13
tptacek wrote: post #11

Earlier quoted context omitted.

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…

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…

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.

Re: Random Numbers

#15

Post by ktsmith »

tptacek wrote: post #12
ktsmith wrote: post #10

Earlier quoted context omitted.

I certainly wasn't trying to debate the value of mt_rand or it's implementation of the Mersenne Twister. I was simply trying to point out this is an extremely old issue, and that the problem specified in the article (a visible problem with rand()) is removed by using mt_rand(). Also, the issue only occurs due to problems with the PRNG on Windows specifically and was not present on other operating systems. The use of…

You managed to point out how extremely old this issue was in a manner that implied that mt_rand() was safe for use for security. Since this is an extremely, extremely common problem in PHP code, your comment did more harm than good.

Since you feel it was so harmful I've removed it.

Re: Random Numbers

#16

Post by hga »

tptacek wrote: post #14
hga wrote: post #13

Earlier quoted context omitted.

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…

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…

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

Re: Random Numbers

#17

Post by tptacek »

hga wrote: post #16
tptacek wrote: post #14

Earlier quoted context omitted.

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…

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

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?

Re: Random Numbers

#18

Post by hga »

tptacek wrote: post #17
hga wrote: post #16

Earlier quoted context omitted.

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

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?

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."

Re: Random Numbers

#19

Post by DCoder »

Author, please check your site for hacks. ESET Security detects malware and blocks connection, and bogus JS is returned after the tag.

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

Re: Random Numbers

#20

Post by theboos »

DCoder wrote: post #19

Author, please check your site for hacks. ESET Security detects malware and blocks connection, and bogus JS is returned after the tag. Edit: it's loading scripts and iframes from harpear.ru, which is on a lot of known malware domain blacklists.

Avast Personal also detects a bunch of javascript trojans.
Post reply on HN