Is it secure to store a copy of an encrypted file with omitted secrets alongside the encrypted file?

[kharf]

I didn't know how to phrase the question, but maybe an example clarifies what I am asking.
If I have a file with partially secret content in it, like:

apiVersion: v1
kind: Secret
metadata:
  name: example
data:
  foo: secret

and I use age to encrypt the whole file, but I keep a copy of that file and replace "secret" with a dummy value and store both the encrypted content and the copy of the original version with dummy values together in a git repository; how secure would that be?

I know sops uses age to encrypt an AES key, which is used to encrypt secrets, if I am not mistaken. That made me wonder if this is because of security or QoL, like easier key rotation?

I hope that I don't embarrass myself with that question.
Anyway thank you for your answers in advance!

[cipriancraciun]

And I use age to encrypt the whole file, but I keep a copy of that file and replace "secret" with a dummy value and store both the encrypted content and the copy of the original version with dummy values together in a git repository; how secure would that be?

Storing the encrypted version of the secret file in Git is not a big issue, as long as you can keep your encryption key / password safe. Else, if the encryption material (key / password) is compromised, the attacker can extract the encrypted configuration file from any clone of your Git repository (assuming the Git repository is public) and decrypt it, thus leaking your secret.

Thus, if your "secret" is something that can't be easily rotated, perhaps you shouldn't persist it long term anywhere where the attacker might extract it (like Git, backups, etc.). (When speaking about "rotation", I don't mean rotating the underlying encryption key (i.e. AES key) like in your SOPS example, but the actual "secret" your application uses.)

However, storing also the unencrypted file with a dummy secret, I believe it to be very problematic: if during development (or when using the Git repository) you replace the dummy secret with the actual secret, then Git will always show that file as modified, and you are one typo away from committing that file to the repository.

---

A somewhat safer alternative would be this:

• add your unencrypted configuration file to .gitignore;
• create a "safe folder" somewhere on your disk, in a safe place, excluded from backups; (perhaps have it mounted as a tmpfs if you are on Linux, or even better ramfs to be sure it doesn't leak to swap;)
• place unencrypted configuration files in that "safe folder"; (thus you could use it for more than one project;)
• symlink the configuration file from the "safe folder" to the Git worktree;

This way, even if you by mistake commit to Git the unencrypted configuration file, it's actually a symlink, thus of no value for anyone, leaking only the path of your "safe folder".

---

Note that a few months ago, someone opened a discussion thread about a project, based on Age, that targets exactly the problem you are talking about: #543

However, please also see some of the discussion threads I've opened in that project:

• About managing multiple recipients glehmann/yage#3
• About signatures for individual tokens glehmann/yage#4

[kharf]

thanks for the long and detailed reply!
I have been reading through yage, but it seems there is a slight difference to what I am doing. Yage encrypts the secret values, while I am encrypting the whole file and only omitting the secret values. I wonder if there is difference in terms of security for both approaches.

[cipriancraciun]

In your particular case, because you are also committing into the repository the configuration file with dummy values, there is practically no difference. (In your case there are dummy values, in case of yage / SOPS there are encrypted tokens.)

If you were not to include in the repository the configuration file with dummy values, you get a bit of extra security through obscurity, because the attacker wouldn't know what you have decided to include in the configuration file. (Like for example which email service you use, etc.)

However, as said that is only "obscurity", because the attacker could just look at the source code, and see exactly which keys are actually read.

[kharf]

true. Thank you for the clarification!