Open stouset opened 7 years ago
@stouset Sounds like a good idea. One thing that we'll definitely need is a way that automatically converts the encrypted file from the bf-cbc algorithm to aes-128-gcm. We'd be happy to see a pull request 😄 .
For a similar tool, but with a more conventional symmetric encryption algorithm, please check out a gem called sym
. It offers AES-256-CBC
cipher with random iv
for the data encryption, and can optionally use AES-128-CBC
for encrypting the 256-bit encryption key with an arbitrary password.
While sym
does not have as simple of a Rails integration as this gem does, it has a couple of neat features such as the ability to use OS-X Keychain to store the key locally on a Mac, as well as time-sensitive password caching for keys that are password-protected.
On the implementation side — when the data is encrypted, sym
uses light-weight serialization around the encrypted data, which includes the serialization format version. This thin wrapper allows adding arbitrary metadata to the encrypted files, supporting various extensions and additional cipher types in the future.
I wrote sym
(sorry for the shameless plug) after spending several days of painstakingly looking for a gem like sekrets
or sym
and — obviously — not finding it :)
But it is my hope that it is the community that ultimately benefits from having multiple solutions, with slightly different set of features, even if the overall intention can sometimes be similar.
@stouset and @copiousfreetime see -> https://github.com/ahoward/sekrets/issues/18
i am working on this.
general idea is having a yaml formatted keyfile with the cipher and other metadata inside it. this will allow automatic key/cipher detection moving forward which should allow the gem to easily migrate people forward. my question to you both is:
what do you think is the the preferred setup wrt to keysize/cicpher, etc?
i am not a fan of system dependent preferences because debugging nightmare not to mention having different behavior in, for eg, production vs dev vs ci envs but..... love to hear more.
The cryptography behind this gem is far behind standards considered minimally acceptable for modern systems.
Far better would AES-128-GCM with a random IV. Best would be ChaCha20-Poly1305 on systems that support it. I am happy to provide a pull request if you are not opposed to merging it.