
Show HN: A note taking application that encrypts in the browser - billowycoat
https://github.com/moyaproject/notes
======
taf2
Very cool - the issue with believing that encrypting on the client is safer
then relying a secure transport and a secure server is that the code on the
client doing that encryption, came from the server. That said, it may still be
an interesting layer of security to layer into your application. After all
security is more about layers then absolutes.

~~~
skrebbel
This is the usual argument in HN when client-side encryption comes up, and I
have a question about it.

Doesn't virtually all encryption on user computers come from servers? I mean,
Chrome updates itself from a server, and I first downloaded it from the same
server. Google (or anyone breaking in to Google) could maliciously break the
SSL code in my browser and I'd never even know it had been updated.

Likewise, I downloaded dropbox and putty and ssh.exe from servers, all apps I
installed on my phone came from a server and were put there by people I don't
know at all.

Why is in-browser encryption considered so different that even smart people
like tptacek get all worked up about it? Is it that browser apps get
"reinstalled" on every use, and not "only" when an autoupdater or user detects
a new version? If so, can I use appcache to achieve the same and enjoy the
exact same security as I'd get in an installed app(lication)?

In short, what am I missing?

(note to the angry security people: I'm not dissing you, I really don't know.
I'd appreciate non-snarky replies)

~~~
losvedir
> Why is in-browser encryption considered so different that even smart people
> like tptacek get all worked up about it?

There's two issues that I can think of.

The first is philosophical, and not technological: in all these examples (e.g.
this post) doing encryption on the client side _gets you nothing_.
Furthermore, although it is in fact exactly as secure as not having client
side encryption, it misleads users into thinking that now the backend can't
read their data, etc.

Assume the server operators are 1) competent and 2) trustworthy. Then let them
use the standard, time-tested technology of SSL to send data in the clear, and
trust them to encrypt it on their end.

If you can't assume (1) and (2) above, remind me why I'm trusting the
javascript code they deliver instead?

The point is, with web apps you have to either trust the provider or not. If
you do, just use SSL. If you don't, then nothing they can provide via
javascript should convince you otherwise. And them providing client side
encryption so that you "don't have to trust them" is infuriatingly wrong.

The second point is technological. Let's say the developers are competent, and
you understand that you have to trust them. Why then should you prefer that
they write the encryption stuff on the backend rather than the frontend? This
one I'm not so clear on and would like to hear more. It makes sense that the
backend is a more controlled environment, but beyond that I don't know.

~~~
walterbell
_> nothing they can provide via javascript should convince you otherwise._

How about javascript that is:

(a) open-source

(b) third-party audited, with a third-party-published hash of the versioned
javascript

(c) verified against the hash at runtime by a browser plugin that consults a
hash directory of audited versions?

~~~
tptacek
That's great, if it's running in an extension that is only downloaded once and
firewalled off from the DOM. Otherwise, every single HTTP request your browser
makes can potentially override it.

~~~
walterbell
What design or implementation changes would you recommend for a future browser
or HTTP spec, to enable 3rd-party validation of scripts and notification to
the user when new, unvalidated scripts are requested?

------
jacques_chester
You may have seen this: [http://matasano.com/articles/javascript-
cryptography/](http://matasano.com/articles/javascript-cryptography/)

The brief problem statement is:

Either you're on SSL, in which case, you have encryption from the client to
the server.

Or you don't have SSL, and a MITM attack can substitute your javascript with
anything, rendering the scheme unsafe.

~~~
maaaats
You forget one case: Here, the server will never know the content of the
encrypted data.

~~~
new299
Unless the attacker has access to the server for a period of time, in which
case they just replace the JS with their own code.

Seems like there should be a way to sign the JS offline (away from the server)
and prevent that, but I don't think there's any browser mechanism for that. I
think that would be neat though.

------
ivanhoe
Turning the client-side code into a browser extension would lessen the chances
of MITM attacker tampering with the code.

------
steakejjs
In case people are interested in the under-the-hood. I just dug in a little
bit and it looks like a library is used that automatically generates IV for
each encrypt, and automatically uses your passphrase, passed through EvpKDF as
the key.

SHA3, Rabbit, and whatever EvpKDF does, I don't actually have time to look at
that.

~~~
colept
On binbox.io, we use a similar library called Stanford Cryptograph JavaScript
Library. It's fast enough that small files decrypt and encrypt within
reasonable times, but it scales poorly to large files.

------
billowycoat
Ask me anything about the implementation. I'm no expert on encryption /
security so there could be holes.

------
gojomo
Could be interesting to allow multiple pre-existing wiki/CMS systems to serve
as backends.

(Potentially, then, you _only_ bring the overlay JS from a trusted source, and
your encrypted notes can live in many places, as visible-but-uninterpretable
'noise' in other systems.)

------
meesterdude
cool! I did something similar with my side project. Users could
encrypt/decrypt text in an editor, and would have to provide a password to
decrypt it on the display page.

Yes, its not 100% secure - you have to trust the JS, which with enough
targeted effort could be swapped out for something malicious. But this does
mean your data at rest is encrypted, which can be very beneficial.

A bullet proof vest doesn't stop all bullets, nor does it protect everywhere.
But people still use them all the time in addition to other solutions.

Still, with all that if you end up with a keylogger on your machine it means
nothing. Air gaping helps a lot but really nothing is totally foolproof - one
can only make it exponentially more difficult to bypass.

------
avyfain
"This note is about a fizzy buzz that went away to become a knight. No one
shall now what the rabbit ate tonight."

