
BadgerDB Implemented AES Encryption - mrjn
https://blog.dgraph.io/post/encryption-at-rest-dgraph-badger/
======
sneak
> _A user provided AES encryption key, called the master key, is used to
> encrypt auto-generated data keys. Data keys are used to encrypt and decrypt
> data on disk. Each encrypted data key is stored on disk along with the
> encrypted data. The length of your master key must be 16, 24 or 32
> characters. This determines what version of AES encryption is used (AES-128,
> AES-192, and AES-256 respectively)._

It will be difficult for me to trust a crypto implementation written by people
who don’t seem to know what a PBKDF is.

~~~
mrjn
(author of Badger) Keeping things simple. If you can break it (decrypt data
without knowing the master key), we'll be happy to pay you a bounty. We can
extend it from data loss to also include "breaking encryption."

[https://github.com/dgraph-io/badger/issues/601](https://github.com/dgraph-
io/badger/issues/601)

~~~
sneak
> _Note that you should never use a predictable string as your master key. If
> you have a password manager (such as 1Password, LastPass, etc.), you can use
> its built-in password generator to generate a strong encryption key._

Reducing the keyspace to only ASCII/printable is a pretty big deal, although
judging by the article and not the code, I doubt brute force is the way to
break your system.

The method you are employing (cracking contests) is another thing that
projects commonly do that makes people trust their implementations less.

Inventing a cryptosystem is a pretty big task. I haven’t looked at your code.
How are you sure that you got it reasonably right?

Furthermore, why do you believe it’s better to do this in the application
than, say, with LUKS?

