Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Encryption at rest #61

Open
itsezc opened this issue Jul 25, 2024 · 0 comments
Open

Feature: Encryption at rest #61

itsezc opened this issue Jul 25, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@itsezc
Copy link

itsezc commented Jul 25, 2024

There is little to no documentation of how SurrealKV handles encryption at rest. This is a very important security factor for choosing SurrealKV (and by extension SurrealDB) over competitors such as Foundation DB, TikV, Postgres etc.

I've previously raised an issue on the surrealdb repository about using Kyber for Encryption on rest / storage, this hasn't received any major feedback; as SurrealKV was still in development at that time.

In many cases, there are many considerations to take with regards to Encryption at rest:

  • Storage medium level (Hardware / VMs / Container): there are many cases where this is not possible, especially in the Cloud vendor scene as not all offer them or reliable
  • At file / folder level: This is what is suggested by the scope of this issue, encrypting all the necessary files used by SurrealKV

Additional considerations to take into mind would be choosing the appropriate algorithm that is both performant and secure enough for a "post-quantum" world.

Related:

With all this in mind, heres a few suggested solutions:

  • Preferred: XChaCha / XChaCha20-Blake3
  • Preferred: Kyber 512 / 1024: https://pq-crystals.org/kyber/ (Although storage encryption is not feasible to the best of my knowledge)
  • AES 256 Bit (Traditional option)

These offer decent levels of safety against quantum attacks, and notable choices are for the following reasons:

ChaCha20 has a higher security margin than AES, performs well on older devices, and runs in constant time, unlike AES.

BLAKE3 is fast and evolved from BLAKE, which received a significant amount of cryptanalysis, even more than Keccak (the SHA3 finalist), as part of the SHA3 competition.

@arriqaaq arriqaaq added the enhancement New feature or request label Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants