3 ms·

There's no such thing as "host proof". There is software tamper resistance, which gives limited protection against the host and is often used for DRM. But this

There's no such thing as "host proof". There is software tamper resistance, which gives limited protection against the host and is often used for DRM. But this software does not use software tamper resistance. The author made up the term "host proof" to refer to the fact that the data is not stored on the client and is sent to the server encrypted. That's it. This is Javascript "pgp -c" (passphrase-based encryption) but less secure. With Javascript crypto, you implicitly trust the server. You are executing code downloaded from the server in order to encrypt your data to upload to the same server (or one run by the same entity if not the exact same box). Instead of trusting the server to encrypt your data for you, you're trusting it to send you unmodified, non-buggy code to encrypt your data for you. Every time you connect to it. The one time it sends you a trojaned (or buggy) version of the code, your data is compromised. I prefer to get my software once, audit it, and be sure I'm running the same thing every time. With Javascript crypto, every time you connect to the site is a crapshoot. Is it 0wned today? Maybe. The comments section of a post I wrote has a discussion of Clipperz, a JS crypto library: http://rdist.root.org/2009/06/10/when-crypto-attacks-slides-posted/#comments http://rdist.root.org/2009/06/10/when-crypto-attacks-slides-...

m_eiman 17y ago
He actually talks about that in the post, if you read it. He's making a Firefox plugin to validate JS before it's run, it's a bit down near the end.
CMay 17y ago
It's incorrect that there is no such thing as host-proof assuming the meaning intended by cryp.sr, but you would be correct in being put off by a false sense of security this provides for users of the web based version of the interface. I believe that's the point of the client library at http://github.com/cortesi/crypsr_client http://github.com/cortesi/crypsr_client. The only things you're asked to trust is that encryption algorithm is good and that the host will delete the encrypted data long before the processor in your smart phone is fast enough to decrypt it in 30 milliseconds. If the host returns bad data, it simply won't decrypt and it will be trash. The real problem with this service is that it's intended to be an easy to use secure means of sharing information from one to many, but to make true secure use of it everyone needs to download a dedicated trusted client and the problem becomes no different than it has always been and only marginally more user friendly than hosting the data yourself. Refusing to trust or rely on SSL by using javascript based encryption is something I've experimented with a bit in the past. Without this you are still relying on SSL which only protects the information in transport anyway. If the server is compromised, then at the least all of the information already stored on the server is secure as each key is not on the server at all. At that point you just have to worry about whether the algorithm has flaws or if the person gaining unauthorized access has a couple supercomputer farms and many years on their hands. It is true that if you rely on the host to provide you with the encryption algorithm then it is open to future compromise, but the data couldn't be retroactively compromised until the moment it's accessed again via a modified page. Due to this, using cryp.sr via a browser is less desirable than using the open source client until there's a trusted plugin or greasemonkey script.

m_eiman 17y ago

He actually talks about that in the post, if you read it. He's making a Firefox plugin to validate JS before it's run, it's a bit down near the end.

CMay 17y ago

It's incorrect that there is no such thing as host-proof assuming the meaning intended by cryp.sr, but you would be correct in being put off by a false sense of security this provides for users of the web based version of the interface. I believe that's the point of the client library at http://github.com/cortesi/crypsr_client http://github.com/cortesi/crypsr_client. The only things you're asked to trust is that encryption algorithm is good and that the host will delete the encrypted data long before the processor in your smart phone is fast enough to decrypt it in 30 milliseconds. If the host returns bad data, it simply won't decrypt and it will be trash. The real problem with this service is that it's intended to be an easy to use secure means of sharing information from one to many, but to make true secure use of it everyone needs to download a dedicated trusted client and the problem becomes no different than it has always been and only marginally more user friendly than hosting the data yourself. Refusing to trust or rely on SSL by using javascript based encryption is something I've experimented with a bit in the past. Without this you are still relying on SSL which only protects the information in transport anyway. If the server is compromised, then at the least all of the information already stored on the server is secure as each key is not on the server at all. At that point you just have to worry about whether the algorithm has flaws or if the person gaining unauthorized access has a couple supercomputer farms and many years on their hands. It is true that if you rely on the host to provide you with the encryption algorithm then it is open to future compromise, but the data couldn't be retroactively compromised until the moment it's accessed again via a modified page. Due to this, using cryp.sr via a browser is less desirable than using the open source client until there's a trusted plugin or greasemonkey script.