Hi there! Having a lazy Boxing Day and thought I'd take a whack at this. I'll put a PR shortly; my code might be naive because this is in no way my specialty, but the unit test does work at least.

See #2518 for historical discussion.

For stream keys, there's one extra option: store the key both hashed and encrypted. The protocol can't use the encrypted key since that requires giving the server the cipher in plaintext. The admin can't use the hash since that's irreversible.

The encrypting password can be stored as a hash. Any decryption. modification or addition of keys would require comparing the user provided password against it to verify before the encrypting/decrypting. The RTMP check can just work off the hash of the stream key since that doesn't need the original value. Forcing a user-provided value to interact also allows the possibility to re-encrypt the keys without losing them. Losing the encrypting password still means losing access to the stream keys, in which case using the admin password could make sense. Since it would be necessarily impossible to view the stream keys without knowing at least that. Resetting the admin pass via the CLI would still break it.

This would take the most work, and would also cause problems with SRT parity if that gets pursued. I also have no idea what the implications of this are security-wise.