

Show HN: aes.io - secure storage/collaboration with client-side JS crypto - trekkin
https://aes.io

======
Piskvorrr
Oblig: JavaScript crypto considered harmful.
<http://www.matasano.com/articles/javascript-cryptography/>

The site doesn't address any of the concerns. Why? Well, because they can't.
Client-side JS is fundamentally, unfixably insecure.

~~~
trekkin
The article has many points, but it seems that they can be grouped together
around three themes:

1\. very easy for MITM-type attacks: this is negated by using SSL

2\. JavaScript is too "malleable" for crypto - this argument is not very
clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is
not "infected", by using server-side tools like signatures and SSL? This is
highly debatable...

3\. server breaches easily propagate to users: this is a real issue, but it is
a real issue with many products that auto-update themselves, such as OSes
(with patches/updates), browsers, anti-viruses, etc. Thus although this is a
valid concern, it is part of everyday life of most Internet users,and not
something JS crypto is specifically bad at.

~~~
Piskvorrr
In other words, "I don't understand #2, so let's assume it's not a problem and
handwave it away." Alas, it is a problem, and _a_ critical one. Pray tell, how
do you check the VM, _from inside the VM sandbox_? Guess what: you have no way
to do that, not in JavaScript. That's another chicken-and-egg problem which is
insurmountable with client-side, in-page JS.

~~~
trekkin
I cannot do that from inside the sandbox, but as I completely control the
page, not just one script on it, I can be reasonably sure no rogue script is
running on it (by using SSL).

I've read the Matasano article, don't assume I didn't. Most of the points in
it are negated by controlling the page 100% and using SSL.

~~~
tptacek
I'm confused. In way does your application protect users against _you_? You
control the code that handles the users encryption secrets. Your users have no
effective way to police you.

Why not just have the users send you their plaintext, and rely on SSL/TLS for
the rest of your security? It seems like that provides effectively the same
security.

------
justauser
Trekkin posted yesterday in the discussion regarding Microsoft's SkyDrive
(<http://news.ycombinator.com/item?id=4265621>) and not being familiar with
the project I asked him to post a ShowHN so more folks could chime in
regarding the use of clientside JS cryptography.

I asked about the library/implementation used and it is BouncyCastle
compiled/convertered to JS using GWT.

The common discussion/blog references I've also pointed out but for everyone
else have a look at these: [http://rdist.root.org/2010/11/29/final-post-on-
javascript-cr...](http://rdist.root.org/2010/11/29/final-post-on-javascript-
crypto/) and <http://www.matasano.com/articles/javascript-cryptography/> .

~~~
trekkin
Thank you! The Matasano article, as I mentioned in another comment, for some
reason assumes that SSL is not used, which is not the case with aes.io.

~~~
tptacek
The article does not assume SSL isn't used. The article addresses JS
cryptosystems in the presence of HTTPS/TLS from top to bottom.

But we also go out of our way to discuss JS cryptography as an _alternative_
to HTTPS, because that is how many people use it; for instance, to do
challenge-response authentication for "secure login" without needing SSL.

But that's a sideshow on this thread. The article squarely addresses exactly
the application you've built, and in detail.

~~~
trekkin
OK, let's discuss the article in detail. :)

The article lists three reasons for why "JS crypto is bad" at the beginning:

\- Secure delivery of Javascript to browsers is a chicken-egg problem. \-
Browser Javascript is hostile to cryptography. \- The "view-source"
transparency of Javascript is illusory.

The first issue is addressed by using SSL and controlling the page 100%. The
third issue becomes a matter of trust, as many users trust closed-source
vendors, so in an environment where closed-source vendors are truested (e.g. a
typical accounting firm), the third issue becomes not about JS crypto but
about vendor reliability.

That leaves the second issue. The article expands it as:

\- The prevalence of content-controlled code. \- The malleability of the
Javascript runtime. \- The lack of systems programming primitives needed to
implement crypto. \- The crushing weight of the installed base of users.

The first and second sub-issues, again, are more or less addressed by using
SSL and controlling the page, I believe. One can argue that because JS is so
"malleable", it is very easy to add malicious code to a page. Yes, it is easy
if you have access to it (via third-party scripts/XSS), but it is _harder_ to
infect a JS crypto page that is properly set up than a regular online-banking
page, for example, as most online banking pages have links to third-party
advertising (often over plain HTTP!). So in the world where people and
companies do online banking, the "malleability" does not seem to add a lot of
issues.

The third sub-issue is being addressed in HTML5 and/or, via SSL, round-trips
to the server (for random seeding, for example).

The fourth issue is, again, not much different from online banking.

In summary, it seems we are using somewhat different criteria of what "secure
JS crypto" means. You seem to be saying that storing data in aes.io is less
secure than in a truecrypt volume. I agree 100%. But what I am saying is that
for an accounting firm that does online banking on a daily basis, using aes.io
as opposed to a cloud collaboration service without client-side encryption
would probably be a great idea.

~~~
tptacek
The rebuttals you're making are addressed in the article you're commenting on,
in detail.

The problem here is that the core value proposition of services like this one
are "you can put your documents here even if you don't trust the operators".

But that, as it turns out, simply isn't true. You are exactly as reliant on
the operators of aes.io as you are on the operators of Dropbox.

------
abemassry
I went full server side encryption with <https://truefriender.com> I relied on
SSL for the client to server communication. However the user holds a key that
is not stored on the server, so without that key the text on the server is
unreadable, if you try entering an incorrect PIN you can see what I mean.

I've submitted to HN but didn't make the front page, check it out if you're
interested in this stuff.

------
pwpwp
Interesting. How difficult was it to get the Bouncy Castle crypto lib to
compile with GWT?

~~~
trekkin
Not difficult in theory - classes not supported by GWT (such as iostreams) are
easily cut out; but in practice many array operations inside BigInteger needed
to be carefully tweaked to work well when compiled into JS.

------
Toshio
This site more or less does the same thing as deadrop.us so why do I need to
sign up?

~~~
trekkin
deadrop.us seems to be focused exclusively on short messages. aes.io, in
addition to messages, supports file uploads and sharing, for example...

