Show HN: CryptPage, experiment in online publishing using client side encryption | Hacker News Reader

Show HN: CryptPage, experiment in online publishing using client side encryption

cryptpage.com

16 pointssamwillis25 comments

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?

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.

Random question: where did this particularly implementation of CTR mode come from?

Its the one from http://www.movable-type.co.uk/scripts/aes.html

I am considering moving to the http://code.google.com/p/crypto-js/ version as I'm not sure that it is currently producing keys in the best way.

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

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

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

just write the Mozilla and Chrome extensions to expose a C implementation of PGP/GPG to Javascript?

Would that really help? The same hypothetical malicious server admin could simply alter the JS to not call the code from the extension and the average user would be none the wiser. What am I missing?

If the crypto operations are run in browser elements that are obviously part of the browser chrome and not the webpage, then they should be safe. As long as the end user knows the difference.

Eg, if the end user knows they can safely write a message and hit an encrypt button in a particular window opened by the browser, but not just any old textarea on the webpage.

This isn't about keeping the content private for the users. This is all about removing the server's ability to read the content, to attempt to absolve the server owner of liability for that content. Therefore the server has no incentive to lie about the encryption algorithm used.

This is how HushMail works for email. Except they can be (and have been) compelled to send backdoored code to individual end-users in order to access their users keys and hand over the unencrypted data to their government.

but this does not guarantee that the server won't read that more than stating "I will not read your data".

the server doesn't want to read the content! Otherwise they would just store it in the clear. If the server can read the content then they are liable if that content infringes copyright. The theory is that if the server cannot read it, they're not liable. I would not like to be the first one to test this strategy out in court however

http://openpgpjs.org/ is an interesting and related project to keep an eye on. Obviously, if it is delivered from a server and run in a client, you can't trust it. I can imagine it being useful for people writing browser addons or nodejs apps though.

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.

Well done. I kind of doubt you can monetize this app on its own (famous last words) but you can certainly gain cred for popularizing the technique.

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.

It would be nice for a box to pop up if the key is not detected in the hash, asking for the decryption key (and password if that's set).

That way, you enable two types of users:

* The "I just don't want the server to have this stored in plaintext" type.

* The "I'll send you the URL now and the key via some secure channel" type.

Also, if you browse incognito, then there shouldn't be a browser history containing the keys.

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

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.

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

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.

Thanks! Fixed

Also, the title tag is "CryptPaste".

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.

Reply on news.ycombinator.com