4 ms·

I'm still waiting for backup tool that uses asymmetric encryption (data encrypted using public key, decrypted using private key) and having write-only server mo

I'm still waiting for backup tool that uses asymmetric encryption (data encrypted using public key, decrypted using private key) and having write-only server mode (so bad actor can't remove backups)

dividuum 5y ago
The append-only mode can be implemented using https://github.com/restic/rest-server https://github.com/restic/rest-server or services like rsync.net that offer read-only zfs snapshots. Doesn’t solve the asymmetric crypto of course.
k8sToGo 5y ago
Incremental and differential backups aren't possible that way. Also Borg has an append only mode.
- lucb1e 5y ago
  Why would that not be possible? Especially since you say borg can do it, and borg is said to be incremental and deduplicated? Note that write-only or append-only is a bit of a misnomer, since reading the files is fine (you need the decryption key anyhow before they're of any use). It's about not being able to overwrite or remove backup data without some verification that you're not ransomware or similar.
- rssoconnor 5y ago
  Tarsnap provides incremental and differential backups with public key cryptography. So it must be possible.
- eps 5y ago
  Only if the backup side is unreadable (which is different from being append-only).
  - remram 5y ago
    I'm the GP's setup, it's not readable without the private key. You could do deduplication on the encrypted blocks I suppose (is that secure?)
tialaramex 5y ago
Hmm. If anybody can encrypt backups indistinguishably, and you want write-only so that bad guys can't remove stuff, surely you can incur unlimited costs as bad guys fill it with gibberish and you can't stop them?
- rssoconnor 5y ago
  You would run out of remote storage space quickly and then find out you have been compromised. But your backups that you made up to the point of being compromised are still in tact, which seems to be the best you can hope for.
- lucb1e 5y ago
  > incur unlimited costs as bad guys fill it with gibberish That's always an option, no matter if it's set to append-only or not. If you don't want to pay infinite costs for storage, you will need to limit it using software on the server.
  - tialaramex 5y ago
    The remote backup store can easily choose to only store things you actually encrypted, but this isn't possible for a simple public key setup. If you wanted to get fancy, you could use a sign + encrypt setup with separate keys so the store can tell if this is a real backup from you, and not allow things to get stored unless they've got such a signature, yet it still can't actually decrypt the backups it has been given. As a proof of concept, take a look at a Certificate Transparency log server. Most CT logs are configured to only accept certificates meeting certain criteria. They'll log any such certificates (their SLAs only apply to contractual users, but you don't need an SLA you're probably just writing one certificate to the log to see it works) but you cannot fill them with garbage because you can't make any certificates they'd accept, only the legitimate CAs can do that† † The CAs have their own reasons not to let you produce heaps of garbage, even Let's Encrypt has finite resources and so it imposes rate limits.
    - lucb1e 5y ago
      But if your box gets compromised, then whatever it was using to prove to the server that it's legit is also going to be available to the attacker. I guess you're thinking of a scenario where backups are not automated and the user either unerringly knows whether their box is compromised (and doesn't type in said proof when that happens) or uses some 2FA hardware device. Given the chance, there certainly will be people that use 2FA when making an append-only regular backup, but even among command line restic users I expect this will be the exception rather than the rule.
phone8675309 5y ago
At the risk of sounding like a shill, tarsnap does that and explicitly supports write-only keys[1] [1] https://www.tarsnap.com/tips.html#write-only-keys https://www.tarsnap.com/tips.html#write-only-keys
- lucb1e 5y ago
  Indeed, this is one of the major advantages of tarsnap, though a friend also mentioned borg can do this apparently. I should really look into borg (again).
- rssoconnor 5y ago
  I do use Tarsnap for this reason. That said, Tarsnap isn't free software, and doesn't come with the ability for me to self-host backups. Thus, I am somewhat at the mercy of Amazon. Still, the advantages of Tarsnap currently outweigh the disadvantages in my opinion.
- cperciva 5y ago
  At the risk of sounding like a shill For the record, this is not a shill. I don't even know who Jenny is.
gnufx 5y ago
http://duplicity.nongnu.org/ http://duplicity.nongnu.org/ at least can use PGP public keys. I've used it for a long time and not seen any particular reason to change.
sreitshamer 5y ago
(I make Arq, a backup app that supports S3's object-lock API for immutable backups). I can't see how to do incremental backups without using the private key to read the previous backup record. Can you explain how that would work?

I'm still waiting for backup tool that uses asymmetric encryption (data encrypted using public key, decrypted using private key) and having write-only server mode (so bad actor can't remove backups)

dividuum 5y ago

The append-only mode can be implemented using https://github.com/restic/rest-server https://github.com/restic/rest-server or services like rsync.net that offer read-only zfs snapshots. Doesn’t solve the asymmetric crypto of course.

k8sToGo 5y ago

Incremental and differential backups aren't possible that way. Also Borg has an append only mode.

lucb1e 5y ago
Why would that not be possible? Especially since you say borg can do it, and borg is said to be incremental and deduplicated? Note that write-only or append-only is a bit of a misnomer, since reading the files is fine (you need the decryption key anyhow before they're of any use). It's about not being able to overwrite or remove backup data without some verification that you're not ransomware or similar.
rssoconnor 5y ago
Tarsnap provides incremental and differential backups with public key cryptography. So it must be possible.
eps 5y ago
Only if the backup side is unreadable (which is different from being append-only).
- remram 5y ago
  I'm the GP's setup, it's not readable without the private key. You could do deduplication on the encrypted blocks I suppose (is that secure?)

tialaramex 5y ago

Hmm. If anybody can encrypt backups indistinguishably, and you want write-only so that bad guys can't remove stuff, surely you can incur unlimited costs as bad guys fill it with gibberish and you can't stop them?

rssoconnor 5y ago
You would run out of remote storage space quickly and then find out you have been compromised. But your backups that you made up to the point of being compromised are still in tact, which seems to be the best you can hope for.
lucb1e 5y ago
> incur unlimited costs as bad guys fill it with gibberish That's always an option, no matter if it's set to append-only or not. If you don't want to pay infinite costs for storage, you will need to limit it using software on the server.
- tialaramex 5y ago
  The remote backup store can easily choose to only store things you actually encrypted, but this isn't possible for a simple public key setup. If you wanted to get fancy, you could use a sign + encrypt setup with separate keys so the store can tell if this is a real backup from you, and not allow things to get stored unless they've got such a signature, yet it still can't actually decrypt the backups it has been given. As a proof of concept, take a look at a Certificate Transparency log server. Most CT logs are configured to only accept certificates meeting certain criteria. They'll log any such certificates (their SLAs only apply to contractual users, but you don't need an SLA you're probably just writing one certificate to the log to see it works) but you cannot fill them with garbage because you can't make any certificates they'd accept, only the legitimate CAs can do that† † The CAs have their own reasons not to let you produce heaps of garbage, even Let's Encrypt has finite resources and so it imposes rate limits.
  - lucb1e 5y ago
    But if your box gets compromised, then whatever it was using to prove to the server that it's legit is also going to be available to the attacker. I guess you're thinking of a scenario where backups are not automated and the user either unerringly knows whether their box is compromised (and doesn't type in said proof when that happens) or uses some 2FA hardware device. Given the chance, there certainly will be people that use 2FA when making an append-only regular backup, but even among command line restic users I expect this will be the exception rather than the rule.

phone8675309 5y ago

At the risk of sounding like a shill, tarsnap does that and explicitly supports write-only keys[1] [1] https://www.tarsnap.com/tips.html#write-only-keys https://www.tarsnap.com/tips.html#write-only-keys

lucb1e 5y ago
Indeed, this is one of the major advantages of tarsnap, though a friend also mentioned borg can do this apparently. I should really look into borg (again).
rssoconnor 5y ago
I do use Tarsnap for this reason. That said, Tarsnap isn't free software, and doesn't come with the ability for me to self-host backups. Thus, I am somewhat at the mercy of Amazon. Still, the advantages of Tarsnap currently outweigh the disadvantages in my opinion.
cperciva 5y ago
At the risk of sounding like a shill For the record, this is not a shill. I don't even know who Jenny is.

gnufx 5y ago

http://duplicity.nongnu.org/ http://duplicity.nongnu.org/ at least can use PGP public keys. I've used it for a long time and not seen any particular reason to change.

sreitshamer 5y ago

(I make Arq, a backup app that supports S3's object-lock API for immutable backups). I can't see how to do incremental backups without using the private key to read the previous backup record. Can you explain how that would work?