File encryption/decryption with vault

[Praveen Kumar Pasupuleti]

Hi All:

I learnt using vault transit, we can encrypt and decrypt for the base 64 encoded strings. If I want to encrypt or decrypt a file , what are the possible options we have with vault. 

Thank you for you help!

Regards,

-Praveen

[Jeff Mitchell]

Hi Praveen,

Simply encode your file's contents as base64 and pass through transit.
Then when you decrypt the result, decode the base64 value and you have
your file back!

Best,
Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/fea0e88a-1d3d-4244-ae9c-1b3fc3598387%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Gordon Cassie]

Hi Jeff,

I believe in another thread it was mentioned that transit is not really optimized for file encryption.  Would this work with any size file? I assume performance would not be sufficient to stream decrypted files back to a client (for example in a file server type application)?

Cheers,

Gordon

[Jeff Mitchell]

On Thu, Apr 28, 2016 at 1:24 PM, Gordon Cassie <gordon...@gmail.com> wrote:
> I believe in another thread it was mentioned that transit is not really
> optimized for file encryption. Would this work with any size file? I assume
> performance would not be sufficient to stream decrypted files back to a
> client (for example in a file server type application)?

It's not optimized in the sense that you're round-tripping entire
files over the network. The AES encryption speed is pretty good,
especially with Go 1.6+ (in Vault 0.5.1+), but encoding many large
files just means a lot of data being sent back and forth. Also,
streaming isn't supported, unless you implement it yourself -- each
call is a discrete block of data to be encrypted or unencrypted.

Generally when people want to encrypt lots of large files we recommend
the datakey approach -- have transit generate a datakey wrapped by a
transit key. You can store the encrypted copy of the datakey with your
data and unwrap it with a single call to transit as needed, then using
the unwrapped key to perform encryption/decryption locally, without
persisting the unwrapped key to disk.

Best,
Jeff

[Gordon Cassie]

Ok great - that matches my understanding. I just spent the last couple weeks

implementing exactly what you describe so was a bit worried when I read your

initial response.

I hate to hijack the thread but I do have another question.  What would be the best 

approach for encrypting certain text fields in a database?  In this case if you have

200 rows in a DB table, there would be 200 encrypted strings. Transit does not appear to

have any bulk decrypt feature where you could send 200 encrypted strings and get

200 decryptions back in one transaction. My instinct is to use a similar approach as to

files and store an encrypted datakey, use transit to decrypt the key, then in the application

layer I can decrypt 200 strings at once and server the response.  Does that make sense?

Cheers,

Gordon

[Jeff Mitchell]

Sure, that makes sense. I think it might be a neat addition to allow
bulk encrypt/decrypt operations in the future, so feel free to file an
issue against it -- I don't think I could get to it real soon, but it
wouldn't be super hard for someone else that's motivated to implement.

In the mean time, a datakey works fine. Another option would be to use
an HTTP client that supports reusing connections -- many already do,
but transit itself is really quite fast, so when you can pipeline a
bunch of transit requests down the same TLS connection it's pretty
speedy.

--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/vault-tool/28667b56-eb3f-46be-b7ba-8400af7e34da%40googlegroups.com.

[Gordon Cassie]

Ok, I will take a look at feasibility of a PR for bulk operations in transit once I am looking at the DB issue in more detail.  Thanks for all the help.

[Jeff Mitchell]

On Thu, Apr 28, 2016 at 3:46 PM, Gordon Cassie <gordon...@gmail.com> wrote:
> Ok, I will take a look at feasibility of a PR for bulk operations in transit
> once I am looking at the DB issue in more detail. Thanks for all the help.

Cool. FYI a PR should land with some major refactoring to transit in
the next few days so maybe wait until after then :-)

--Jeff