encrypted cloud backups

[tcurdt]

I am looking for a good way to encrypt backups for cloud storage.
Since I don't want to do anything stupid, I thought I better ask.

First things first:

Is age OK for large files? or is there something to else to consider?

The most simple usage would be:

age-keygen -o key.txt

private: in key.txt
public: age14n8ts9gzqtuyqa44qpel44euprsctclfm79zaa94w3u58sfh3pxqdx42v8

# encrypt
cat data | age -r age14n8ts9gzqtuyqa44qpel44euprsctclfm79zaa94w3u58sfh3pxqdx42v8 > data.age
cp data.age to cloud

# decrypt
cp data.age from cloud
age --decrypt -i key.txt data.age > data

IIUC one would have to know the public key and the recipient to make a data replacement attack.
And if the persons knows both the public key and the recipient there really isn't a way to make it any safer anyhow.

Are these correct assumptions?

Or would be better to add some kind of manual sender authentication?

This discussion seems related #463

[cipriancraciun]

First of all, depending on the type of backup you require, perhaps age isn't the best tool for the job. I (personally) would strongly recommend restic for this purpose.

Moreover, Filippo (the author of age) has sometime ago (circa 2017) investigated restic for his own purposes:
=> https://words.filippo.io/restic-cryptography/

He began his article with:

tl;dr: this is not an audit and I take no responsibility for your backups, but I had a quick look at the crypto and I think I'm going to use restic for my personal backups.

And his conclusion was:

The design might not be perfect, but it's good. Encryption is a first-class feature, the implementation looks sane and I guess the deduplication trade-off is worth it.
So... I'm going to use restic for my personal backups.

---

With regard to your concern:

IIUC one would have to know the public key and the recipient to make a data replacement attack.
And if the persons knows both the public key and the recipient there really isn't a way to make it any safer anyhow.

According to the age specification:
=> https://github.com/C2SP/C2SP/blob/main/age.md

The textual file header wraps the file key for one or more recipients, so that it can be unwrapped by one of the corresponding identities. It starts with a version line, followed by one or more recipient stanzas, and ends with a MAC.

Thus in your comments the public key and the recipient are in fact one and the same, namely the public key of the recipient. Which, in your backup case, is actually the public key of yourself (as the recipient).

Thus, any attacker that can read your backups (in encrypted form) can replace them with whatever they choose, because they already have access to your public key.

---

If you are interested more in the subject, I would recommend reading the following article from Filippo, tackling exactly the issue you are describing:
=> https://words.filippo.io/dispatches/age-authentication/

Citing:

In short, while no one can modify an encrypted age file, anyone can replace it with a completely new encrypted file. (This is not actually strictly true, as we'll see later, but it's what age says on the tin to be conservative.)

He then follows with the following statement:

This means that if you need to make sure an attacker can't forge age encrypted files for you, you just need to keep the recipient string (age1...) secret from the attacker. For example, if you upload backups to cloud storage, simply make sure you don't upload the recipient string along with them.

To my knowledge, currently age doesn't implement this use-case.

[tcurdt]

Much appreciate the answer.

While restic certainly is an option. I am also aware of some drawbacks.
It can be quite memory hungry, slow at times and IIUC it "only" allows for symmetric encryption. It does not support append-only backups, cannot be used with S3 Object Locking (AFAIK) and the term "corrupted" is not unheard of in the issues.

An encrypted archive has a hint of simplicity. I like KISS.

And why I am asking is the idea here is that the backup server can encrypt the backup, but not decrypt it (without me providing the private key).

Thus, any attacker that can read your backups (in encrypted form) can replace them with whatever they choose, because they already have access to your public key.

Uh, that I didn't expect. Because the quote...

This means that if you need to make sure an attacker can't forge age encrypted files for you, you just need to keep the recipient string (age1...) secret from the attacker. For example, if you upload backups to cloud storage, simply make sure you don't upload the recipient string along with them.

...seems to suggest differently.

If the public key is extractable from the age file that sentence would not make much sense (to me). Or what am I missing?

[tcurdt]

Oh, it seems like Object Lock might be supported now. I have to retract that limitation. restic/restic#2202

[cipriancraciun]

Uh, that I didn't expect. Because the quote...

This means that if you need to make sure an attacker can't forge age encrypted files for you, you just need to keep the recipient string (age1...) secret from the attacker. For example, if you upload backups to cloud storage, simply make sure you don't upload the recipient string along with them.

...seems to suggest differently.

If the public key is extractable from the age file that sentence would not make much sense (to me). Or what am I missing?

Please note that the second article I've pointed out from Filippo (the one you've cited from) is more "theoretical" than describing what age actually does.

Indeed, if you patch a variant of age that doesn't also write the public key (in the encrypted file header), then you get the suggested behavior. But as said, to my knowledge, at the moment age doesn't behave like that, and instead always writes the public key in the header. If I remember correctly from Filippo's article, he suggested some kind of "plugin" that would implement this idea.

---

However, even if from a cryptographic point of view "it might work" (because, in Filippo's words, such a construct is not standard and hasn't been analyzed much), your threat model changes as follows:

• not only do you have to keep the private key secret (for decryption), you now have to also keep the corresponding public key secret (for encryption); (thus the amount of cryptographic material doubles, and can't be easily remembered;) (granted, you can just keep secret the secret key, and derive the public key from that, but then why bother with with private/public key?)
• because you need to keep the public key secret, each time you want to create a backup, you need to handle that public key with care as not to leak it; however, most software isn't designed with care for public keys (which as the name states are expected to be public), as opposed to handling actual "secrets" (i.e. passwords);

Thus, given all of these, why not settle for an actual "password" / "passphrase"?

---

Finally, if you insist going the "experimental" route, I could point you to my own project z-tokens, that allows both encryption (to a recipient) and authentication (by the sender), among other things. If you are interested, just open a discussion thread in that project.

[tcurdt]

the ... article .... I've pointed out from Filippo is more "theoretical" than describing what age actually does.

I might have not read thoroughly enough then. Thanks for pointing that out.

Thus, given all of these, why not settle for an actual "password" / "passphrase"?

That I already mentioned:

"the idea here is that the backup server can encrypt the backup, but not decrypt it (without me providing the private key)."

I guess the options I see:

• not use age but gpg instead
• also sign the age file (e.g. with openssl)

Neither options are fantastic - but should work I guess.

I could point you to my own project z-tokens, that allows both encryption (to a recipient) and authentication (by the sender), among other things

Nice!