5 ms·

Hey, Daniele (FileRock CEO) here. Just a clarification about the (seemingly high) price: the idea is to offer a limited space where users can put their critica

Hey, Daniele (FileRock CEO) here. 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).

Avshalom 13y ago
I feel like Tarsnap offers all that a fraction of the price.
egonschiele 13y ago
How does this compete with something like Arq (http://www.haystacksoftware.com/arq http://www.haystacksoftware.com/arq)? 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. In what use case would I choose FileRock?
- FileRockDA 13y ago
  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 :-)
  - tptacek 13y ago
    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.
jeffasinger 13y ago
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.
- FileRockDA 13y ago
  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.
tptacek 13y ago
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.
- FileRockDA 13y ago
  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.
  - tptacek 13y ago
    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.
    - StavrosK 13y ago
      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.
      - FileRockDA 13y ago
        Sorry if I wasn't clear. We're not using MD5. And we're not using proprietary cryptography. What's "proprietary" is the implementation of the integrity check technology, which is based on published research.
miahi 13y ago
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.
- FileRockDA 13y ago
  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).
darkchasma 13y ago
Yea, the prices are ridiculous, you blew right past the mark on this.
lawnchair_larry 13y ago
Yup, things that you never want to hear together: "really really secure", "proprietary"

Avshalom 13y ago

I feel like Tarsnap offers all that a fraction of the price.

egonschiele 13y ago

How does this compete with something like Arq (http://www.haystacksoftware.com/arq http://www.haystacksoftware.com/arq)? 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. In what use case would I choose FileRock?

FileRockDA 13y ago
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 :-)
- tptacek 13y ago
  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.

jeffasinger 13y ago

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.

FileRockDA 13y ago
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.

tptacek 13y ago

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.

FileRockDA 13y ago
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.
- tptacek 13y ago
  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.
  - StavrosK 13y ago
    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.
    - FileRockDA 13y ago
      Sorry if I wasn't clear. We're not using MD5. And we're not using proprietary cryptography. What's "proprietary" is the implementation of the integrity check technology, which is based on published research.

miahi 13y ago

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.

FileRockDA 13y ago
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).

darkchasma 13y ago

Yea, the prices are ridiculous, you blew right past the mark on this.

lawnchair_larry 13y ago

Yup, things that you never want to hear together: "really really secure", "proprietary"