Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe. ...
Even a quiet server seeds its generator before it needs it, so the randomness failures that still happen are not shortages. They are replays: a seed baked into an image, a snapshot resumed, a state restored from before the last reseed. The kernel does not drip entropy at you; it concentrates a little device noise into a generator, then produces keystream indefinitely. ...
You do not choose a hash for the database; you choose it for the attacker who reads the database. Dedicated password hashes trade speed for resilience so a leak does not become a password factory. Fast is the wrong goal Speed is the enemy here. General-purpose hashes like SHA or MD5 run in nanoseconds and are intentionally fast, which is exactly what an offline attacker wants — they can churn through billions of guesses per second. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so each guess costs real work (say 100ms-1s) and each account produces a different result even with a shared password. The slowness is the feature; it is what converts an instantly-downloadable hash file into a long, expensive grind. Choose an algorithm that is memory-hard where feasible, and pick a cost that stays high yet tolerable on the hardware that has to verify every login. ...