Suggested process when encrypting large files

[Jon Marks]

Hello all.

Is there a suggested process (API calls) when using Vault to encrypt/decrypt large files?

I'd rather not use the /transit/encrypt //transit/decrypt endpoints as there could be hundreds of files.

All suggestions appreciated

Regards.

[Jeff Mitchell]

Hi Jon,

The recommended approach is to create an AES key, encrypt it with
transit, and then have hosts decrypt that key and use it locally for
encryption (but without ever storing the unencrypted key on disk). The
first two items (creating/encrypting) have a utility path in the
transit backend (the "datakey" path).

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/a12d8bef-db76-4405-a631-7d81e9920494%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Joel Thompson]

Just a thought....

Rule #1 of doing crypto is: "Don't write your own crypto." That's one of the reasons why tools such as Vault are so valuable -- they prevent individuals from having to write their own crypto. And so, that's why the answer below is a bit unsatisfying to me, because it forces end users to write their own crypto. While Vault can provide things such as protection of the data key or authentication of the key, it won't protect against easy-to-make mistakes such as re-using a nonce with the same key in AES GCM mode, or not comparing HMACs in constant time, which can substantially weaken the protections encryption offers

So, with that in mind, what about building that functionality into the Vault CLI? It would talk to a Vault server to generate the data key and do the encryption. It would talk to Vault to authenticate the ciphertext passed in, decrypt the data key, and then decrypt the data.

Thoughts? (A quick search of the issues on GH didn't indicate anything.)

--Joel

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GHNbtGOxmKH9J4ktdV7p5PELtUVwg-dAeg86J7tutVwNg%40mail.gmail.com.

[Jeff Mitchell]

On Mon, Jan 16, 2017 at 10:37 PM, Joel Thompson <jatho...@gmail.com> wrote:
> Just a thought....
>
> Rule #1 of doing crypto is: "Don't write your own crypto." That's one of the
> reasons why tools such as Vault are so valuable -- they prevent individuals
> from having to write their own crypto. And so, that's why the answer below
> is a bit unsatisfying to me, because it forces end users to write their own
> crypto.

There's a very, very large difference between "provide a
Vault-protected key to a well-tested library" and "write your own
crypto".

> While Vault can provide things such as protection of the data key or
> authentication of the key, it won't protect against easy-to-make mistakes
> such as re-using a nonce with the same key in AES GCM mode, or not comparing
> HMACs in constant time, which can substantially weaken the protections
> encryption offers

But libraries can and do.

> So, with that in mind, what about building that functionality into the Vault
> CLI? It would talk to a Vault server to generate the data key and do the
> encryption. It would talk to Vault to authenticate the ciphertext passed in,
> decrypt the data key, and then decrypt the data.

I don't expect this will land in Vault's CLI anytime soon, but it
seems like really good functionality for an easy third-party utility.

Best,
Jeff