How to fill a thumb drive with random numbers?

Couldn't you input Johnson noise with a soundcard, and record it at

That seems within the reach of just about anybody.

-- Les Cargill

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

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

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.

Ding! Good one!

Group added, as it should be. Group removed.

^ only

IHTUTFYPFY (I Had The Urge To Fix Your Post For You)

Idiot. It is all caps.

The OTP is only as good as the random number generator that created it. So, no, this is not correct.

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

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.

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

Not all OS automatically mount devices without being told.

cat /dev/random >/dev/sda works here on an unmounted thumb drive.

Not easy to know when the drive is full, though. I just let it run a few minutes, then -c.

Like procedural headers and stuff. The systematic Germans liked those.

Look up the Berlekamp-Massey algorithm.

Jeroen Belleman

That's disingenuous and misleading. Firstly, the 'environmental signals' at the generation site aren't generally accessible to a cracker. Second, 'correlation' might be high to a MSB but negligible to other bits of a measurement (the refrigerator hum doesn't dominate a microphone pickup of Brownian motion, if you know enough to apply masking). Third, 'cryptographically random' can mean any old wishlist of properties, few if any of which relate to the needs of an XOR-against-constant encryption.

I've heard it said that a cryptographically random source has less than 2**-64 imbalance of ones and zeroes; even just CHECKING a string of bits for that kind of imbalance would take over 2**128 bits of sample size, about 2**98 seconds of a 1Gbit/sec signal channel. A year is 2**25 seconds.

Hardly.

Irrelevant. Have you ever heard of autocorrelation?

Wrong. The correlated noise is reduced "randomness", effectively reducing the strength of the keys.

Absolute nonsense. The strength of the pad is crucial to OTP cryptography.

An absurd statement.

No one said this stuff was easy.

=20

=20

=20

=20

=20

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

?-)

point a satellite dish at the sun.

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.

Best regards,

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

Please explain. (See below)

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.

Best regards,

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

With a vibrator attached to the pointing arm.