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

Add option to set encryption key for storage #1539

Open
wburningham opened this issue Feb 10, 2020 · 6 comments · May be fixed by #1542
Open

Add option to set encryption key for storage #1539

wburningham opened this issue Feb 10, 2020 · 6 comments · May be fixed by #1542

Comments

@wburningham
Copy link

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I have two use cases where data needs to be:

  1. "encrypted at rest" (for file storage backend)
  2. "encrypted in the runtime/process" even though TLS encrypts HTTP traffic and even though some storage providers may provide encryption at rest (ex Amazon's S3), storage providers still have my plaintext data in their servers and I just trusting providers is not a sufficient level of security

Describe the solution you'd like
Provide an ATHENS_STORAGE_ENCRYPTION_KEY option that if set will wrap a storage.Backend and handle encrypting and decrypting of data.

Describe alternatives you've considered
Write an encryption backend pkg that wraps storage.Backend and created my own proxy app that uses most of the gomods/athens/pkg/* internals. I've done this, but I think writing a PR back to gomods/athens with the encryption would be a better solution.

@arschles
Copy link
Member

@wburningham for the 2nd requirement, could Athens encrypt before sending to S3 and decrypt in-memory after receiving data?

Also, do you have code that you can share from your own proxy app? We can use that and work together to submit a PR back to Athens if you'd like

@wburningham
Copy link
Author

The code that I had from my own app was already in it's own package so I just submitted a PR with what it could look like.

@marwan-at-work
Copy link
Contributor

marwan-at-work commented Feb 11, 2020

I think this is a perfect use case for #1353

Maybe it's worth revisiting so that we don't inflate our backend implementations.

Admittedly, encrypting/decrypting modules within the Athens codebase sounds pretty damn cool ;)

But I worry about the following:

If we were to claim Athens has encryption within its codebase, then people will trust it and cryptographers will put it under scrutiny.

None of the maintainers (AFAIK), are cryptography experts to maintain and develop proper encryption. Therefore, we would need a cryptography champion who is actively developing and maintaining this backend implementation if we are to have Athens claim e2e support :)

@arschles
Copy link
Member

arschles commented Feb 15, 2020

I think this is a perfect use case for #1353

As it happens, I was just commenting on an unrelated issue (#1511 (comment)) where the author could use something like #1353. Maybe it's time 😄

If we do any of this encryption work, I'm all for putting a big disclaimer that we're not experts, until we get someone to audit and/or champion the implementation. Would you be ok with that @marwan-at-work ?

@marwan-at-work
Copy link
Contributor

@arschles ideally I'd go for 1353 first, it would also help keep the Athens code base smaller and easier to maintainer since we already have a big number of implementations. I definitely don't wanna block anyone tho in case this is absolutely needed 👍

@arschles
Copy link
Member

Agreed on #1353. Looks like that PR hasn't had any activity for a while, so I'm gonna open a new draft with a simple implementation and we can start there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants