20 ms·
The fact that something was fixed doesn't make it a security vulnerability, the "security vulnerability" here is equivalent to a command line tool not accepting
by dodomodo 1y ago
The fact that something was fixed doesn't make it a security vulnerability, the "security vulnerability" here is equivalent to a command line tool not accepting weak passwords, defenetly something worth having, but not a vulnerability.
- Eikon 1y agoThis is not true, 1. Operator correctly runs: cat /dev/urandom > seed.bin 2. Filesystem corruption fills seed with nulls/spaces (happens in production) 3. Sunlight silently generates predictable keys from corrupted seed 4. CT log operates "normally" - valid signatures, no errors 5. Anyone knowing about corruption can recreate the private keys What other "end-user" crypto-related app runs with a user-produced seed to generate key pairs on the fly?
- dodomodo 1y agothis is out of scope for the project, it is insane to expect every software project to deal with random file system corruptions. if this kind of thing was considered a security vulnerability we would have 100x the vulnerabilities we have now.
- Eikon 1y agoThere's a distinction between "Corrupted seed" and corrupted PK / password. The seed is provided without validation or checksuming, generating perfectly valid keys on the fly from unknown entropy quality. If you have bad entropy (partially or fully corrupted/weak seed), you'll generate valid-looking keys that are actually insecure. There's a reason there's not a single "end-user" crypto-related app / cli tool or server that takes a user-specified arbitrary seed as input. That's dangerous, broken design. Why would you even do that?