Nice reply, sorry was sleeping, then woke up and got the chainsaw out and started clearing trees again:) Haters gonna hate;)
On Sun, 24 Mar 2013 11:08:42 +0100, Yiorgis Gozadinos <ggo...@crypho.com> wrote: > > On Mar 24, 2013, at 01:11 , Steve Weis <stevew...@gmail.com> wrote: > > > Hi Yiorgis. The Crypho web page says: > > "No-one can access your data, either in transit or when stored — Not even > > Crypho staff or the government." > > > > Yet, you acknowledge that "we are aware of the potential problems of > > serving JS [Javascript]", meaning it's trivial for your staff or a > > government to compromise the Javascript code and cause it to leak plaintext > > data. > > > > Even the authors of the Stanford Javascript Crypto Library (SJCL), which > > Crypho "uses solely", say that it's not feasible to secure: > > "Unfortunately, [SJCL] is not as great as in desktop applications because > > it is not feasible to completely protect against code injection, malicious > > servers and side-channel attacks." (http://crypto.stanford.edu/sjcl/) > > Hey Steve, > > Thanks for bringing this up. We are aware of the js crypto controversy and it > is a challenge for us as we are trying to make crypto more approachable. > > On the technical side, like I said, we will try to address the issue of > trusted js by implementing apps as well as explore ways of asserting the > authenticity of served js. Open-sourcing the client code will certainly help > in auditing. There are other things we put in place to help, CSP, > Strict-Transport-Security and X-Frame-Options headers for example or a proper > SSL setup. > These cannot guarantee of course that we haven't overseen things, but our > hope is that gradually we can build trust on our app. > > Now, similar issues exist of course on networked desktop apps just as well. > Nobody can guarantee that malware will not eavesdrop on you, and it is pretty > hard to assert there are no backdoors in proprietary software. > > The argument, when stretched, eventually leads to: Unless you are a skilled > cryptographer, and can audit/inspect/write your own code, you should not be > using crypto because it is dangerous and you will invariably screw up > somewhere. While this is true in a few cases, and it should not be taken > lightly, it leaves something to be desired for the rest of us. > > In my professional life, I have yet to see somebody who is not a geek, or has > received training, use PGP or encrypt data strongly. The process is complex, > and it is easier to screw up than use properly. In addition to that, "normal" > people when faced with the choice between security and convenience, will > invariably pick the second. > > Businesses start recognising that they over-share, and some even become > reluctant to use cloud services, because of various reasons, be it policy, > fear or cross-border legislation. What we try to do, is bridge the gap, and > provide a familiar and convenient interface sacrificing in the way as little > security as possible. > > Again, that does not make Crypho the tool of choice if you are an activist, > risking your life. Between the activist and John Doe the lawyer who wants to > share a contract with his client without storing it plain in the US, there is > a big gap. We hope that Crypho will cater well for the second case. > > -- > Yiorgis Gozadinos > www.crypho.com > > -- > Too many emails? Unsubscribe, change to digest, or change password by > emailing moderator at compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
