4 ms·

The rule is, "data in motion should be secured with TLS, data at rest should be secured with PGP". And even that attitude can be dangerous. A while back I was

The rule is, "data in motion should be secured with TLS, data at rest should be secured with PGP". And even that attitude can be dangerous. A while back I was getting depressed at the usability of tarsnap so I began to think about how I would design some secure backup system on Windows. "Ok," I thought, "I'll build stuff on top of GPG." The trouble is, any way I imagined doing this, even taking out features like deduplication, I would have leaked the filesizes of every file backed up. If the FBI wanted to scan for anybody who had some popular illegal porn collection or whatnot, they could tell just by looking or a certain distribution of chunk sizes. And anybody listening on the network would be able to get a weak idea of the filesizes just based on timing. I have no idea what Tarsnap does about this; I am guessing the blocks it hashes for deduplication purposes aren't the same as the ones it sends to the server, and I presume it doesn't stream stuff to the server as it scans the filesystem. And there are probably several other things it does that I wouldn't even think of. (But even then if some government found that a protest movement was distributing USB sticks with 3.167 GB of information after it gets zipped for backup, it could just look for people uploading that approximate amount of information to the backup server. It seems like people who have a true reason to be paranoid simply shouldn't do online backups.) I would change the rule to "Data in motion should be secured with TLS, data at rest should be secured with PGP, and don't even think about doing anything weird."

cperciva 17y ago
A while back I was getting depressed at the usability of tarsnap Please send me an email with details about the usability issues you encountered. [...] distribution of chunk sizes [...] I have no idea what Tarsnap does about this; I am guessing the blocks it hashes for deduplication purposes aren't the same as the ones it sends to the server, and I presume it doesn't stream stuff to the server as it scans the filesystem. And there are probably several other things it does that I wouldn't even think of. The blocks Tarsnap uses for deduplication are the same as the blocks Tarsnap uploads; but they are encrypted (to avoid leaking file data), identified by HMAC (to avoid leaking information via hash), and the blocking is key dependent, so an attacker can't say "you have chunks of lengths X, Y, and Z, so you probably have this particular block of data". Also, the chunk size (64 kB on average, pre-compression) is small enough that there would be too much noise to pull off such an attack.

cperciva 17y ago

A while back I was getting depressed at the usability of tarsnap Please send me an email with details about the usability issues you encountered. [...] distribution of chunk sizes [...] I have no idea what Tarsnap does about this; I am guessing the blocks it hashes for deduplication purposes aren't the same as the ones it sends to the server, and I presume it doesn't stream stuff to the server as it scans the filesystem. And there are probably several other things it does that I wouldn't even think of. The blocks Tarsnap uses for deduplication are the same as the blocks Tarsnap uploads; but they are encrypted (to avoid leaking file data), identified by HMAC (to avoid leaking information via hash), and the blocking is key dependent, so an attacker can't say "you have chunks of lengths X, Y, and Z, so you probably have this particular block of data". Also, the chunk size (64 kB on average, pre-compression) is small enough that there would be too much noise to pull off such an attack.