4 ms·

Asymmetric crypto for backups feels overrated to me. The "write-only mode" argument makes sense, if the backup target holds data from other nodes, but that doe

Asymmetric crypto for backups feels overrated to me. The "write-only mode" argument makes sense, if the backup target holds data from other nodes, but that doesn't require asymmetric crypto. The "shouldn't be able to read own backups by default because what if it's hacked" argument doesn't seem to hold much water to me, because the most valuable secrets will generally be those in active use on the machine.

justin_oaks 8y ago
Asymmetric crypto allows you to use the same public key across all your machines without the concern that one compromised machine will leak the key for all of them.
- blattimwind 8y ago
  Like I said, access control does not require asymmetric crypto.
  - justin_oaks 8y ago
    Layered security. If there's a vulnerability in your access control, the encryption prevents data from being accessed (decrypted). If there's a vulnerability in the encryption, the access control prevents the data from being read.
    - blattimwind 8y ago
      I'm not saying it shouldn't be done, but I've seen a number of projects which have been started (and afaik abandoned as soon as the author saw that backup software isn't quite so simple to develop) specifically because asymmetric crypto was seen as a missing flagship feature. What I'm saying here is, if you start a new backup software project today, there are more important things to consider and failings of existing software to address than not supporting asymmetric crypto. Do the encryption right. Do proper access controls. Get concurrency right. Get deduplication right. Get your archive/snapshot format right. Get filesystem interaction and testing right. Maybe you think existing software does all of that already; it doesn't. (Though I am actually convinced that you can't design a piece fulfilling these requirements without having a lot of prior experience developing backup software — conversely that's the reason why most backup software is so half-baked: they're all first designs, by the time a developer has the necessary experience to do a better second design, they're fed up with backup software and move on).
FooBarWidget 8y ago
> The "shouldn't be able to read own backups by default because what if it's hacked" argument doesn't seem to hold much water to me, because the most valuable secrets will generally be those in active use on the machine. Leaking data is only one consequence of getting hacked. Another consequence is corrupting data. Even if you can't prevent the former, there are still times when you want to recover from the latter. If the attacker can overwrite old backups then you are toast.
- blattimwind 8y ago
  "read" vs "write"
- ericpauley 8y ago
  Unfortunately asymmetric encryption on the data itself only prevents leaking. It doesn't ensure integrity or prevent deletion. For that you need some system that explicitly enforces those permissions.

justin_oaks 8y ago

Asymmetric crypto allows you to use the same public key across all your machines without the concern that one compromised machine will leak the key for all of them.

blattimwind 8y ago
Like I said, access control does not require asymmetric crypto.
- justin_oaks 8y ago
  Layered security. If there's a vulnerability in your access control, the encryption prevents data from being accessed (decrypted). If there's a vulnerability in the encryption, the access control prevents the data from being read.
  - blattimwind 8y ago
    I'm not saying it shouldn't be done, but I've seen a number of projects which have been started (and afaik abandoned as soon as the author saw that backup software isn't quite so simple to develop) specifically because asymmetric crypto was seen as a missing flagship feature. What I'm saying here is, if you start a new backup software project today, there are more important things to consider and failings of existing software to address than not supporting asymmetric crypto. Do the encryption right. Do proper access controls. Get concurrency right. Get deduplication right. Get your archive/snapshot format right. Get filesystem interaction and testing right. Maybe you think existing software does all of that already; it doesn't. (Though I am actually convinced that you can't design a piece fulfilling these requirements without having a lot of prior experience developing backup software — conversely that's the reason why most backup software is so half-baked: they're all first designs, by the time a developer has the necessary experience to do a better second design, they're fed up with backup software and move on).

FooBarWidget 8y ago

> The "shouldn't be able to read own backups by default because what if it's hacked" argument doesn't seem to hold much water to me, because the most valuable secrets will generally be those in active use on the machine. Leaking data is only one consequence of getting hacked. Another consequence is corrupting data. Even if you can't prevent the former, there are still times when you want to recover from the latter. If the attacker can overwrite old backups then you are toast.

blattimwind 8y ago
"read" vs "write"
ericpauley 8y ago
Unfortunately asymmetric encryption on the data itself only prevents leaking. It doesn't ensure integrity or prevent deletion. For that you need some system that explicitly enforces those permissions.