How to fill a thumb drive with random numbers?

Don't use this technique for the message. Use it for a hash key.

Internet connections using SSL use a similar "trick". The public/private keys pairs are very expensive to compute. So they are not used for the content to be exchanged - which may be Megabytes or Gigabytes - they are only used to exchange a DES key, which is what actually encrypts the data.

Encipherment does not have to be 100% secure, all it requires is to keep the enemy busy long enough to make your message worthless once it is decoded.

w.

Not in software, but it is easy with hardware.

Helmut Wabnig schrieb:

Hello,

but what if you think the enemy will be busy for at least ten years, but he is ready to read all messages in only one day after only one year of krypto analyses?

Bye

No it's not. It's surprisingly difficult to come up with a truly random crypto-quality RNG. It's even harder to ascertain that indeed your numbers *are* truly random.

Then again, you don't really need a one-time-pad. There are plenty of encryption algorithms around that give decent protection using a reasonably-sized key. At some point, it becomes much easier to get the message by other means than trying to decrypt it.

Jeroen Belleman

First of all, this plan has the shortcoming of all one-time pads: You have to get the key to the recipient by some

But as for your question, I don't think you need to worry about perfect randomness (whatever that is). All that is needed is that the generator pattern not be predictable, given a particular sample of the stream. That's easy to arrange: just make the repeat sequence very long. It's trivial to make this millions (or billions) of years at current CPU speeds.

And even if it was much shorter, there is still the problem for a cracker to deduce the next state from a limited snippet of the pattern. I don't think this is particularly do-able except for certain weak generators like linear congruential with all bits visible. (If you can only see, say, the lowest 32 bits out of 64, you don't know where you are in the 2^64-1 possible states... you'd need to analyze a long sequence to know.)

Best regards,

Bob Masta DAQARTA v6.02 Data AcQuisition And Real-Time Analysis

On a sunny day (Fri, 02 Mar 2012 13:46:42 +0100) it happened Jeroen Belleman wrote in :

Little remark I recently did read in sci.crypt: In the one time pad, with truly random numbers, half the bits are the same as the original.

If you just want random (tm): cp /dev/random /dev/usbstick Let it run a couple of weeks. If you have no patience: cp /dev/urandom /dev/usbstick where usbstick is of course the device name.

You should use the OTP only ONCE. See why?

I've been saying that, here, for years. Few believe it. There are all sorts of pitfalls to getting cryptographically random numbers. Correlation of a noise source to environmental signals, for example, is just too easy.

OTPs also have the disadvantage of lying around for a long time, making them easy to "intercept" at some point. The other issue with OTPs is reuse. It's too easy to reuse one (people don't understand just how important the 'O' in "OTP" is).

Yes. But you don't know which ones. ;-)

Yes, of course. In the case of using XOR, just XORing the encrypted messages together would cancel the random key, leaving you with the XOR of two clear-text messages, which is usually pretty easy to decode.

Jeroen Belleman

You'd be surprised then to learn that just by looking at the LSB, a string of about 128 consecutive values from anywhere in the sequence is enough to work out the the whole thing in no time flat.

Jeroen Belleman

Exactly this or almost this took place in WW2 with the German Enigma. Germans always suspected traitors and treason (which also happened) but indeed it was Bletchley Park.

In fact, the Germans were able to read several top level British codes, only little to nothing is documented and available for us to know.

w.

Thermal (Johnson) noise from a resistor is random. So is shot noise from a photodiode. In real life, any such amplified and processed signal will have a little residual bit bias and autocorrelations, so it's prudent to xor several of them, and maybe add a little digital scrambling for luck.

Generating, say, 10 or even 100 megabits per second wouldn't be hard from Johnson or shot noise.

There are software ways to do this that might not impress the CIA but would be unbreakable by anybody without megabucks to spend.

See "Venona" for a public domain example of people who didn't understand the latter point.

Right, just fill it up with Usenet postings & you are done... :-)

bill

Really, you could have a computer download a bunch of non-static web pages or usenet postings sequentially, xor random fields into a digital scrambler, and be done. The Drudge Report might work.

Some very basic circuits can generate reliable random bits. 'Difficult' or not depends on your skill set

BINGO! :-)

Interesting discussion but let me emphasize a couple of points.

1. Unbreakability. In the OTP it can't be broken without the key if the key is truly random (the problem). Note for example NSA employs half the math graduates in the country! And that doesn't matter because it only takes ONE math whiz to find an easy way into your "perfect" brainchild. And there are quite a few math whizzes in countries that might have an interest in some high-tech industrial information.

1. One time. The idea of a thumb drive is that the software erases the pad in use. Yes you might be able to read the whole drive and copy it beforehand, but a good setup would make that difficult because any use (especially reading) would erase the pad. Hence re-use is out. If you can keep the drive in your possession it's (hopefully) secure.

2. Truly random. Scheme requires truly random numbers. This means a truly random source. Radioactivity, electronic noise (but with NO environmental sources!), usenet posts! etc. The point is not to be "good enough" but so good nobody can break in. The technology change that works here is modern storage devices that can hold gimongous keys large enough for say all the emails you'd ever send in your life!

Aside. I have a white noise generator used in jamming transmitters in WWII. It's a magnet around a thyratron. Makes REALLY good looking white noise, but there's something I discovered. If you put a scope on it and run the sweep up very fast you can find it triggering on some sort of high frequency (megaHz range) that gives the first couple humps of a sine wave and then trails off into randomness. Clearly Something in this generation scheme is not truly random at high frequencies.

1. Data speed. The essence of this idea would be along the lines of say a business that fills thumb drives with random numbers and sells them in pairs for secure communications (and of course the software sold separately that runs them). This seems to require VERY high speed noise sources! Even my thyratron is pretty slow. Even without the sine wave thing, I'll bet you couldn't get good data at more than a megabyte/s out of it. Letting it run for a week is OK for ONE drive-pair but not in production. So the question would be what kind of REALLY fast physical phenomena is really fast? Electron clouds? 2D photons? What? For example, how could you generate a truly random bit stream say at the rate of a standard SATA serial bit stream?

This is one of those things that is so simple, yet the devil is in the details.

(snip, someone wrote)

and in an polyalphabetic substitution cypher 1 in 26 (or other alphabet size) should by the same. Note the failure of Enigma.

-- glen

I once had a box from a WWII-vintage radar jammer that used a 931A photomultiplier as the source of random pulses.