# How does GRC password generator get 512 bit of secret data?

I'm trying to understand how GRC password generator can get 512 bit of secret data while encrypting 128-bit of data.

The generator address is located here: https://www.grc.com/passwords.htm See the "The Techie Details" section at the end of the webpage.

They wrote:

The result of the combination of the 256-bit Rijndael/AES secret key, the unknowable (therefore secret) present value of the 128-bit monotonically incrementing counter, and the 128-bit secret Initialization Vector (IV) is 512-bits of secret data providing extremely high security for the generation of this page's "perfect passwords". No one is going to figure out what passwords you have just received.

Diagram they provide:

What I tried is

I made a new IV (128-bit):

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00])


A monolitic counter - what is actually encrypted (128-bit):

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01])


An encryption Key (256-bit): , 32 bytes)

Buffer([00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00])


They XOR the IV with the monolitic counter (or the last encryption result with the monolitic counter, if there is a last result).

They say it gives them 512-bit of secret data. But when I encrypt everything I get 16 bytes (128-bit) of data:

<Buffer ad 86 de 83 23 1c 32 03 a8 6a e3 3b 72 1e aa 9f>


How do they get 512 bit of "secret" data? And how they XOR 512bit of data with 128-bit from the monolitic counter?

And how they XOR 512bit of data with 128-bit from the monolitic counter?

He doesn't. Look carefully at the algorithm you posted. All XOR operations occur on 128 bit values. The 256 bit entry is the key for a 256 bit AES implementation. The SPDT switch starts off using the secret IV and then switches to running with a 128 bit counter. The 512 bits comes from 512 = |IV| + |counter| + |key|. This is all a bit nonsensical as he's putting in 512 bits of (alleged) entropy and only generating a password of 128 bits. This is exactly what you've proved to yourself. Typically the AES-CTR-PRNG algorithm is as below (without any switches) and Steve's method is characteristically unusual.

How do they get 512 bit of "secret" data?

Who knows? It's probably calls to CryptGenRandom (Steve's a Windows man), but perhaps it's just hard coded somewhere. And in assembly only no doubt. Or it might come from his Ultra-High Entropy Pseudo-Random Number Generator based on Latin Squares. Another doozy.

No one is going to figure out what passwords you have just received.

Reach for the salt. This is clearly false. Any SSL intercepting router along the line can decrypt and read the web traffic (on the fly). And Steve knows too. Perhaps the moral of this question is - do not use a web service to obtain your password or key from. If you're really stuck for a key /password either use dice or just randomly hit keys on the keyboard. That was good enough for top secret one time pads during WW2 so it should suffice for you.

You have actually asked the wrong question. You should have asked who is Steve Gibson? Google him and find out. There are masses of articles. I can't write any more without sacrificing my composure and professionalism.

• Wow hahaha thank you very much. Very interesting answer. So I shouldn't trust this website because it's a website but also, and this is the thing that came out at me, because the website try to be transparent by explaining how they generate the keys but failed and proved that they are quite wrong while doing so. Thanks again for your time – Jeremy Dicaire Oct 28 '17 at 2:11
• @JeremyDicaire You might want to take a look at this and remember it next time you see anything GRC-related... – forest Dec 31 '17 at 6:35