Support modern encryption

[sylvain101010]

What version of Go are you using (go version)?

$ go version
go1.13.5

What version of Badger are you using?

2.0.1

Does this issue reproduce with the latest master?

yes

What do you expect to see?

Hi, we are evaluating to migrate from embedded SQLCipher to Badger. As I understand Badger can enable AES encryption using Options.EncrpytionKey.

Is it envisaged to add modern encryption algorithms as an option, like XChaCha20Poly1305?

According to cryptographers (https://latacora.singles/2018/04/03/cryptographic-right-answers.html) it's far better than AES for multiple reasons, the number one being it's simplicity.

[jarifibrahim]

Hey @z0mbie42

According to cryptographers (https://latacora.singles/2018/04/03/cryptographic-right-answers.html) it's far better than AES for multiple reasons, the number one being it's simplicity.

I couldn't find any valid argument for using XChaCha20Poly1305 against AES . Can you please point me to some other references?

A quick google search landed me on
https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes and what I understand is

• Chacha20 would be faster on CPU which does not have dedicated AES Instruction
• Chach20 is easier to implement than AES

(there were other points that I don't think are relevant to this discussion)

Most of the modern CPUs have the AES instruction so point 1 isn't of much relevance.

Adding support for encryption algorithms would be breaking change for badger. Do you have a strong reason to not use AES?

[sylvain101010]

The two principal reasons are what you mentioned:

• use in mobile/low end SBCs (like raspberry pi) which does not have aes ni, Google also switched to XChaCha20-Poly1305 for disk encryption (https://github.com/google/adiantum)
• I feel really better using XChaCha20-Poly1305 rather than AES, because it's a lot simpler to understand and it is a modern AEAD cipher: it supports both encryption and authentication, which allow detection of corrupted data (https://github.com/google/tink/blob/master/docs/PRIMITIVES.md)

Regarding the last point, I'm not sure if there is other mechanisms in place in badger, but AEAD encryption 'gives for free' the detection of corrupted data.

Regarding the breaking change, can't it be added simply by an Options ? Like Options.EncryptionCipher and an Enum

const(
     CipherXChaCha20Poly1305 = iota
     AESCTR
}

[elagergren-spideroak]

Instead of baking in encryption, please provide an API so that users can supply their own cryptographic primitives. There are business reasons why a particular encryption package might be used instead of the stdlib's crypto.

[sylvain101010]

It can be a solution also.

One more reason to allow other ciphers:
-> https://news.ycombinator.com/item?id=22500231

Hardware can be backdoored to produce faulty cryptography (The recent story of CryptoAG prove it) thus pure software crypto (like XChCha20-Poly1305) is safer and more auditable.

[jarifibrahim]

This was accidentally closed. Reopening.