marcoonroad/nocoiner

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.