How to fill a thumb drive with random numbers?

[be...@iwaynet.net]

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]

"BJA...@teranews.com" <be...@iwaynet.net> wrote in message
news:BU_3r.3974$X%7.2...@newsfe01.iad...

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]

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]

"BJA...@teranews.com" <be...@iwaynet.net> wrote in message
news:BU_3r.3974$X%7.2...@newsfe01.iad...

Not in software, but it is easy with hardware.

[Uwe Hercksen]

Helmut Wabnig schrieb:

> 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]

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]

On Fri, 02 Mar 2012 02:45:54 -0500, "BJA...@teranews.com"
<be...@iwaynet.net> wrote:

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!

[Jan Panteltje]

On a sunny day (Fri, 02 Mar 2012 13:46:42 +0100) it happened Jeroen Belleman
<jer...@nospam.please> wrote in <jiqfff$7dt$1...@speranza.aioe.org>:

>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

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.

[1]Now let that sink in your concept of total security :-)

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?

[k...@att.bizzzzzzzzzzzz]

On Fri, 02 Mar 2012 13:46:42 +0100, Jeroen Belleman <jer...@nospam.please>
wrote:

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]

On 2012-03-02 14:33, Jan Panteltje wrote:
> On a sunny day (Fri, 02 Mar 2012 13:46:42 +0100) it happened Jeroen Belleman
> <jer...@nospam.please> wrote in<jiqfff$7dt$1...@speranza.aioe.org>:
>
>> 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
>
> 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]

On 2012-03-02 14:21, Bob Masta wrote:

> [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]

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.

[John Larkin]

On Fri, 02 Mar 2012 02:45:54 -0500, "BJA...@teranews.com"
<be...@iwaynet.net> wrote:

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.


--

John Larkin, President Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

[Spehro Pefhany]

On Fri, 02 Mar 2012 08:50:20 -0500, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:

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

[VWWall]

Helmut Wabnig wrote:
> On Fri, 02 Mar 2012 12:24:34 +0100, Uwe Hercksen
> <herc...@mew.uni-erlangen.de> wrote:
>
>>
>> Helmut Wabnig schrieb:
>>
>>> 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?
>>
> 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.
>

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

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.

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

No comment!

--
Virg Wall

[Bill Martin]

On 03/02/2012 07:11 AM, John Larkin wrote:
> On Fri, 02 Mar 2012 02:45:54 -0500, "BJA...@teranews.com"
> <be...@iwaynet.net> wrote:
>
>> 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!
>>

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

bill

[John Larkin]

On Fri, 02 Mar 2012 10:02:40 -0800, Bill Martin <w...@wwmartin.net>
wrote:

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.


--

John Larkin, President
Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser controllers

Photonics and fiberoptic TTL data links

VME thermocouple, LVDT, synchro acquisition and simulation

[David Eather]

On Fri, 02 Mar 2012 22:46:42 +1000, Jeroen Belleman <jer...@nospam.please>
wrote:

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

> 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

--
We have failed to address the fundamental truth that endless growth is
impossible in a finite world.

[be...@iwaynet.net]

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]

In sci.physics.electromag VWWall <vw...@large.invalid> wrote:

(snip)

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

> 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]

In sci.physics.electromag Jan Panteltje <pNaonSt...@yahoo.com> wrote:

(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

[John Larkin]

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


--

John Larkin, President
Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser controllers

Photonics and fiberoptic TTL data links

[Michael A. Terrell]

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

Fair Radio had new WW II surplus aircraft jammers that used a
phototube for noise source for the wideband modulator. The thing would
wipe out the entire band used by all aircraft to prevent a plane on
patrol from contacting more planes. I should have bought one, but they
are long gone.


--
You can't have a sense of humor, if you have no sense.

[VWWall]

glen herrmannsfeldt wrote:
> In sci.physics.electromag VWWall <vw...@large.invalid> wrote:
>
> (snip)
>>> 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.
>
>> 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.
>

Here is an "Enigma Simulator":

http://www.bletchleypark.org.uk/content/enigmasim.rhtm

You can play games with it!

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

You don't need spies to exploit human error.

--
Virg Wall

[Les Cargill]

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.

--
Les Cargill

[Bob Masta]

On Fri, 02 Mar 2012 15:31:07 -0500, "BJA...@teranews.com"
<be...@iwaynet.net> wrote:

>On 3/2/2012 1:02 PM, Bill Martin wrote:
>> On 03/02/2012 07:11 AM, John Larkin wrote:
>>> On Fri, 02 Mar 2012 02:45:54 -0500, "BJA...@teranews.com"
>>> <be...@iwaynet.net> wrote:
>>>
>>>> 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!
>>>>
>>
>> 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.

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.

[Bob Masta]

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

[FatBytestard]

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.

[WoolyBully]

Idiot. It is all caps.

[k...@att.bizzzzzzzzzzzz]

On Sat, 03 Mar 2012 13:43:46 GMT, N0S...@daqarta.com (Bob Masta) wrote:

>On Fri, 02 Mar 2012 15:31:07 -0500, "BJA...@teranews.com"
><be...@iwaynet.net> wrote:
>
>>On 3/2/2012 1:02 PM, Bill Martin wrote:
>>> On 03/02/2012 07:11 AM, John Larkin wrote:
>>>> On Fri, 02 Mar 2012 02:45:54 -0500, "BJA...@teranews.com"
>>>> <be...@iwaynet.net> wrote:
>>>>
>>>>> 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!
>>>>>
>>>
>>> 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.
>
>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 OTP is only as good as the random number generator that created it. So,
no, this is not correct.

>The reason is that there is no basis for an analysis...
>symbol frequency, etc, is meaningless in this case.

The same would hold true for the random number generator that created it.
"Quite far from random" is the key.

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

No, because the key is then that text. Search text for the key. It's just a
matter of (simple) horsepower. The strength *is* the randomness of the OTP.
Remember, security by obscurity (the key text) isn't.

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

Listen into the entire conversation. When the key loops, you have it all.

[Jeroen]

On 2012-03-03 14:46, Bob Masta wrote:
> On Fri, 02 Mar 2012 15:25:29 +0100, Jeroen Belleman
> <jer...@nospam.please> wrote:
>
>> On 2012-03-02 14:21, Bob Masta wrote:
>>
>>> [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?
>

Look up the Berlekamp-Massey algorithm.

Jeroen Belleman

[josephkk]

On Fri, 02 Mar 2012 15:31:07 -0500, "BJA...@teranews.com"
<be...@iwaynet.net> wrote:

"Randomly" xor groups of files from LHC and hash them, should yield many
MB/s.

?-)

[Jasen Betts]

On 2012-03-02, BJA...@teranews.com <be...@iwaynet.net> wrote:
> 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?

point a satellite dish at the sun.

--
⚂⚃ 100% natural

[Bob Masta]

Many thanks for that! But on looking over the relevant
links, it appears that this will only find the minimum
length of an LFSR. That would certainly be a useful clue
for a cracker, but unless I missed something (always a
possibility!) that wouldn't be all that much help. Knowing
that wouldn't tell you the current position in the sequence,
which is what you really need.

It also appears to be only for LFSR, not linear congruential
(not that I favor the latter for anything other than
simplicity).

In addition, it seems to only apply to the "canonical"
academic-type single bit-stream LFSR. I expect that anyone
using LFSR for serious work will use a separate LFSR (same
length but different position) for each bit... it's actually
way simpler to implement than the canonical since you
replace shifts with pointer math, and work on all bits at
once.

[Bob Masta]

Please explain. (See below)

>>The reason is that there is no basis for an analysis...
>>symbol frequency, etc, is meaningless in this case.
>
>The same would hold true for the random number generator that created it.
>"Quite far from random" is the key.
>
>>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.
>
>No, because the key is then that text. Search text for the key. It's just a
>matter of (simple) horsepower. The strength *is* the randomness of the OTP.
>Remember, security by obscurity (the key text) isn't.

I'm not sure I follow your thinking. I'm assuming only that
the cracker doesn't know the key ahead of time... no way to
"search the text for the key". If he tries random text
(like the random Web pages or NG posts suggested earlier) he
will get random garbage unless he happens to hit on the
right one... exactly what would happen with a "perfect"
random key. The drawback with "real" text (as opposed to
semi-random characters) would be that, if he *knew* that's
what it was he could apply certain language assumptions.
This is not really much help, IMHO.

Remember, this is one pass only, so there is no pattern for
the cracker to search for. He could generate some random
numbers or select an arbitrary Web page, etc, and XOR it
with the code text. Then he has to decide if the result is
the original plain text. This is not trivial, unless he
happens to know quite a lot about what he is looking for.
Only then can he move on to trying another putative key.
The sheer number of (say) possible Web pages to try would
make this deathly slow.

[Chieftain of the Carpet Crawlers]

With a vibrator attached to the pointing arm.