Hacker News new | past | comments | ask | show | jobs | submit login
NoPlainText: One time, browser-encrypted messaging (noplaintext.com)
44 points by zotz on Apr 21, 2012 | hide | past | web | favorite | 38 comments

It uses a 47.6 bit key?

Generated by Math.random()? (According to MDN, that's seeded from the current time...)

Update: Another problem is that there is no message authentication. The server can flip individual bits within the message.

Update: Also, obviously, we have to trust noplaintext.com to send us an uncompromised web page.

But wait! View source!

<script type="text/javascript" async="" src="https://ssl.google-analytics.com/ga.js></script>;

We also have to trust Google, specifically google-analytics.com not to steal the message.

<script type="text/javascript" src="https://crypto-js.googlecode.com/files/2.5.3-crypto-sha1-hma...;


We also have to trust whoever controls the crypto-js project and the people running googlecode.com.

It's even worse than that. The sources of entropy you have available to you in the browser are servers which you obviously can't use in this case and the user which would be a UX disaster.

> We also have to trust whoever controls the crypto-js project and the people running googlecode.com.

And every router between them and googlecode.com (or whatever that resolves to in their DNS situation!)

The link is an HTTPS link so that's not true. You merely have to trust every CA.

I noticed that the generated links default to non-SSL even though SSL seems to work and even when the site itself has been accessed via SSL.

The message you get when running noscript is almost condescending.

Please enable Javascript to use NoPlaintext.

Javascript is an integral part of modern websites and is very easy to enable.

Get used to it. People who make and own web sites do not like noscript users or users who disable JS. For reasons that are perfectly reasonable, too:

- No ads (= no revenue if you rely on ads and get paid per mille)

- No analytics (frustrating when your site is being used in all sorts of interesting ways but your information is limited to log files)

- No behavior layer (great, another intentionally crippled client). You can bring up graceful degradation but I'm fairly positive that trend came as a result of spotty JS support. That era of spotty JS support has mostly come to an end, at least as far as default configurations are concerned.

From the perspective of many (most?) of the sites you'll visit, js-disabled clients are merely leeches. Like bots silently hitting your server logs, slurping up your content for who knows why. (Unless you're otherwise creating content for them, such as posting on HN -- or a paying customer.)

Just my point of view, but I'm willing to bet that other creators feel the same way.

I myself am a 'creator', but I would never think of no-script users as "leeches" or "bots". The web is not some gated community (nor should it ever turn into one), and everyone has the right to browse as they please. If they don't think the value added by my site's interactivity is worthwhile enough for them to enable their javascript, I'd much rather hear why, than present them with a snarky remark about the 'modern web'; that way I can at least try to improve the site's message so that future no-script users feel compelled to use the site as it's meant to be used.

I used to be a no-script user too for a time, and while I stopped using it because it became too inconvenient, I think it's everyone's prerogative to decide whether or not a site can track them or show them ads. It might be annoying for sites whose only means of monetization is ads, but again, the web is free and that's just the nature of the beast.

I seem to find myself tip-toeing through a minefield of things I didn't say or mean to imply. I'm not sure where the gated community thing came from. They aren't even related concepts. (Though I wouldn't mind hearing why you consider them so closely related.) Everyone has the right to browse as they please, I agree with you on that point. I don't think noscript users should get upset when a site owner points out that their client is crippled if the site owner wasn't delicate with their feelings in the process. It's a hindrance and an annoyance (a conclusion that you even shared as a noscript user over time).

>>I think it's everyone's prerogative to decide whether or not a site can track them or show them ads

Or even work properly. (I felt that was important to include too since it's a big deal.)

Gated communities are exclusive by definition, so whenever a site posts up a message saying essentially 'get with the times', I feel that basically treats no-script users as a community that's being excluded. It's largely a semantic/communication issue at this point, but there is a difference between helping someone out by pointing them in the right direction ("oh hey, it seems your javascript is off right now, but if you turn it on for us we can offer you these cool features..."), and saying they aren't welcome here ("why is your javascript off? every modern website uses it!"/"you're taking away from our ad revenue!").

Now I'm not a huge 'graceful degradation' advocate by any means, since a lot of sites (or 'apps' rather) would become totally useless without js, but all those no-script users decided to block javascript for a reason and they know very well what blocking javascript will entail, so I see no reason to be condescending towards them or give them anything more than a simple reminder/value-proposition so that they can turn js on for our sites.

We're probably on the same page, I just think the case against people who block javascript is overstated; these users are a minority, and they can evaluate it on their own whether your site's functionality is worth enabling javascript for.

I know how easy it is to enable, I was the one who disabled it in the first place!

There was a good discussion on this kind of service a while back--check out "Javascript Cryptography Considered Harmful"

HN: http://news.ycombinator.com/item?id=2935220 Direct link: http://www.matasano.com/articles/javascript-cryptography/

If the messaging was peer-to-peer, the objections in that post wouldn't apply quite as much. Then you would connect to the NoPlainText server to download the JS client by HTTPS, and use it to encrypt the direct connections to your messaging partners. I think JS crypto could still sensibly be used for this kind of "separation of trust" problem.

For instance, I am considering a service at the moment which would involve people uploading confidential information. The uploads will be fairly large, so a lot of bandwidth will be required (optimistically assuming it gets traction.) One architecture I am considering is a small dedicated HTTPS server which provides a self-contained webpage-plus-JS program to encrypt the upload and send it for storage on Amazon S3. Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network. The advantage to this architecture is that it will scale arbitrarily but require me to secure only relatively modest dedicated resources, despite being used for transmission of confidential information. Because it uses a dedicated HTTPS server serving a self-contained page doing all the crypto, it avoids tptacek's objections to JS crypto in the browser (E.g., the server can provide the random seed in the JS itself, HTTPS prevents MITM attacks, etc.)

I don't get it. If you're emailing the link anyway, wouldn't someone that intercepts the email have access to the link? Is the point that your recipient opens it before an interceptor does?

I'ts also unclear to me how the encryption scheme is working here. I don't see how it's impossible for the server to decrypt the message when it is sending you everything you need to decrypt it when you click the link. Am I missing something?

I think its aimed at medium priority info where convenience of both parties is a factor. It seems the point is to send information that, although it could still be compromised, you will know if that happens because your recipient won't be able to access the message. So you have peace of mind that there was no silent observation of the info en route. I think if you were trying to send information that you didn't want to be compromised at all, you'd eschew the convenience of this and use proper encryption on the message (both parties PGP keys, etc).

Also, from what I understand, the system requires total trust in the provider's servers to do their job. That is no different than trusting that an anonymous email provider is doing their job (not storing logs, etc) and there's a proven market for that (I think).

The claim of how the server doesn't have the information to decrypt seems valid. The key is computed locally and never sent to the sever. That doesn't make this a good idea, but I see plenty of comments already pointing to the specifics of bad RNG, crypto in Javascript being problematic, etc.

> Is the point that your recipient opens it before an interceptor does?

Yes, the idea is simply to avoid having the sensitive data stored somewhere forever, like on their gmail account. Obviously if you think you have a 3rd party listening in on your on-going conversation, you need something more secure.

I don't know about your second point.

Except it uses crypto written in JavaScript, which is inherently broken.

Isn't it fair to say, though, that all crypto is broken to some degree, and that javascript crypto lies somewhere on that that continuum? Surely AES with a 256 bit key that you've downloaded to your browser and can inspect is better than rot13?

No, it's not fair to say that at all. The website can MITM you at any time, even without changing the crypto code it sends you.

Native crypto clients don't have this particular vulnerability.

> The website can MITM you at any time, even without changing the crypto code it sends you.

I am not following you. If they send you the code, can't you inspect it? And if you vet it, where's the concern for the MITM attack? You already have the code.

> Native crypto clients don't have this particular vulnerability.

Isn't it exactly the same? You have to download the code at some point.

The website or any of the domains it includes JS from can at any time inject some JS into your page, which could maybe replace AES with Base64, or anything else it wished to do.

Native crypto clients don't arbitrarily download code from several domains every time you turn on your app.

And I forgot to add, there's no way you can protect against other side-channel attacks like timing attacks. JS as it is today makes it impossible.

What keeps JS from protecting against timing attacks?

Even so, I would argue that it's fair to say that this pushes it along a continuum towards less secure, not that it is "broken".

Yeah, but you have the code. You could see if they were doing that.

The problem is I have no assurance that the plain text never reaches the server except for your word for it. It also doesn't solve the problem if the message can be intercepted before the intended recipient can read it.

I think the appeal of the service is the convenience. If the message was important enough to warrant no third-party trust, you'd just go the extra hassle of PGP keys from both parties, etc.

The target seems to be people who were previously just emailing their confidential info. And though trust is an issue, people happily trust anonymous emailers, commercial encryption providers (where source is not available), etc.

Moreover, if the server stores enough information for a recipient to read the message, then the server effectively stores the message.

Hmm, oh, I think the stuff after the hash is the decryption key, and we're assuming the server throws it away.

We still require a trusted third party here.

The HTML anchor never reaches the server in the request, it's for local use only. Of course, malicious JS on the page can always send it anywhere.

How is this different than any other security functionality, though? Unless you plan to cipher your message yourself, you always need to trust that whatever encryption you're using works as designed.

This is similar to an app I wrote for fun to learn some nodejs, http://www.selinked.com. I think it's pretty secure but I am no encryption expert. Main difference is that I store nothing but the encrypted messages and for the chat and group chat nothing at all. You can also change the type of encryption it uses, all js browser side. Group chat and chat are half baked, there are a still few bugs in there. Would love some feedback on it.

It's quite similar what I made just for fun: https://off-the-record.appspot.com/ Of course I could add javascript AES encryption, maybe I'll do it. I have also planned to use Raspberry Pi as server instead of Google's servers.

Similar to https://privnote.com, but slightly quicker to use. It would be neat to have an API-service like this, that could be useful for building messaging plugins.

I can just imagine receiving a link like this while I'm on a spotty WLAN, trying to load it, it not loading properly, refreshing, and having it be "expired".

Check out secure notes: http://sn.linkstore.ru And it has got simple API

Doesn't work at all in Mobile Safari on the iPad with iOS 5.1

nice idea to keep the key after the '#' tag. add binary data, 1mb would be enough, and you'll rock.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact