Encryption of opening key on CLI/API usage
marcoonroad opened this issue · 0 comments
The CLI executable would write & read the plain opening key on disk. This is an undesirable security issue. Therefore, I should reuse the internals regarding KDF and AEAD to store this opening key encrypted. We can use an $NOCOINER_PASSWORD
environment variable as the end-user input password for our KDF-then-Encrypt-then-MAC for the random opening key. We can too validate this end-user password against minimal security requirements for strong passwords even with a KDF applied (the number of cycles of KDF vs. the strength/entropy of end-user password is a tradeoff to match).
It's desirable as well to expose this encryption/decryption of opening under an API interface for development & integration from developers/maintainers. This should be optional due possible internal requirements from corporations regarding encryption/storage of keys (in the case, the opening key). The interface could be something like:
module OpeningEncryption : sig
type opening = string
val encrypt : password:string -> opening -> string
val decrypt : password:string -> string -> opening
end
Issue open for more discussions.