Re: [liberationtech] Crypho

[Mike Perry]

zooko:

> On Tue, Mar 26, 2013 at 09:24:13AM +0100, Yiorgis Gozadinos wrote:
> > 
> > Assuming there is a point of reference for js code, some published instance 
> > of the code, that can be audited and verified by others that it does not 
> > leak. The point then becomes: "Is the js I am running in my browser the 
> > same as the js that everybody else is?". 
> > Like you said, it comes down to the trust one can put in the verifier.
> > A first step could be say for instance a browser extension, that compares a 
> > hash of the js with a trusted authority. The simplest version of that would 
> > be a comparison of a hash with a hash of the code on a repo.
> > Another (better) idea, would be if browser vendors would take up the task 
> > (say Mozilla for instance) and act as the trusted authority and built-in 
> > verifier. Developers would sign their code and the browser would verify.
> > Finally, I want to think there must be a way for users to broadcast some 
> > property of the js they received. Say for example the color of a hash. Then 
> > when I see blue when everyone else is seeing pink, I know there is 
> > something fishy. There might be a way to even do that in a decentralised 
> > way, without having to trust a central authority.
> 
> Dear Yiorgis:
> 
> I think this is a promising avenue for investigation. I think the problem is
> that people like you, authors of user-facing apps, know what the problem is
> that you want to solve, but you can't solve it without help from someone else,
> namely the authors of web browsers.
> 
> With help from the web browser, this problem would be at least partly 
> solvable.
> There is no reason why this problem is more impossible to solve for apps
> written in Javascript and executed by a web browser than for apps written in a
> language like C# and executed by an operating system like Windows.
> 
> Perhaps the next step is to explain concisely to the makers of web browsers
> what we want.
> 
> Ben Laurie has published a related idea:
> 
> http://www.links.org/?p=1262

Now this is interesting. Had not seen that link before.

I wonder how that above 2012 Ben Laurie would get along with this
slightly more vintage 2011 Ben Laurie, who discounts not only the
hashtree concept, but any attempt to secure it with computation as well:
http://www.links.org/?p=1183

The problem is, 2012 Ben Laurie's system is obviously quite easy to
censor and manipulate if the adversary has any sort of active traffic
capabilities in terms of showing custom extensions of the hash chain (ie
malware) to targeted individuals.

2011 Ben Laurie's "Efficient Distributed Currency", on the other hand,
suggests a Tor-like multiparty signing protocol to avoid these issues:
http://www.links.org/files/distributed-currency.pdf

But if we assume the worst, the 2011 model Ben Laurie is weak to an
adversary such as the NSA that might compromise his datacenter
computers (or keys) behind his back.

However, 2012 Ben Laurie could detect this compromise by the NSA if it
was reasonably hard to add new, fake entries to the hash tree, if
clients kept history, and if he had multiple authenticated network
perspectives on the hash tree (ie notaries).

Can't both Ben Laurie's just get along? ;)


To bring us back to Earth:

The core problem with the website-as-an-app JS model is that *every* JS
code download from the server is not only authenticated only by the
abysmal CA trust root, but that insecure/malicious versions of the
software can also be easily targeted *specifically* to your account by
the webserver (or by the CA mafia) at any time without informing you in
any way.

But, the really scary situation we now face is that many of us have
accounts on app stores capable of delivering updates *right now* that
have the same type of targeted capabilities. In fact, in my opinion, all
app stores that exist today are just as unsafe for delivering crypto
software as website-based solutions are :/.


I think I still agree that the takeaway is that it's better to create
situations where you only have to do a heavyweight "double Ben Laurie"
PKI+notary+hashtree+PoW all-in-one-check *once* upon initial download,
to establish a trust root with the software provider themselves, rather
than regularly trusting an intermediary appstore, webserver, and/or 
CA trust root.

Once that initial strong check is done (and you've either run the
malware or you haven't), then the software can update using its own
strong signature authentication. In the case of paid/proprietary
software, proof of purchase from the client should be based upon
blind-signatures/ZKPs instead of unique account credentials.

But like, really nobody in the world is doing any of this, are they?


-- 
Mike Perry
--
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

Re: [liberationtech] Crypho

[zooko]

On Tue, Mar 26, 2013 at 09:24:13AM +0100, Yiorgis Gozadinos wrote:
> 
> Assuming there is a point of reference for js code, some published instance 
> of the code, that can be audited and verified by others that it does not 
> leak. The point then becomes: "Is the js I am running in my browser the same 
> as the js that everybody else is?". 
> Like you said, it comes down to the trust one can put in the verifier.
> A first step could be say for instance a browser extension, that compares a 
> hash of the js with a trusted authority. The simplest version of that would 
> be a comparison of a hash with a hash of the code on a repo.
> Another (better) idea, would be if browser vendors would take up the task 
> (say Mozilla for instance) and act as the trusted authority and built-in 
> verifier. Developers would sign their code and the browser would verify.
> Finally, I want to think there must be a way for users to broadcast some 
> property of the js they received. Say for example the color of a hash. Then 
> when I see blue when everyone else is seeing pink, I know there is something 
> fishy. There might be a way to even do that in a decentralised way, without 
> having to trust a central authority.

Dear Yiorgis:

I think this is a promising avenue for investigation. I think the problem is
that people like you, authors of user-facing apps, know what the problem is
that you want to solve, but you can't solve it without help from someone else,
namely the authors of web browsers.

With help from the web browser, this problem would be at least partly solvable.
There is no reason why this problem is more impossible to solve for apps
written in Javascript and executed by a web browser than for apps written in a
language like C# and executed by an operating system like Windows.

Perhaps the next step is to explain concisely to the makers of web browsers
what we want.

Ben Laurie has published a related idea:

http://www.links.org/?p=1262

Regards,

Zooko

https://tahoe-lafs.org - Free, Open Source Secure Decentralized Storage
https://LeastAuthority.com - Commercial Ciphertext Storage Service
--
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

Re: [liberationtech] Crypho

[Yiorgis Gozadinos]

On Mar 26, 2013, at 2:16 PM, hellekin  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 03/26/2013 05:24 AM, Yiorgis Gozadinos wrote:
>> 
>> "Is the js I am running in my browser the same as the js that
>> everybody else is?".
>> 
> *** The LibreJS project [1] tries to solve that issue to ensure the
> code is unmodified free software. There's probably room for cooperation.
> 
> Assuming Javascript code does not call other sources that will run in
> the same space as the rest of it, and bypass the checks.


Unless I have misunderstood, LibreJS merely detects whether the js served comes 
with a open-source license. It would not detect if Crypho or a someone else 
maliciously served modified js to specific users.

-- 
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

Re: [liberationtech] Crypho

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/26/2013 05:24 AM, Yiorgis Gozadinos wrote:
> 
> "Is the js I am running in my browser the same as the js that
> everybody else is?".
> 
*** The LibreJS project [1] tries to solve that issue to ensure the
code is unmodified free software. There's probably room for cooperation.

Assuming Javascript code does not call other sources that will run in
the same space as the rest of it, and bypass the checks.

==
hk

[1] https://www.gnu.org/software/librejs/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRUZ+zAAoJEDhjYTkcokoTJ4AP/2jmmbuTeXxR3JOgFSWSI5Zs
KdvPEqIiUnXhYVmOaslyGnvZwKKY+q/gDnN/b5I2XEidIuTdrtRy+MCf/O9Hba3C
w1GpA4LM1Vhlyfld6UNmMJ9aYoxRByJW04uIpkzpi9pQ1C9rR2VvqENXfoDpQ50a
UdIX67Yahhs5s4zrAplFVDhQMdHfMOUWEzoLHQl3ppSyoCvT9JdwCsGO/sWIYtdL
E/sZuRq69kjbDqtHDBUZzhQHNpKzMF5qeGRhq7nLrRykCbBICfazUXZG3A0n6ecT
YGXVhuHm37xhFwxWTp8ncpbMgiPfrJQn2hcL5lTXiccdjcip24FJmbe8u7nYI4bg
FMNH0tTTKqZ8t1stnHxxCc18thCPygeu+Mj+rWkDFnvvzJa9jOdTQaENa29MaGRO
+z50c6gd1Yrca1lc+yXpkK50fgaLI+w/qREne1uButlOCp5p538cslqbjMUxZw/P
LLTcGJEHq4rCyp5dgJxkMN+q2Bq4Z1YklpnGVJMlEPDmzFkyWvQ19Cs5BilzQ9hY
0mmqBAyGAkjgaBhl1F3nUuVLg1tcNb12np59Rdr5Y/QxvKqBYnUCh3ZY/sQOBDrH
CiSKMXAFt+F5K29EWbHpDXNtZ7wRcHLZzNHUrvQyMYyh9PrLnRjCWqGZC2SXjWVi
ESbmQDRnurbNjbPWCXQf
=YUSu
-END PGP SIGNATURE-
--
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

Re: [liberationtech] Crypho

[Yiorgis Gozadinos]

On Mar 25, 2013, at 18:20 , Steve Weis  wrote:

> Hi Yiorgis. The "ways of asserting the authenticity of served [JavaScript]" 
> always reduce to trusted code executing on the client. You need to trust 
> whatever is authenticating the served application. You can't get around it.
> 
> This approach always ends up with either trusting the service or running 
> client-side code. The former is a perfectly fine business model and the 
> standard for almost all web apps, but you can't make the claim that "the 
> government and our staff cannot access your data". It's simply not true, and 
> not just because there might be incidental bugs you're working on fixing. 
> It's fundamentally untrue.
> 
> I appreciate the challenge you are trying to tackle and understand that 
> delivering client-side code across all browsers and platforms is a 
> non-starter for an early startup. If it were an easy problem, we wouldn't be 
> having this discussion. I wish you luck in solving it.

Hey Steve,
I can't say how much I appreciate your comments :)
If I may I would like to leave aside the rest, and try to share my 
not-implemented and purely based on intuition and speculation vision on 
authenticated js. This of course means that I acknowledge the fact that the way 
we serve crypho leaves a lot to be desired in terms of security, and apps will 
be our short-term solution. I strongly believe though in the browser as the 
platform, and want to take this as the opportunity to see whether there exists 
a viable solution outside the apps.

Assuming there is a point of reference for js code, some published instance of 
the code, that can be audited and verified by others that it does not leak. The 
point then becomes: "Is the js I am running in my browser the same as the js 
that everybody else is?". 
Like you said, it comes down to the trust one can put in the verifier.
A first step could be say for instance a browser extension, that compares a 
hash of the js with a trusted authority. The simplest version of that would be 
a comparison of a hash with a hash of the code on a repo.
Another (better) idea, would be if browser vendors would take up the task (say 
Mozilla for instance) and act as the trusted authority and built-in verifier. 
Developers would sign their code and the browser would verify.
Finally, I want to think there must be a way for users to broadcast some 
property of the js they received. Say for example the color of a hash. Then 
when I see blue when everyone else is seeing pink, I know there is something 
fishy. There might be a way to even do that in a decentralised way, without 
having to trust a central authority.

All this smells like overkill if there is no general interest in pursuing it, 
but I would love to hear your thoughts as well as other's on this.

-- 
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

Re: [liberationtech] Crypho

[Brian Conley]

Thanks for this Steve, its a rare breath of fresh air to see someone
respond firmly, critically, yet also collegially.

+1 for gnomish anti-troll behavior!

B

On Mon, Mar 25, 2013 at 10:20 AM, Steve Weis  wrote:

> Hi Yiorgis. The "ways of asserting the authenticity of served
> [JavaScript]" always reduce to trusted code executing on the client. You
> need to trust whatever is authenticating the served application. You can't
> get around it.
>
> This approach always ends up with either trusting the service or running
> client-side code. The former is a perfectly fine business model and the
> standard for almost all web apps, but you can't make the claim that "the
> government and our staff cannot access your data". It's simply not true,
> and not just because there might be incidental bugs you're working on
> fixing. It's fundamentally untrue.
>
> I appreciate the challenge you are trying to tackle and understand that
> delivering client-side code across all browsers and platforms is a
> non-starter for an early startup. If it were an easy problem, we wouldn't
> be having this discussion. I wish you luck in solving it.
>
> On Sun, Mar 24, 2013 at 3:08 AM, Yiorgis Gozadinos wrote:
>
>> 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.
>>
>
> --
> 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
>



-- 



Brian Conley

Director, Small World News

http://smallworldnews.tv

m: 646.285.2046

Skype: brianjoelconley
--
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

Re: [liberationtech] Crypho

[Steve Weis]

Hi Yiorgis. The "ways of asserting the authenticity of served [JavaScript]"
always reduce to trusted code executing on the client. You need to trust
whatever is authenticating the served application. You can't get around it.

This approach always ends up with either trusting the service or running
client-side code. The former is a perfectly fine business model and the
standard for almost all web apps, but you can't make the claim that "the
government and our staff cannot access your data". It's simply not true,
and not just because there might be incidental bugs you're working on
fixing. It's fundamentally untrue.

I appreciate the challenge you are trying to tackle and understand that
delivering client-side code across all browsers and platforms is a
non-starter for an early startup. If it were an easy problem, we wouldn't
be having this discussion. I wish you luck in solving it.

On Sun, Mar 24, 2013 at 3:08 AM, Yiorgis Gozadinos wrote:

> 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.
>
--
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

Re: [liberationtech] Crypho

[ddahl]

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  wrote:

> 
> On Mar 24, 2013, at 01:11 , Steve Weis  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

Re: [liberationtech] Crypho

[Yiorgis Gozadinos]

On Mar 24, 2013, at 01:11 , Steve Weis  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

Re: [liberationtech] Crypho

[Steve Weis]

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/)

On Sat, Mar 23, 2013 at 3:57 AM, Yiorgis Gozadinos wrote:

> We are aware of the potential problems of serving js. We will eventually
> ship an installable app, but at the moment, with daily updates, ease of
> deployment wins.
--
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

[liberationtech] Crypho

[Yiorgis Gozadinos]

Hey!

Yosem contacted me and Geir (aka Crypho) on twitter and made us aware of 
LibTech. He was also kind to forward to me the discussion on our product. So, 
here's a short summary hopefully addressing your questions.

Crypho is a web app allowing teams to share confidential data. You can chat, 
edit documents, share files in private spaces, in real-time or async 
(everything is persisted). All data & keys are encrypted in the browser, so the 
server only sees ciphertext. It focuses on businesses and will be marketed as 
Software-as-a-Service. It does not provide anonymity, but focuses on data 
confidentiality.

Technology wise, it consists of a thin server side written in Twisted & 
ejabberd and a fat js client that is based on Backbone.js. Encryption uses 
solely SJCL. In particular AES256 is used to encrypt the data, while El Gamal 
ecc is used to share keys among members of a team. We are working hard on 
ensuring a good security level and the injection attacks that Cooper mentioned 
are all fixed. We have not yet had an independent security audit, but will 
hopefully do so as soon as we can afford one.

We are aware of the potential problems of serving js. We will eventually ship 
an installable app, but at the moment, with daily updates, ease of deployment 
wins. That said, we also had a few interesting discussion with Mozilla folks 
discussing potential ways of ensuring the authenticity of served js. It is a 
direction we would like to explore in the future.

With regards to open-source: Crypho has been initially developed as 
closed-source. However we both have been working in open-source for years and 
during our trip to the US we decided to switch direction and open-source the 
project. This will take time and will happen gradually. There are parts of the 
app that are legacy code, and some have commercial licenses. As we progress 
through removing them we hope to be releasing steadily components and 
eventually the whole app.

Our focus at the moment is finding our market fit. This unfortunately slows 
down everything else and eats up most of our time, but to code we need a 
salary, so please bear with us :)

If any of you would like to try it out please go ahead. Needless to say, this 
is not to be used as life-critical tool, but we sure appreciate feedback ;)

-- 
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

Re: [liberationtech] Crypho

[Cooper Quintin]

Nadim,
It seems like Cryptocat has a browser plugin, which I though offers more
security than just delivering js straight from the server to the
browser.  I am incorrect in my assumption?
The other difference between this and Cryptocat is, as Jason mentioned,
the fact that it uses strong authentication, where Cryptocat is more
oriented toward anonymity and privacy.
For what it's worth, I would prefer to use Cryptocat over Crypho for
most of the use cases I am interested in.

Cooper Quintin
PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA

On 03/22/2013 02:03 PM, Nadim Kobeissi wrote:
> How is this any different from Cryptocat?
> 
> 
> NK
> 
> 
> On Fri, Mar 22, 2013 at 4:59 PM, Cooper Quintin
> mailto:coo...@radicaldesigns.org>> wrote:
> 
> I had a chance to try out crypho a couple of weeks ago at a demo they
> put on at noisebridge.  I have some concerns about it, namely the
> delivery of crypto code over javascript without any sort of verification
> of it's authenticity (via browser plugin, etc.), since this point has
> already been discussed to death on this list however, I do not wish to
> re-open that debate.
> I managed to find a couple of javascript injection attacks in the beta
> already, though the developer assures me that they are working on fixing
> all the bugs right now, still the lack of attention to basic web
> security at such an early stage is concerning.
> That aside it seems okay, though I have some worries about side channel
> attacks and the fact that it hasn't been peer reviewed as far as I can
> tell yet.
> It does seem like an interesting project though, with some smart people
> behind it. I am looking forward to seeing the code once they open
> source it.
> 
> Cooper Quintin
> PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA
> 
> On 03/22/2013 01:48 PM, R. Jason Cronk wrote:
> > Anybody know the people who are doing this?  http://www.crypho.com/
> >
> > It's still in beta, so I'm assuming they are working out bugs prior to
> > releasing the code which they say they will do. See
> > http://www.crypho.com/faq.html
> >
> >
> >   Is it Open-Source?
> >
> > Yes! We are reviewing the source code for release. It will be
> > available under an OSI approved license in the near future.
> >
> >
> >
> >
> >
> > *R. Jason Cronk, Esq., CIPP/US*
> > /Privacy Engineering Consultant/, *Enterprivacy Consulting Group*
> > http://enterprivacy.com>>
> >
> >   * phone: (828) 4RJCESQ
> >   * twitter: @privacymaverick.com 
> >   * blog: http://blog.privacymaverick.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
> 
> 
> 
> 
> --
> 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

Re: [liberationtech] Crypho

[R. Jason Cronk]

Nadim,

The only major difference I see (assuming you're asking about the 
product and not the threats Cooper lays out) is the persistence. It 
appears you can set up projects and store encrypted data on their 
servers. This certainly opens you up to other threats but I don't see it 
serving the same market as CryptoCat, namely it's going after a business 
audience that just doesn't want Google having all their files/chats/etc 
in the clear on some server somewhere whereas my take on CryptoCat is 
that it facilitates secure non-persistent multiparty chat.


Oh, and the two factor authentication is interesting for login is 
interesting.


Jason


On 3/22/2013 5:03 PM, Nadim Kobeissi wrote:

How is this any different from Cryptocat?


NK


On Fri, Mar 22, 2013 at 4:59 PM, Cooper Quintin 
mailto:coo...@radicaldesigns.org>> wrote:


I had a chance to try out crypho a couple of weeks ago at a demo they
put on at noisebridge.  I have some concerns about it, namely the
delivery of crypto code over javascript without any sort of
verification
of it's authenticity (via browser plugin, etc.), since this point has
already been discussed to death on this list however, I do not wish to
re-open that debate.
I managed to find a couple of javascript injection attacks in the beta
already, though the developer assures me that they are working on
fixing
all the bugs right now, still the lack of attention to basic web
security at such an early stage is concerning.
That aside it seems okay, though I have some worries about side
channel
attacks and the fact that it hasn't been peer reviewed as far as I can
tell yet.
It does seem like an interesting project though, with some smart
people
behind it. I am looking forward to seeing the code once they open
source it.

Cooper Quintin
PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA

On 03/22/2013 01:48 PM, R. Jason Cronk wrote:
> Anybody know the people who are doing this? http://www.crypho.com/
>
> It's still in beta, so I'm assuming they are working out bugs
prior to
> releasing the code which they say they will do. See
> http://www.crypho.com/faq.html
>
>
>   Is it Open-Source?
>
> Yes! We are reviewing the source code for release. It will be
> available under an OSI approved license in the near future.
>
>
>
>
>
> *R. Jason Cronk, Esq., CIPP/US*
> /Privacy Engineering Consultant/, *Enterprivacy Consulting Group*
> http://enterprivacy.com>>
>
>   * phone: (828) 4RJCESQ
>   * twitter: @privacymaverick.com 
>   * blog: http://blog.privacymaverick.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




--
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



*R. Jason Cronk, Esq., CIPP/US*
/Privacy Engineering Consultant/, *Enterprivacy Consulting Group* 



 * phone: (828) 4RJCESQ
 * twitter: @privacymaverick.com
 * blog: http://blog.privacymaverick.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

Re: [liberationtech] Crypho

[Brian Conley]

"Crypho is a team collaboration tool, comparable to Basecamp and Yammer. It
provides a real-time persistent team chat, collaborative document editing
and file sharing. Unlike comparable tools, all data is encrypted before
leaving the browser, with encryption keys held only by the team members. It
is impossible for anyone without the keys to decrypt your data."

"collaborative document editing and file sharing."

that's how, no?

B

On Fri, Mar 22, 2013 at 2:03 PM, Nadim Kobeissi  wrote:

> How is this any different from Cryptocat?
>
>
> NK
>
>
> On Fri, Mar 22, 2013 at 4:59 PM, Cooper Quintin  > wrote:
>
>> I had a chance to try out crypho a couple of weeks ago at a demo they
>> put on at noisebridge.  I have some concerns about it, namely the
>> delivery of crypto code over javascript without any sort of verification
>> of it's authenticity (via browser plugin, etc.), since this point has
>> already been discussed to death on this list however, I do not wish to
>> re-open that debate.
>> I managed to find a couple of javascript injection attacks in the beta
>> already, though the developer assures me that they are working on fixing
>> all the bugs right now, still the lack of attention to basic web
>> security at such an early stage is concerning.
>> That aside it seems okay, though I have some worries about side channel
>> attacks and the fact that it hasn't been peer reviewed as far as I can
>> tell yet.
>> It does seem like an interesting project though, with some smart people
>> behind it. I am looking forward to seeing the code once they open source
>> it.
>>
>> Cooper Quintin
>> PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA
>>
>> On 03/22/2013 01:48 PM, R. Jason Cronk wrote:
>> > Anybody know the people who are doing this?  http://www.crypho.com/
>> >
>> > It's still in beta, so I'm assuming they are working out bugs prior to
>> > releasing the code which they say they will do. See
>> > http://www.crypho.com/faq.html
>> >
>> >
>> >   Is it Open-Source?
>> >
>> > Yes! We are reviewing the source code for release. It will be
>> > available under an OSI approved license in the near future.
>> >
>> >
>> >
>> >
>> >
>> > *R. Jason Cronk, Esq., CIPP/US*
>> > /Privacy Engineering Consultant/, *Enterprivacy Consulting Group*
>> > 
>> >
>> >   * phone: (828) 4RJCESQ
>> >   * twitter: @privacymaverick.com
>> >   * blog: http://blog.privacymaverick.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
>>
>
>
> --
> 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
>



-- 



Brian Conley

Director, Small World News

http://smallworldnews.tv

m: 646.285.2046

Skype: brianjoelconley
--
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

Re: [liberationtech] Crypho

[Nadim Kobeissi]

How is this any different from Cryptocat?


NK


On Fri, Mar 22, 2013 at 4:59 PM, Cooper Quintin
wrote:

> I had a chance to try out crypho a couple of weeks ago at a demo they
> put on at noisebridge.  I have some concerns about it, namely the
> delivery of crypto code over javascript without any sort of verification
> of it's authenticity (via browser plugin, etc.), since this point has
> already been discussed to death on this list however, I do not wish to
> re-open that debate.
> I managed to find a couple of javascript injection attacks in the beta
> already, though the developer assures me that they are working on fixing
> all the bugs right now, still the lack of attention to basic web
> security at such an early stage is concerning.
> That aside it seems okay, though I have some worries about side channel
> attacks and the fact that it hasn't been peer reviewed as far as I can
> tell yet.
> It does seem like an interesting project though, with some smart people
> behind it. I am looking forward to seeing the code once they open source
> it.
>
> Cooper Quintin
> PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA
>
> On 03/22/2013 01:48 PM, R. Jason Cronk wrote:
> > Anybody know the people who are doing this?  http://www.crypho.com/
> >
> > It's still in beta, so I'm assuming they are working out bugs prior to
> > releasing the code which they say they will do. See
> > http://www.crypho.com/faq.html
> >
> >
> >   Is it Open-Source?
> >
> > Yes! We are reviewing the source code for release. It will be
> > available under an OSI approved license in the near future.
> >
> >
> >
> >
> >
> > *R. Jason Cronk, Esq., CIPP/US*
> > /Privacy Engineering Consultant/, *Enterprivacy Consulting Group*
> > 
> >
> >   * phone: (828) 4RJCESQ
> >   * twitter: @privacymaverick.com
> >   * blog: http://blog.privacymaverick.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
>
--
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

Re: [liberationtech] Crypho

[Cooper Quintin]

I had a chance to try out crypho a couple of weeks ago at a demo they
put on at noisebridge.  I have some concerns about it, namely the
delivery of crypto code over javascript without any sort of verification
of it's authenticity (via browser plugin, etc.), since this point has
already been discussed to death on this list however, I do not wish to
re-open that debate.
I managed to find a couple of javascript injection attacks in the beta
already, though the developer assures me that they are working on fixing
all the bugs right now, still the lack of attention to basic web
security at such an early stage is concerning.
That aside it seems okay, though I have some worries about side channel
attacks and the fact that it hasn't been peer reviewed as far as I can
tell yet.
It does seem like an interesting project though, with some smart people
behind it. I am looking forward to seeing the code once they open source it.

Cooper Quintin
PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA

On 03/22/2013 01:48 PM, R. Jason Cronk wrote:
> Anybody know the people who are doing this?  http://www.crypho.com/
> 
> It's still in beta, so I'm assuming they are working out bugs prior to
> releasing the code which they say they will do. See
> http://www.crypho.com/faq.html
> 
> 
>   Is it Open-Source?
> 
> Yes! We are reviewing the source code for release. It will be
> available under an OSI approved license in the near future.
> 
> 
> 
> 
> 
> *R. Jason Cronk, Esq., CIPP/US*
> /Privacy Engineering Consultant/, *Enterprivacy Consulting Group*
> 
> 
>   * phone: (828) 4RJCESQ
>   * twitter: @privacymaverick.com
>   * blog: http://blog.privacymaverick.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

[liberationtech] Crypho

[R. Jason Cronk]

Anybody know the people who are doing this?  http://www.crypho.com/

It's still in beta, so I'm assuming they are working out bugs prior to 
releasing the code which they say they will do. See 
http://www.crypho.com/faq.html



 Is it Open-Source?

   Yes! We are reviewing the source code for release. It will be
   available under an OSI approved license in the near future.





*R. Jason Cronk, Esq., CIPP/US*
/Privacy Engineering Consultant/, *Enterprivacy Consulting Group* 



 * phone: (828) 4RJCESQ
 * twitter: @privacymaverick.com
 * blog: http://blog.privacymaverick.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