@maq No! You must use different salts or you're boned.

Also note that an attacker will not actually ever perform this attack. They might as well skip the expensive hashing step and just brute force the key directly.

Correct. And since you're hashing your password, only the entropy matters, not how you chose the specific string of characters. I recommend Diceware passwords for wireless networks quite regularly.

You're thinking of PBKDF2 or another password-based KDF. Those take an iteration count and are purposely slow. HKDF is an example of a general KDF; it does not perform key stretching, and takes "input key material" instead of a passphrase. Feed it the key material you have, whatever length, and a different "info" value (salt) for each different key you want out. Then you can get exactly the number of bytes you need out of it, however many that is.

You're not going to get a whole lot of answers to a question about a paper behind a paywall!

@GeorgeBailey Autonomous System Number, I think.

Putting an upper limit on number of characters in a password is usually a sign you're thinking about things wrong. Your hash function won't care how long the password is or what characters are in it, and you shouldn't either. Hash it, throw it away, and never touch it again.

You haven't specified the length of the passwords in the adversary's search space. 30% of a million-bit search space is still a lot; 30% of all 6-character strings is embarrassingly small.

The square device comes in a couple forms. The original one was a simple passive device connecting a magnetic read head to the mic line. The signal's power came from the physical movement of the card. The newer ones have an encryption IC inside, and the app plays a tone to power it. The IC returns the data over the mic line by modulating the signal.

20 kbps isn't a lot; are you sure someone was logged in, and not just trying to log in a bunch of times? I'd check the Security log for remote logon events to see if someone actually succeeded or not, and what account they got in with, if any.

I'm pretty sure Visual Studio has a debugger window for viewing (and searching) memory, but if I wanted a quick-n-dirty solution, I'd probably use Cheat Engine.

@ShinobiUltra OpenVPN (in its most common mode) performs its key exchange over TLS.

You could always use a deterministic algorithm, like a KDF, to determine the nonce. It doesn't matter that it's random, just that it never collides. Especially if you're working with small data, you could run the data itself through a KDF (HKDF is my favorite) to get the number of bytes you need in a deterministic way.