Just a clarification about the (seemingly high) price: the idea is to offer a limited space where users can put their critical files (business and sensitive personal stuff, not downloaded PDFs or DivX movies).
Something like your own private safe on the cloud, which is really really secure because we do:
- client-side encryption (we're not able to look at your files even if we wanted to);
- integrity check (you can verify that your files have not been tampered. This is our proprietary technology, I daresay nobody else does that as efficiently as we do);
- transparency (our client is open-source, so you can actually verify our claim that the software is secure. This is also something that few others do).
I don't understand what you mean by "proprietary" "integrity check". I looked at your code (only the client is open-source) and I see something about skip-lists, "proofs", and MD5.
File integrity is a solved problem, so I'm not clear on why you'd want to have a proprietary solution here.
The "proprietary" part of the solution is the efficiency it brings. MD5 hashes for a large set of data are slow to update and not really usable for a dynamic dataset. Our technology makes integrity checks possible in real-time.
I'm somehow even more confused than I was before I asked. Why are you using MD5? Stop doing that. And while I'm sure there is some scenario where simply hashing files might be costly, I don't see how that applies to you; for instance, every TLS record you send to your service is being "integrity checked" using a simple hash-based MAC.
It seems to me that they're using a tree-based structure to avoid hash-checking the entire file, but do hash checking in blocks and update it. Since they're using MD5, this probably makes it easier to find a collision and change a specific block.
Looks like they're using AES in CFB mode, which would probably complicate things, but I don't know why people don't use CTR mode more (it looks like it has many advantages to me, but I don't know much about crypto anyway), although in this scenario you'd probably want to use XTS.
Anyway, "proprietary" and "cryptography" in the same sentence is generally a big red flag to me.
The problem with that pricing is that you can have the same security by heavily encrypting a file and then storing it on any other cloud, or even USB sticks (as shown on your webpage). And because many cloud providers have a free or very cheap offer for small storage, you can afford not to keep all the eggs in the same basket and use more than one cloud provider for the same file.
Probably, but we want to simplify this. Actually, on our roadmap we are planning to replicate the user's data on multiple clouds so that the process of selecting the "correct" file (untampered) is automated.
The main difference brought from the technology we use is that while a system like the one you describe involves some probabilistic decision-making (like voting: e.g. out of 3 replicas, you choose 2 that seem correct) we have a mathematical way of verifying the integrity of the data (so you don't need to access all replicas to be sure that you are working with the correct data).
1. client-side encryption: it's all getting stored totally encrypted on amazon
2. integrity check: md5 check
3. transparency: I'll say you are more transparent, but your server-side code isn't open source so this isn't a huge win for me.
Arq is also a $29 one-time fee + the cost of S3, which is $.075/GB vs $13.
Arq seems to be a backup rather than a sync service that makes your files available on all your devices + from the web. As for the questions:
1. I couldn't find detailed info on Arq, but "plain" encrypted storage is different from client-side encryption (where you, and nobody else, control the keys)
2. Our integrity check is very efficient, allowing us to update a hash of the complete dataset in real-time (while re-MD5ing a set of data at every small update takes time)
3. See another answer in this thread: from a security point of view, the fact that the server is not open-source does not matter as the client verifies all server replies.
We believe that our security features are top-notch and are worth the price if you really care about the security of your data :-)
1. Tarsnap and (I believe) Arq both have client-controlled keys; the server can't decrypt data.
2. Stop saying you MD5 things, and, if you're using it, stop using MD5. Also: this is not a compelling feature. Tarsnap HMAC-SHA256's every block of data it stores.
3. I'm not going to tell you that you need to open-source your server, but I wouldn't give "it doesn't matter for security" as a reason why.
You should put a page together that explains your whole cryptosystem, down to "why you're using CFB" and "how you pick IVs for CFB" and "where integrity checks are performed", so that people can review it. It's awfully hard to assess security claims without detailed information.
My Problem is with your pricing is this:
For the amount you charge for 16GB, I could probably rent a dedicated server that had 200GB+ in harddrive storage.
Possibly; as said we do not really want to compete on the space available, but on the security we give.
With the solution you mention, you'd have to manage the server and the encrypted communication, make everything redundant and still introduce some kind of integrity check if you want to really be sure that your provider hasn't tampered with your data.
I just don't get this. Well done for open sourcing the client, but on the front page the product is touted as fully open source so it can be audited, but the client is only half the product (arguably less) so security cannot be audited. The prices are also incredibly expensive, I can understand why you pictures of old fashioned USB sticks. Good luck with your business but I can't see how this is going to disrupt anything.
Yes, our client is open-source but our server isn't. But from the point of view of security this is sufficient, as the client does not "trust" the server and every server reply is verified.
The client code is GPLv3, so it could be a building block for other projects if they want to use it with a different server.
When I read some of the comments above, I thought "Oh come on, they make the client's source available to prove security, and you're complaining about lack of self-hosting? They're a business!"
But yes, it's not an "open source <something>", it's a "<something> with source available". It's great from a security standpoint, but "open source" implies that all the components are open-source and that you can self-host, and referring to it as "open source <something>" is disingenuous.
That said, this is just the HN post's title. It's not described like that on your site, so that part is good.
They ARE expensive...and not a bit. At least for the legal uses i can think about. Who knows, they might have a market though. Wish you best of luck guys.
Just a clarification about the (seemingly high) price: the idea is to offer a limited space where users can put their critical files (business and sensitive personal stuff, not downloaded PDFs or DivX movies).
Something like your own private safe on the cloud, which is really really secure because we do:
- client-side encryption (we're not able to look at your files even if we wanted to);
- integrity check (you can verify that your files have not been tampered. This is our proprietary technology, I daresay nobody else does that as efficiently as we do);
- transparency (our client is open-source, so you can actually verify our claim that the software is secure. This is also something that few others do).