How to fill a thumb drive with random numbers?

[[email protected]]

Here's the invention: It's unbreakable computer security.
It's the oldest cypher in the book: A one-time pad.

But modern technology puts it all in a new light!

With a modern thumb drive you can have gigs of messages based on the
space in the drive. You fill the drive with random numbers and you make
a copy. Each message is exclusive ORed with the random numbers. You have
your copy and the person getting the messages has theirs. Software keeps
track of it all and erases used keys. So far so good.

But here's the rub. Just how does one fill a thumb drive with truly
random numbers say at normal write speeds? It is obviously essential the
numbers are truly random. A pseudo-random source (which would be fast
enough to generate the pad) would not be secure.

So just how can a true random sequence of numbers (say 8 bit bytes) be
generated with proper random characteristics? The usual thing of
radioactive sources or white noise do not seem fast enough. Microwave
noise perhaps? since the key is as big as the message you don't want to
use a lot of time filling the key memory.

Anybody know of a decent way to do this?

 

[Peter Webb]

Here's the invention: It's unbreakable computer security.
It's the oldest cypher in the book: A one-time pad.

But modern technology puts it all in a new light!

With a modern thumb drive you can have gigs of messages based on the space
in the drive. You fill the drive with random numbers and you make a copy.
Each message is exclusive ORed with the random numbers. You have your copy
and the person getting the messages has theirs. Software keeps track of it
all and erases used keys. So far so good.

But here's the rub. Just how does one fill a thumb drive with truly random
numbers say at normal write speeds? It is obviously essential the numbers
are truly random. A pseudo-random source (which would be fast enough to
generate the pad) would not be secure.

So just how can a true random sequence of numbers (say 8 bit bytes) be
generated with proper random characteristics? The usual thing of
radioactive sources or white noise do not seem fast enough. Microwave
noise perhaps? since the key is as big as the message you don't want to
use a lot of time filling the key memory.

Anybody know of a decent way to do this?

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.

 

[Helmut Wabnig]

Here's the invention: It's unbreakable computer security.
It's the oldest cypher in the book: A one-time pad.

But modern technology puts it all in a new light!

With a modern thumb drive you can have gigs of messages based on the
space in the drive. You fill the drive with random numbers and you make
a copy. Each message is exclusive ORed with the random numbers. You have
your copy and the person getting the messages has theirs. Software keeps
track of it all and erases used keys. So far so good.

But here's the rub. Just how does one fill a thumb drive with truly
random numbers say at normal write speeds? It is obviously essential the
numbers are truly random. A pseudo-random source (which would be fast
enough to generate the pad) would not be secure.

So just how can a true random sequence of numbers (say 8 bit bytes) be
generated with proper random characteristics? The usual thing of
radioactive sources or white noise do not seem fast enough. Microwave
noise perhaps? since the key is as big as the message you don't want to
use a lot of time filling the key memory.

Anybody know of a decent way to do this?

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.

 

[TTman]

Here's the invention: It's unbreakable computer security.
It's the oldest cypher in the book: A one-time pad.

But modern technology puts it all in a new light!

With a modern thumb drive you can have gigs of messages based on the space
in the drive. You fill the drive with random numbers and you make a copy.
Each message is exclusive ORed with the random numbers. You have your copy
and the person getting the messages has theirs. Software keeps track of it
all and erases used keys. So far so good.

But here's the rub. Just how does one fill a thumb drive with truly random
numbers say at normal write speeds? It is obviously essential the numbers
are truly random. A pseudo-random source (which would be fast enough to
generate the pad) would not be secure.

So just how can a true random sequence of numbers (say 8 bit bytes) be
generated with proper random characteristics? The usual thing of
radioactive sources or white noise do not seem fast enough. Microwave
noise perhaps? since the key is as big as the message you don't want to
use a lot of time filling the key memory.

Anybody know of a decent way to do this?

Not in software, but it is easy with hardware.

 

[Uwe Hercksen]

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.

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

 

[Jeroen Belleman]

Not in software, but it is easy with hardware.

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

 

[Bob Masta]

Here's the invention: It's unbreakable computer security.
It's the oldest cypher in the book: A one-time pad.

But modern technology puts it all in a new light!

With a modern thumb drive you can have gigs of messages based on the
space in the drive. You fill the drive with random numbers and you make
a copy. Each message is exclusive ORed with the random numbers. You have
your copy and the person getting the messages has theirs. Software keeps
track of it all and erases used keys. So far so good.

But here's the rub. Just how does one fill a thumb drive with truly
random numbers say at normal write speeds? It is obviously essential the
numbers are truly random. A pseudo-random source (which would be fast
enough to generate the pad) would not be secure.

So just how can a true random sequence of numbers (say 8 bit bytes) be
generated with proper random characteristics? The usual thing of
radioactive sources or white noise do not seem fast enough. Microwave
noise perhaps? since the key is as big as the message you don't want to
use a lot of time filling the key memory.

Anybody know of a decent way to do this?

First of all, this plan has the shortcoming of all one-time
pads: You have to get the key to the recipient by some
*other* means, which typically involves physical delivery.

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
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!

 

[[email protected]]

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.

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.

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.

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

 

[Jeroen Belleman]

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.

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

[...]

You should use the OTP only ONCE.
See why?

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

 

[Jeroen Belleman]

[About LFSR RNGs...]
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.)

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

 

[Helmut Wabnig]

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?

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.

 

[Spehro Pefhany]

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

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

 

[Bill Martin]

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

bill

 

[[email protected]]

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

bill

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.

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

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

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

 

[glen herrmannsfeldt]

(snip)

I was in Signal Intelligence in WWII in North Africa. Many of the
messages we intercepted and sent to Bletchley Park contained violations
of procedures that allowed for the determination of the Enigma settings
used. For example many encoded messages contained the phrase
"Heil Hitler".

As I understand it, one of the biggest mistakes of Enigma was that
it never mapped a letter to itself. That sounds like a small effect,
but statistically it turns out to be big. For one, if there is a phrase
that you know is in the message, the longer the better, you can
easily find where it isn't (any letters match), and so reasonably
quickly where it is.

Some of our more skilled operators would "join" a German net and
attempt to make someone violate crypto principals by re-sending
text, etc. We never knew how well this succeeded;
I didn't know of Bletchley Park until much later.

Most modern crypto systems are compromised by human error.

Does "human error" include spies? (Or the hiring of spies?)

-- glen

 

[glen herrmannsfeldt]

(snip, someone wrote)

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.

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

-- glen

 

[Les Cargill]

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.

Couldn't you input Johnson noise with a soundcard, and record it at
24 bits? So long as you got the gain within 3dB of optimum or so...

That seems within the reach of just about anybody.

 

[Bob Masta]

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.

As far as I can tell, a true OTP (that is used only *once*)
can't be broken even if the key is quite far from random.
The reason is that there is no basis for an analysis...
symbol frequency, etc, is meaningless in this case.
I mean, you can't have "AAAAAAA..." as the key, but any
chunk of arbitrary data would be OK, and even arbitrary text
if you were only encrypting text (no high bits set in plain
ASCII). But your key must be at least as long as the
message, and can never be used again.

If I understand the initial post, you were planning on
something that approaches that. With a 1 GB (say) key, you
could send a lot of (relatively) short text messages or data
files before you ran out of key bytes. If you then started
over at the beginning of the key you'd have pretty good
security unless the crackers knew your key length and how
many messages you had sent. Then they could in principle
get two different messages encrypted with the same key
bytes, which would give them the key via XOR... but only
that part of the key for which they had the pair of
messages. They'd have to wait for a complete 2nd pass
through your 1 GB key to get the whole thing. And once they
had it, in order to use it they would have to know where in
the 1 GB any given message was encrypted. Incidentally,
that little difficulty would also apply to you and your
intended recipient... you'd only be able to use that thumb
drive with one recipient so you'd both remain in sync.

Best regards,


Bob Masta

DAQARTA v6.02
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!

 

[Bob Masta]

[About LFSR RNGs...]
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.)

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

I would indeed be surprised, but wold love to be educated.
Can you provide a Web link or citation?

Best regards,


Bob Masta

DAQARTA v6.02
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!

 

[FatBytestard]

As far as I can tell, a true OTP (that is used only *once*)
can't be broken even if the key is quite far from random.
The reason is that there is no basis for an analysis...
symbol frequency, etc, is meaningless in this case.
I mean, you can't have "AAAAAAA..." as the key, but any
chunk of arbitrary data would be OK, and even arbitrary text
if you were only encrypting text (no high bits set in plain
ASCII). But your key must be at least as long as the
message, and can never be used again.

If I understand the initial post, you were planning on
something that approaches that. With a 1 GB (say) key, you
could send a lot of (relatively) short text messages or data
files before you ran out of key bytes. If you then started
over at the beginning of the key you'd have pretty good
security unless the crackers knew your key length and how
many messages you had sent. Then they could in principle
get two different messages encrypted with the same key
bytes, which would give them the key via XOR... but only
that part of the key for which they had the pair of
messages. They'd have to wait for a complete 2nd pass
through your 1 GB key to get the whole thing. And once they
had it, in order to use it they would have to know where in
the 1 GB any given message was encrypted. Incidentally,
that little difficulty would also apply to you and your
intended recipient... you'd only be able to use that thumb
drive with one recipient so you'd both remain in sync.

Best regards,


Bob Masta

DAQARTA v6.02
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
Frequency Counter, FREE Signal Generator
Pitch Track, Pitch-to-MIDI
Science with your sound card!

This is good stuff you have thought through here. Since the "re-use"
is also only limited to a single additional pass and use, the message(s)
et all would still be good.

So, a 'Two Use Pad' is doable if YOU are the guy laying down the rules,
and getting it set up so as to not screw up your method. And then
getting all those who may not 'see it' yet up to speed.

--------
As for the "filling" of the drive thing, would not such drives still
be tied to our OS paradigms and be more correctly referred to as a
"single file write with random numbers"? Because there is no way to
write to them otherwise.

Unless one makes a specific "key drive", meant to be a watchdog circuit
managed (right there on the 'drive'), proprietary key fill/dump system.

Using a file system managed "file write" as a key is easy.

One makes a large, random key, then you take a snapshot frame within
that key to make the 'keyfile' you write to the thumb drive. You're
done.

Now to take the literal, and "fill" the drive with random bits, one
would have to put a circuit on the drive to manage the space.

Operating systems already think of such devices as "thumbdrives" as a
mass storage device as soon as you plug it in (it IDs itself actually),
even before we put ANY file system on them. This means that the ONLY way
to "fill it" is by formatting it with a file system your OS uses and
works with, and writing a file to it.

There is no "fill" on thumbdrives. One could use an old defragmenter,
which used to be able to do it, but I doubt any of those would do that
with these drives. They wouldn't work at all, in fact, as they worked
through the BIOS in the good old days on the drives they were used on.

So this means one would actually have to create a new USB hid device
group. Like the watchdog circuit managed system mentioned above, where
the "thumbdrive" is a dedicated keyFOB type thingy and would no longer be
'seen' by the machine you plug it into as a mass storage device, but as
your new keyFOB device.

We already do this stuff.

Nothing new... move on.

Reverts back to a basic discussion on making a random string again.

I like your stuff here though, Bob.