Hacker News Reader

Comment by dodomodo | Hacker News Reader

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.

View on HN

This 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?

this 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.

There'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?

Reply on news.ycombinator.com