That's the ticket though: I suspect the entropy is really bad. This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba

That's the ticket though: I suspect the entropy is really bad. This is how encryption_key gets invoked: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L110-L115 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... This is where the entropy is sourced from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L160-L172 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... The global secret comes from: https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime.rb#L53 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... self.key comes from gibbler.base(36): https://github.com/onetimesecret/onetimesecret/blob/8ba0511e74b64280003691251dd99b04915d42ea/lib/onetime/models/secret.rb#L11 https://github.com/onetimesecret/onetimesecret/blob/8ba0511e... At no point is anything touching /dev/urandom, which is how cryptography keys should be generated. (Additionally, HKDF-SHA-256 should be used for splitting a master key into multiple sub-keys.) I don't know if I want to file an issue for this on Github or not. Usually when the crypto is this bad, there's a lot of cargo-culting and I don't have the emotional bandwidth to deal with a vim-crypt style debate.