Post #2553659

2025-11-11 15:54 UTC

@esoterra@hachyderm.io @yosh@toot.yosh.is The catch is, for secure random numbers, you never want to use a static seed, outside of offline debugging, because that would make the data predictable, voiding the security guarantee. Ideally, deterministic environments should just never run programs that depend on secure random numbers. That puts a lot of weight on applications' ability to distinguish between secure and insecure random number APIs, and I don't know if it'll hold. But something has to give, somewhere.

Replies (3)

@migratory@jorts.horse 2025-11-11 16:38

@sunfish@hachyderm.io @esoterra@hachyderm.io @yosh@toot.yosh.is to not empower software producers over software consumers, it is often necessary to void security guarantees. e.g., DRM leverages "security" infrastructure to unethically enforce monopolies with no regards to the user's actual legal rights the most important thing is for users to know and control which external inputs, including cryptographic entropy, a program will be able to access

Open ##2553660
@esoterra@hachyderm.io 2025-11-11 17:02

@sunfish@hachyderm.io to pick a specific use case, how about reproducible builds? you shouldn't need to do any cryptography that requires secure random numbers. e.g. you might verify signatures, but not generate keys you might need random number generators for certain algorithms though and those will need to be portably reproducible. I guess you could always embed the PRNG and seed within the component for those though.

Open ##2553664
@josh@social.joshtriplett.org 2025-11-11 17:39

Counterexample: what if you want to run a game with a replayable RNG so that you get deterministic replays? I think we need two separate RNGs: "replayable" (can be seeded) and "secure" (cannot be seeded). Crypto should use the latter, game RNGs and similar should use the former.

Open ##2553667