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

Support for custom IV #315

Closed
guitmz opened this issue Mar 29, 2018 · 5 comments
Closed

Support for custom IV #315

guitmz opened this issue Mar 29, 2018 · 5 comments

Comments

@guitmz
Copy link

guitmz commented Mar 29, 2018

While I know that this is debatable, I have some scenarios where I would not like the file to physically change every time I encrypt it.

As example, if I run sops -e myfile twice, the output is not the same and I would like to have it to be the same.

The use case for this is something similar as git-crypt, where the encryption is deterministic (which is required so git can distinguish when a file has and hasn't changed).

Thanks

@jvehent
Copy link
Contributor

jvehent commented Mar 29, 2018

I don't think we want to allow nonce reuse. It's a bad security practice and, in some cases, can be a major security vulnerability.

@jvehent
Copy link
Contributor

jvehent commented Mar 29, 2018

The bigger question is why do you reencrypt the file every time with the same values? sops will only change the values that have been changed during your last edit, and indeed will use a new nonce then but only for those specific values, not for the entire file.

@guitmz
Copy link
Author

guitmz commented Mar 29, 2018

@jvehent what I mean is if I run

$ sops -p MY_KEY -e secret.yaml > file_1

and

$ sops -p MY_KEY -e secret.yaml > file_2

and then

$ diff -q file_1 file_2 Files abc and def differ

The differences are present not only on metadata keys (like lastmodified) but also on other keys that were part of the original file and were not changed between running the two encrypt commands.

The sole propose of this request for me at the moment is achieve transparent git encryption.

Having the IV to be a hash of the original file for example would be unique per file (since the hash of the file pushed to VCS is different because this file will be encrypted), but I do agree with your statement about this being a bad practice.

@jvehent
Copy link
Contributor

jvehent commented Mar 29, 2018

this does not work with gpg either, fwiw

$ echo foo > bar
$ cp bar baz
$ gpg -e bar
$ gpg -e baz
$ sha256sum bar.gpg baz.gpg 
df9a2e827d5d6946d40c1c7b25c7bdbfa8f78102f259ebff2b7351d48247b73f  bar.gpg
b0aa36688bd193aa70cefe7019ee4e368390ea7370269dfb0a85eb358c96fc00  baz.gpg

the reason for this is encryption tools generate random data encryption keys for each file, and then encrypt the data key with the private key (for pgp) or kms (for sops kms). Running sops twice with create 2 different data keys that will result in two different files, regardless of what the IV values are.

You should modify your secret.yaml file using sops as an editor instead of recreating the file every time from scratch.

$ sops -p MY_KEY -e secret.yaml > encrypted.yaml
$ git add encrypted.yaml, etc...

then when you want to modify encrypted.yaml, do

$ sops encrypted.yaml

make changes and git commit, it will show the right diff

@elopsod
Copy link

elopsod commented Jul 12, 2024

Hi @jvehent

make changes and git commit, it will show the right diff

Could you pls suggest how to do this automatically
I mean how make changes without decrypt/encrypt all file
Thank you!

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

No branches or pull requests

3 participants