4 ms·

In Tahoe-LAFS, it is actually a proven truth that, up to the level of cryptographic unguessability, server operators cannot read stored files without knowing th

In Tahoe-LAFS, it is actually a proven truth that, up to the level of cryptographic unguessability, server operators cannot read stored files without knowing the client-side key. If you can prove otherwise, then you can earn a spot in their hall of fame: https://tahoe-lafs.org/hacktahoelafs/ https://tahoe-lafs.org/hacktahoelafs/ Tahoe-LAFS providers like Least Authority [1] and Matador Cloud [2] pride themselves on not being able to access your data. [1] https://leastauthority.com/ https://leastauthority.com/ [2] https://matador.cloud/ https://matador.cloud/

aboodman 10y ago
Yeah in that case Tahoe-LAFS and the storage providers are different entities. So if you trust the Tahoe-LAFS developers, then you don't need to trust the storage providers.
cakoose 10y ago
Like OP said, having that design is valuable, but you're still running someone's software on your computer. With Tahoe LAFS, you're either downloading the pre-built binary or compiling from source. Either way, you're trusting the person who signed the binary/source or the person who hosts them. This is similar to when Apple says they can't read your messages. Sure, they may not able to decrypt the data on their server, but they're in total control of the client software. They can get access to your messages. I do think it's in Tahoe/Apple/etc's interest to NOT be able to see their data. For one, they said they can't and reputations are important. It may also be beneficial when dealing with law enforcement requests. So trusting them isn't totally unwarranted, but there's a lot there that isn't mathematics. (You're never going to get to 100% math, but there are ways to get further. For example, someone might eventually write a Tahoe LAFS client that comes with a machine-checkable proof that it doesn't leak plaintext. You now need to trust the proof checker, but it's progress.)
- powera 10y ago
  What do you want then? Only use software you've written yourself, on a non-networked computer?
  - cakoose 10y ago
    Like I said, I don't think it's unreasonable to trust Apple or the Tahoe LAFS download server. I think they're improving the state of security and I would use those products. I just want people to be clear about the actual security properties of the whole system. For example, people should know that blanket statements like "Apple cannot read your messages" are false. And your client/server protocol can be state of the art, but you still rely on the much-maligned HTTPS certificate infrastructure (among other things) to get the client bits.
- emn13 10y ago
  The client could be open source; indeed the network protocol might even be simple. The client distribution or even implementation might be handled by third party. If for commercial reasons the provider wants a fancy shell and doesn't trust the open source or third party for that, they might consider a locally-untrusted (and possibly even remotely run) GUI that is a frontend for your local (trusted, open-source) backup engine. I believe you can architect a solution such that it's easy enough to get a third party (or yourself) to verify it is safe and private, even in the face of a hostile backup provider (or more realistically, a backup provider that's met an opportunistic law enforcement agency waving a sternly worded letter). If enough parties collude, they can still gain access to your data, but at that point I'm pretty sure the backups won't be the weakest link anymore. I mean, you're still running an OS, and compiling with a compiler, installing and running software from a package distributor, and using a CPU with a management engine, and all those things might have backdoors too.
rarrrrrr 10y ago
Tahoe-LAFS is really awesome open project by great people with a rich history of solving complex problems. If this space is interesting to you, spending a few days reading through their Trac is educational and rewarding! Highly recommended. Trivia: One of the founders of LAFS went on to found Zcash, the (actually) zero knowledge crypto currency.

aboodman 10y ago

Yeah in that case Tahoe-LAFS and the storage providers are different entities. So if you trust the Tahoe-LAFS developers, then you don't need to trust the storage providers.

cakoose 10y ago

Like OP said, having that design is valuable, but you're still running someone's software on your computer. With Tahoe LAFS, you're either downloading the pre-built binary or compiling from source. Either way, you're trusting the person who signed the binary/source or the person who hosts them. This is similar to when Apple says they can't read your messages. Sure, they may not able to decrypt the data on their server, but they're in total control of the client software. They can get access to your messages. I do think it's in Tahoe/Apple/etc's interest to NOT be able to see their data. For one, they said they can't and reputations are important. It may also be beneficial when dealing with law enforcement requests. So trusting them isn't totally unwarranted, but there's a lot there that isn't mathematics. (You're never going to get to 100% math, but there are ways to get further. For example, someone might eventually write a Tahoe LAFS client that comes with a machine-checkable proof that it doesn't leak plaintext. You now need to trust the proof checker, but it's progress.)

powera 10y ago
What do you want then? Only use software you've written yourself, on a non-networked computer?
- cakoose 10y ago
  Like I said, I don't think it's unreasonable to trust Apple or the Tahoe LAFS download server. I think they're improving the state of security and I would use those products. I just want people to be clear about the actual security properties of the whole system. For example, people should know that blanket statements like "Apple cannot read your messages" are false. And your client/server protocol can be state of the art, but you still rely on the much-maligned HTTPS certificate infrastructure (among other things) to get the client bits.
emn13 10y ago
The client could be open source; indeed the network protocol might even be simple. The client distribution or even implementation might be handled by third party. If for commercial reasons the provider wants a fancy shell and doesn't trust the open source or third party for that, they might consider a locally-untrusted (and possibly even remotely run) GUI that is a frontend for your local (trusted, open-source) backup engine. I believe you can architect a solution such that it's easy enough to get a third party (or yourself) to verify it is safe and private, even in the face of a hostile backup provider (or more realistically, a backup provider that's met an opportunistic law enforcement agency waving a sternly worded letter). If enough parties collude, they can still gain access to your data, but at that point I'm pretty sure the backups won't be the weakest link anymore. I mean, you're still running an OS, and compiling with a compiler, installing and running software from a package distributor, and using a CPU with a management engine, and all those things might have backdoors too.

rarrrrrr 10y ago

Tahoe-LAFS is really awesome open project by great people with a rich history of solving complex problems. If this space is interesting to you, spending a few days reading through their Trac is educational and rewarding! Highly recommended. Trivia: One of the founders of LAFS went on to found Zcash, the (actually) zero knowledge crypto currency.