Gibson Research Corporation's Ultra-High Entropy Pseudo-Random Number Generator

It is snake oil crypto. It is not safe for cryptographic use. I didn't see them claim that it can be used for cryptographic use on OP's page but they do claim it is a CSPRNG in the header in their js implementation: https://www.grc.com/js/uheprng.js

>This is GRC's cryptographically strong PRNG (pseudo-random number generator)

Don't use it for security or crypto. A CSPRNG should not allow the internal state to be determined from observing the output. The hash function Mash() they use is not one-way and this break can reverse it. It does not provide prediction resistance or backtracking resistance.

What's wrong with Shieldsup? My experience is that it works perfectly fine.

I still use the DNS speed finder.

Forget "ShieldsUp!" This is the guy who still sells SpinRite for $90 when it hasn't seen an update since 2004. It's old enough to vote at this point and Steve Gibson is always spouting off blatant lies about how it's great for recovering SSDs. He's claimed that it can magically read uncorrectable sectors on modern drives (SATA, not SAS, no SCSI READ LONG here and no ancient IDE drives that still supported READ LONG for ATA) and compare results to figure out what the original data was. He claims that it's data recovery software and that people should run it on a failing hard drive before trying to copy data off of it with a real data recovery program! That piece of garbage doesn't even support writing data to a separate disk, the only thing it can do is write the data the drive was able to read back to the failing drive itself.

The technical documentation claims stuff like that it disables bad sector allocation. That's actually a thing, but if you read the man page for some reputable software like hdparm you'll see a nice little note:

> Control of this feature via the -D option is not supported for most modern drives since ATA-4; thus this command may fail.

ATA-4 was standardized in 1998. It can probably actually disable write caching, but it's not like that's unique to SpinRite in the slightest. It's even trivial to change that on Windows which is otherwise horrible for anything low level involving disks. SpinRite doesn't even use LBA48 addressing so if your drive can't address the full capacity in ye olde CHS then too bad, but SpinRite will try to spin that as a problem with your BIOS, a problem with your SATA controller, etc.

I don't see why anyone respects anything he says given his long history of selling snake oil and other shyster tactics. Even the Wikipedia page for SpinRite looks astroturfed and the talk section has a bunch of responses from an unregistered user that all seem to have a similar tone and be suspiciously supportive of some of SpinRite's dubious claims.

If Steve Gibson told me that the sky was blue I think I'd have to go outside and check.

http://www.hddoracle.com/viewtopic.php?f=181&t=2929

Very well put and worth reinforcing by thinking of PRNGs as entropy reduction functions on the original seeds, that ideally loose as little entropy as possible per generation cycle.

It’s mechanically solvable but not in any practical timescale. A naive approach would be to check every square with no repeats in the rows, which requires (26!)^26 attempts, or roughly 5e691. Obviously you can improve that by exploiting symmetry, shifts, etc, but that only gets you a few orders of magnitude. There are much cleverer techniques, but when your baseline is so ludicrously impossible you need a real breakthrough to make any progress.

> If you have enough entropy to fill a high entropy RNG, why not use all that entropy to generate the output in the first place?

Problem is the entropy generation rate. PRNG even with large space typically is running at 10 or better Gbit/sec. PCG with 256/64bit could generate decent numbers at 50Gbit/sec

The issue is that you cannot directly pick one of the outputs using the entropy, you have to use some kind of probabilistic algorithm to traverse the state space and find valid output. When the PRNG's cycle is smaller than the output space then the output distribution is obviously non-uniform. This might seem like inconsequential observation with CSPRNG, but depending on how exactly the state traversal works, such constructions can have real output spaces that are several orders of magnitude smaller than cycle of the used RNG. (to the extent that when used with (CS)PRNG with 128b state the output bias is observable from practical amount of outputs)

Oh dear what is mash() even doing.....

Pure software can't actually generate mathematically-provable random numbers unless given purely random data to start with.

So pseudo removes total dependency on physical events.

Why you don't want to be dependent on physical events:

- You never know if physical events are truly random unless you test them. Your physical RNG source may be broken or compromised.

- A good strategy is to use multiple physical sources of randomness, and this can be any number of things, including modern CPUs with RDRAND (if you trust them), USB attached devices, sampling ADC noise on your sound card, timing network events, etc. Any/all of that has to be combined somehow anyway. Getting data from some of these may be slow.

- So if an operating system needs random numbers quickly, for SSL key generation, UUIDs, nonces, etc. it should use properly seeded pseduorandom numbers.

My guess is that you didn't need it anyway, and we didn't need your baseless ad hominem.