Show HN: CryptoNote is an open source, encrypted, one time view message app(cryptonote.org)
cryptonote.org
Show HN: CryptoNote is an open source, encrypted, one time view message app
https://cryptonote.org/
41 comments
Do you believe there is zero value to client-side JavaScript crypto?
There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter.
EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course).
EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.
There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter.
EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course).
EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.
Client-side crypto in JS has value if and only if the following conditions are all met:
1) The application receives no HTML, CSS, Javascript, or code interpreted by plugins from a server in the same context (e.g. not an iframe) as the crypto code.
2) All assets that are run in the context of the crypto code are fixed and signed. No unsigned javascript code (generated at runtime, passed from a server or input to the app, whatever) is permitted to run in any way in that context.
3) The code as signed is completely transparent. It must be possible to audit the code as it would be run, and be able to 'quarantine' updates.
Without all of these things being met, client-side crypto in the browser is completely untrustable. These conditions have never been met.
1) The application receives no HTML, CSS, Javascript, or code interpreted by plugins from a server in the same context (e.g. not an iframe) as the crypto code.
2) All assets that are run in the context of the crypto code are fixed and signed. No unsigned javascript code (generated at runtime, passed from a server or input to the app, whatever) is permitted to run in any way in that context.
3) The code as signed is completely transparent. It must be possible to audit the code as it would be run, and be able to 'quarantine' updates.
Without all of these things being met, client-side crypto in the browser is completely untrustable. These conditions have never been met.
If you're that paranoid, you shouldn't be using a hosted service at all. There could be a guy right outside your house intercepting your cable line and filtering all traffic to and from cryptonote.org and routing it to his own instance of the app. That doesn't mean that cryptonote is responsible for that happening.
This is everything that is wrong with cryptography and privacy. Simply put, if your data is important enough to use cryptography on it, why would you want to use crypto that is broken by design?
The whole point of a well-designed, well-implemented cryptosystem is that even if there is a dude sitting outside my house, he's not getting a single bit of my data. This is just as true for government secrets as it is sending a recipe to my mother. This service is broken, as all such services are. Bad crypto is never, ever, ever excusable.
The whole point of a well-designed, well-implemented cryptosystem is that even if there is a dude sitting outside my house, he's not getting a single bit of my data. This is just as true for government secrets as it is sending a recipe to my mother. This service is broken, as all such services are. Bad crypto is never, ever, ever excusable.
No, he can't. Not without a valid SSL certificate for cryptonote.org. Sure, there are problems with CAs, but it would nevertheless be very difficult to obtain such a certificate.
but it would nevertheless be very difficult to obtain such a certificate.
Not if you're the government. Just send the root CA a "National Security Letter" and bob's yer uncle.
Not if you're the government. Just send the root CA a "National Security Letter" and bob's yer uncle.
We were are talking about a random guy in front of the house, not the government.
He can put his root CA into the browser, certainly when the browser is first installed, and perhaps with the next update. (Are automatic browser updates encrypted?)
But this is besides the point of in browser crypto. The interesting thing is, you need a reliable delivery platform for your crypto code, but this implies you have a TLS connection. So either a third party can break your TLS and modify the crypto code, or your connection is secure in the first place. The scenarios you are then dealing with, is that the server is potentially malicious, but a malicious server just serves broken crypto.
[Edit spelling]
But this is besides the point of in browser crypto. The interesting thing is, you need a reliable delivery platform for your crypto code, but this implies you have a TLS connection. So either a third party can break your TLS and modify the crypto code, or your connection is secure in the first place. The scenarios you are then dealing with, is that the server is potentially malicious, but a malicious server just serves broken crypto.
[Edit spelling]
Or (in enough cases to be a valid concern), not without using sslstrip. Which is trivial.
If you are the recipient of the link, SSL can't be stripped.
Even if you are an author, assuming you have visited the site over SSL at least once, then it can't be stripped on future visits since the site seems to use HSTS.
Even if you are an author, assuming you have visited the site over SSL at least once, then it can't be stripped on future visits since the site seems to use HSTS.
It is trivial to strip links being sent to a user over unsecured channels.
There are many things that can mitigate an sslstrip style attack, but coverage from those things is patchy.
There are many things that can mitigate an sslstrip style attack, but coverage from those things is patchy.
Thanks, and that is absolutely true. That's why it's open source: I want people to host their own version if they don't trust me https://github.com/alainmeier/cryptonote
But if you need to trust the server (and you do), then the client-side encryption is 100% pointless. You might as well encrypt on the server with safe, sane, battle-hardened code.
At the end of the day, XSS, rogue hosts, etc can own this even if the person "running the show" doesn't want it to happen.
Edit: I note that you now link to nadim's response to http://www.matasano.com/articles/javascript-cryptography...; -- you reaaaaally should consider linking to the original, or perhaps to https://news.ycombinator.com/item?id=5768837 wherein that article is torn to shreds. JS cryptography is very, very dangerous.
At the end of the day, XSS, rogue hosts, etc can own this even if the person "running the show" doesn't want it to happen.
Edit: I note that you now link to nadim's response to http://www.matasano.com/articles/javascript-cryptography...; -- you reaaaaally should consider linking to the original, or perhaps to https://news.ycombinator.com/item?id=5768837 wherein that article is torn to shreds. JS cryptography is very, very dangerous.
Hm, yes, added a warning message, good idea. As for your other thoughts, I completely agree. It's a work-in-progress and I figured the best way to figure out what's wrong is to learn from others.
Edit: Also added a link to that discussion next to Nadim's post.
Edit: Also added a link to that discussion next to Nadim's post.
Awesome, glad to hear it!
This is neat, and the I really like the UI too.
I made something similar (except the one-time view part) not too long ago just to experiment with storing the base64 encoded message into the URL. It also has an option to add a key, which uses a javascript implementation of blowfish.
http://alfg.co/jot
https://github.com/alfg/jot
Since the message is stored within the URL, there's no backend needed, though that means the message needs to be short since most modern browsers can only support up to about 2000 characters in the URL and the messages can generate a long base64 string rather quickly.
I made something similar (except the one-time view part) not too long ago just to experiment with storing the base64 encoded message into the URL. It also has an option to add a key, which uses a javascript implementation of blowfish.
http://alfg.co/jot
https://github.com/alfg/jot
Since the message is stored within the URL, there's no backend needed, though that means the message needs to be short since most modern browsers can only support up to about 2000 characters in the URL and the messages can generate a long base64 string rather quickly.
I experimented with that too, but the character limitation was what made me go server-side. Cool project though, works really well
Looks useful. I am seeing though
message[pre_encryption]
with my unencrypted message in the POST data?
message[pre_encryption]
with my unencrypted message in the POST data?
Good catch, I'll take that out right now thanks.
Edit: fixed. If anybody thinks of anything else, please let me know. This is as much of a learning exercise as anything for me.
Edit: fixed. If anybody thinks of anything else, please let me know. This is as much of a learning exercise as anything for me.
This whole thread is like a textbook example of why people like me (breakers) have itchy trigger fingers when it comes to people building cryptography features.
I'm glad if this has been a good learning experience for you (may I suggest another?†), but real secure systems aren't, to steal a phrase from Richard Stallman, "debugged into existence": they start from a foundation of a secure, well-considered design and are verified piece by piece as the system is assembled.
† http://www.matasano.com/articles/crypto-challenges
I'm glad if this has been a good learning experience for you (may I suggest another?†), but real secure systems aren't, to steal a phrase from Richard Stallman, "debugged into existence": they start from a foundation of a secure, well-considered design and are verified piece by piece as the system is assembled.
† http://www.matasano.com/articles/crypto-challenges
I didn't know about those, they look very cool. Thanks for the link.
(His company produced the challenges also, for what it's worth.)
The password is sent in plaintext in the POST body.
Indeed, that one is listed in the known vulnerabilities section of the repo. Thank you for trying it out
Thanks for making it! Computer security is a fascinating field that I've only begun to dive into recently.
Also see: https://oneshar.es
I created a similar web application in Django as part of a College minor project last year. Best part was implementing the AES algorithm ourselves. :D
I created a similar web application in Django as part of a College minor project last year. Best part was implementing the AES algorithm ourselves. :D
You felt comfortable implementing AES yourself?
For learning purpose, why not? Taught me a lot more about crypto than I would have by simply reading about it. Of course, it wasn't meant for real-world use. :)
> How comfortable did you feel with AES when you were done with the project? Could you try to put into a sentence or two what you (i) didn't know about using AES before you did the project, and (ii) knew at the end of the project?
Frankly, I didn't know much about AES (or encryption in general) before I started working on the project. My only direct encounter with encryption was ROT13 in IRC channels. I felt that without doing at least some "difficult" task myself, the application would be a lot more easy, and nothing new in it for me to learn. So I read how AES works, and created a small implementation myself.
Afterwards, I had a bit more understanding of all the moving parts of AES. Gained a huge appreciation for the algorithm and security in general. Now that I think about it, I guess you don't really have to implement it yourself in order to understand it, but I did it anyway, because, well, I felt like it.
It was just a toy project tbh. I certainly don't consider myself an expert on the algorithm, and will still trust tried and tested library implementations over my own. But now I know what's going on under the hood.
Frankly, I didn't know much about AES (or encryption in general) before I started working on the project. My only direct encounter with encryption was ROT13 in IRC channels. I felt that without doing at least some "difficult" task myself, the application would be a lot more easy, and nothing new in it for me to learn. So I read how AES works, and created a small implementation myself.
Afterwards, I had a bit more understanding of all the moving parts of AES. Gained a huge appreciation for the algorithm and security in general. Now that I think about it, I guess you don't really have to implement it yourself in order to understand it, but I did it anyway, because, well, I felt like it.
It was just a toy project tbh. I certainly don't consider myself an expert on the algorithm, and will still trust tried and tested library implementations over my own. But now I know what's going on under the hood.
This is interesting. Thanks for playing along with me.
Can I ask another question? Now that you've implemented the algorithm, would you feel more comfortable employing AES encryption on a future project, or less comfortable?
Can I ask another question? Now that you've implemented the algorithm, would you feel more comfortable employing AES encryption on a future project, or less comfortable?
Is your question specific to AES itself, or just my own implementation? If it's the latter, I'm hesitant to say more comfortable. It's not something you can just implement in a couple days from memory. There's always a chance something might go wrong.
If you mean will I be more comfortable in using the algorithm itself, then definitely yes. At least for the moment. IIRC, there have been some partially successful attacks against AES, but nothing that has managed to break it fully.
If you mean will I be more comfortable in using the algorithm itself, then definitely yes. At least for the moment. IIRC, there have been some partially successful attacks against AES, but nothing that has managed to break it fully.
How comfortable did you feel with AES when you were done with the project? Could you try to put into a sentence or two what you (i) didn't know about using AES before you did the project, and (ii) knew at the end of the project?
What role does AES serve in your application? Your site is just sending plaintext wrapped in SSL.
I'm confused by that as well. The POST data sends a nonce value but the message itself is in plaintext... not even Base64..
Why is the password stored in plain text "for now"? What is so hard about running bcrypt or pbkdf2 against the password before storing it in the database?
I was just getting this out as soon as possible. There's nothing hard about it, I just wanted to put it out there and keep working on it.
Just use vanish.io
There are a lot of single view self destruct sites, but I wanted to make a new one because I wanted to let people host their own instead of relying on the site provider.
The server dictates what's run on the page, and thus can access the plaintext data in any way it sees fit. The trust model is fundamentally broken in client-side crypto of this nature.
Edit with two more thoughts: 1) Even if you trust the person running the service, how much do you trust the other users (who may be using stored XSS to compromise your data)? How much do you trust the hosting service behind it, if there is one? 2) Am I the only one that finds it massively irresponsible to not have a huge flashing "DO NOT TRUST THIS UNTIL IT'S BATTLE HARDENED" sign over it? This goes for just about every project of this nature.
Edit with a final thought: Most of the time, we think in terms of "relative goodness". A good car is better than a bad car, but a bad car is still better than no car at all. This logic completely breaks when it comes to crypto. Simply put, bad crypto (and bad implementations) when released on the world put lives at risk. This should be taken seriously.
It's one thing to build a project for learning (and please, please do!) but cover every friggin' surface you can with disclaimers.