Support modern encryption

Issues
, , ,
1

Moved from GitHub badger/1194

Posted by skerkour:

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 (Latacora - Cryptographic Right Answers) it’s far better than AES for multiple reasons, the number one being it’s simplicity.

2

jarifibrahim commented :

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
tls - What's the appeal of using ChaCha20 instead of AES? - Cryptography Stack Exchange 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?

3

skerkour commented :

The two principal reasons are what you mentioned:

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
}
4

elagergren-spideroak commented :

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.

5

skerkour commented :

It can be a solution also.

One more reason to allow other ciphers:
→ Uncovering the CIA's Crypto AG operation | Hacker News

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.

6

jarifibrahim commented :

This was accidentally closed. Reopening.

7

What is the status of this feature request? In view of post quantum cryptography AES512 is also a requirement.