

Show HN: CryptPage, experiment in online publishing using client side encryption - samwillis
https://cryptpage.com/

======
tptacek
This has some basic crypto issues, but that doesn't matter much because like
the related "server proof" web crypto apps, all the security of this system
depends on the server not lying to you about the AES implementation it's
sending in its JS.

A malicious server admin or anybody who pops this server can read people's
content just as easily as if it hadn't been encrypted at all.

People obviously enjoy writing these kinds of applications, and more power to
them if they're learning from the experience, but I just don't get the
attraction. Could someone consider taking the energy they were going to invest
in shoehorning 1/8th of PGP into Javascript and just write the Mozilla and
Chrome extensions to expose a C implementation of PGP/GPG to Javascript?

~~~
samwillis
Hi Thomas, thanks for the feedback, I was hoping you would turn up...

Its very true, if someone broke into the server (or I was malicious) they
could replace the js with code that after decrypting the page sends it onto
somewhere else in plain text. I did consider that situation when putting it
together and added the ssl security to help prevent MITM attacks.

I don't really intend this to be a way to share content in a secure manner, as
you said there are much better tools for that. It is really an experiment in
how you could built a tool where the server doesn't know, because it doesn't
want to, what content people have submitted to the site. As you know the url
fragment is not sent to the server and so I never see the encryption key.

~~~
Zikes
When the URL is linked, wouldn't the fragment be sent as a referrer when
loading page resources?

~~~
phpnode
no, the fragment is never sent to the server by the browser.

~~~
samwillis
Exactly, its not included in the referrer header, only the resource location
is.

------
samwillis
I have been working on this on and off for a couple of months and finally
after seeing a similar idea submitted last week
(<http://news.ycombinator.com/item?id=3832269>) I finished it over the
weekend. It's a bit of an experiment with the idea that the server doesn't
need or want to know what the content is that is being posted by the users,
the page is encrypted and decrypted in the users browser using a key in the
url's fragment identifier.

You can see an example document here:
<https://cryptpage.com/Cvni#GTP9LXTSI1LV5FKlkO8Dpd>

The main difference with this to the one last week is that by building it
around a Markdown editor it becomes a platform for publishing nicely formatted
content on-line in a free and secure manner.

I am not sure who the market for it is yet and I built it mostly to scratch an
itch and learn some new tools. I would love to hear what you think!

Some possible things on the to-do list for it:

\- Using the HTML5 file system API and DataURL's to allow people to select an
image on their computer to embed into the page. Although I am a little nervous
about this and how it could be abused.

\- Have an option of a wysiwyg editor for editing the pages.

\- Allow optional commenting on pages in a way that is also encrypted.

\- Allow people to attach small files again using the HTML5 file system API
and DataURL's.

~~~
tptacek
The URL fragment identifier seems like exactly the last place you'd want to
stick a crypto key, in that it's displayed in the URL bar and in no way
protected by the browser.

~~~
pwpwp
I don't know. The cryptographer Zooko Wilcox-O'Hearn keeps cryptographic
capabilities in his browser bookmarks, too.

[http://www.mail-
archive.com/cryptography@metzdowd.com/msg107...](http://www.mail-
archive.com/cryptography@metzdowd.com/msg10786.html)

~~~
tptacek
I have no idea what this appeal to authority is supposed to mean in this
particular context. If Zooko is bookmarking crypto keys, he too is doing
something dumb.

The URL fragment identifier is what it is. It is _not_ a security feature.

~~~
tptacek
I think I might have taken that exchange too literally. :)

------
switz
Saw the same idea submitted on HN last week. Nice implementation.

Note – you have a misspelling > _TIP: You can link to other _CpyptPage_
documents and as the URL is encrypted with the page it is stored securely._

~~~
xorbyte
Also, the title tag is "CryptPaste".

~~~
samwillis
Oops, that was a previous name I was working under. Its actually what the
underlying django app on the server is called...

Fixing it now.

