Hacker News Reader

Comment by m0nastic | Hacker News Reader

By contrast, I've noticed the exact opposite phenomenon that the OP describes (mainly, that over the past year or so, neo-cypherpunks have started coming out of the woodwork to prosthelitize things like bitcoin, and terrible in-browser Javascript crypto).

I suppose we all see what we want to see.

I do wish that there existed a forum for some of the discussions that used to actually happen on the cypherpunks list (even though it would frequently derail into arguments about assasination markets, and paranoid conspiracy theories).

View on HN

mainly, that over the past year or so, neo-cypherpunks have started coming out of the woodwork to prosthelitize things like bitcoin,

OK, fair point about bitcoin. But other than that, I really feel like the cypherpunk types have been fairly invisible lately. Maybe it's just that there was a certain period of time, back in the /. heyday, when discussions of cryptography, surveillance, data-havens, etc. were at a peak, and now they've leveled off. But in any case, I would argue that we (still) need an active and efficient cypherpunk community to promote technological freedom.

I think what's changed is that the discussions during the heyday were around the technology, which at the time was the limiting factor. The technology isn't really the issue anymore (with some specific exceptions).

The problem with crypto-currency isn't the "crypto", it's the "currency". I think that same phenomena is the culprit for most "cyperpunk-related" discussions.

10 years ago I'd have said that I was really hoping for the "Star Trek" future, but that if I was forced to bet, I'd bet on a "BladeRunner" future being way more likely.

Now I'm old, and I think if I was forced to bet, "Brazil" is a more likely model (the movie, not the country).

But I don't want to sound like I'm dismissing the value of a healthy "cypherpunk" community. I think you can look at a lot of things that came out of the original community and see value there.

Now I'm old, and I think if I was forced to bet, "Brazil" is a more likely model (the movie, not the country).

I'm afraid you may be right. But I still hold out some hope that we can do better than that.

Here's a link to a list, by year, of how the future is portrayed in films. I'm not sure if it's listed in the infographic, but the film 'Code 46' (Tim Robbins) tells an intriguing story of where I see things heading.

http://img197.imageshack.us/img197/3199/inforn.jpg

Another image I can't locate showed how we used to see the future, from a 1980's standpoint (think: Jetsons), and how we see it today (think: "The Road", "Book of Eli" or "I am Legend").

how we used to see the future, from a 1980's standpoint (think: Jetsons)

I think you must mean a 1960s standpoint. 1980s gave us Bladerunner and Terminator.

The movie Blade Runner was based on the book Do Androids Dream of Electric Sheep, written by Philip K Dick in 1968.

The movie The Terminator was at probably partially inspired by the short story Second Variety, written by Philip K Dick in 1953.

The problem is the vision these techno-libertarians promote is one of isolation, not connection. The world has shifted. People want to share. They want privacy, but when privacy must be eroded to allow greater connectivity, they trade it willingly.

Crypto solutions lead to technical complexity which in turn raises the barrier to entry and makes it difficult for outsiders to join in. It's some kind of isolationist community. Who uses Diaspora, anyway? Anyone? Doesn't it offer precisely what everyone's allegedly in need of?

> I do wish that there existed a forum for some of the discussions that used to actually happen on the cypherpunks list

check out the bitcoin forums. Honestly, I think the op has been hiding under a rock for the past couple years. Bitcoin and tor are great examples, but there are plenty of other disruptive projects out there, like loom, open-transactions, ripple. Crypto-anarchists didn't go away, they got to work creating practical applications that can change people's lives, and not just for the geeks.

> I do wish that there existed a forum for some of the discussions that used to actually happen on the cypherpunks list

You may find some interested people in UK Crypto (but obviously I'm not suggestion you spam their list). (http://www.chiark.greenend.org.uk/mailman/listinfo/ukcrypto)

> This group is comprised of people with a professional interest in the formulation and content of UK government policy on the provision, use and control of encryption products and services in the UK. It was formed in response to the 1996 announcement of UK policy on the provision of encryption services on telecommunications networks.

> The mailing list is unmoderated, but only subscribed members can post. Please try and restrict postings to UK Encryption law and try not to stray onto general cryptology topics.

Start a mailing list, start recruiting people to post...who knows, maybe you'll set up the new place?

Count me in. My initial focus is going to be on the RTP area, and trying to get a meatspace meetup going, that caters to folks of this mindset. But if a new hub for cypherpunk (and related) thought emerged online, I'd definitely join in.

>terrible in-browser Javascript crypto

I'm not a cryptographer by any means, but my first thought when reading that is can we make non-terrible in-browser javascript crypto?

One of the top Google results for "javascript cryptography" thoroughly attacks the concept, but I'm not an expert in the area so I can't refute or confirm its claims:

http://www.matasano.com/articles/javascript-cryptography/

This is tptacek's company.

The main issue is the trust base. Allow the entire code base of a site to be pinned down to a cert (and that has to be done outside the website context, ie. in-browser), and you're halfway there.

Say, a signed webapp manifest, listing all files that are supposed to be used in that context and their hashes. On first execution, the associated key is stored, maybe compared with third party knowledge about the site (not tampered with) and key (known not-trustworthy).

After that, you know when someone else than the maintainer tampered with the code.

With that you're down to trusting the maintainer. Which makes it as good as any other code distribution scheme.

It's not a problem with javascript so much as a problem with the issue of knowing what code is actually running in your browser.

The short answer is "no, we can't" which every time someone proposes a new scheme seems to infuriate people (as though our inability to actually do it is a value judgement on whether or not it's a good idea).

Actually, I think in some limited circumstances, JS crypto could be useful for a kind of "separation of trust." 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.)

(Copied from http://news.ycombinator.com/item?id=3872007)

So, you're scheme would require the long answer...

;)

Which is that it sounds rather complicated (which makes my security-sense go off, but certainly isn't a fatal indictment) and that I'd really need to either do an active evaluation of the system or get several reassurrances that someone else decent (ideally someone much smarter than me) did and it checked out before I'd be remotely comfortable using it or recommending it.

That's fair enough. I was just pointing out that not every architecture involving in-browser JS crypto suffers from the problems tptacek detailed.

Yeah, we need a crypto library like JQuery where it's open and people can use a common implementation.

> Then I will pull the results off Amazon and decrypt them on a machine which is not even connected to the network.

What? How does the machine -the machine not connected to the network- get the results off Amazon?

I guess it's possible the machine (connected to the Internet) pulling from Amazon is also connected to a network with the machine that can decrypt (but can't access the Internet)

I would periodically copy the encrypted files to removeable media, then physically transfer the copy to the offline machine.

That design is not obviously impossible to make work, but have you thought about timing attacks? There is no obvious way to make JS take key- and data-independent time to encrypt something. (Turning this into a usable attack is nontrivial, obviously.)

What kind of vulnerability would a timing attack expose, in the use case I outlined?

It could conceivably leak the key and/or data being sent. If the key is random, leaking it does not expose unrelated data; and if you're uploading via HTTPS, exposing the key does not even expose the protected data unless the attacker also has access to S3.

Data-dependent timings could conceivably allow a bad guy to deduce something about the data being sent.

Note that this is all highly speculative; I'm not convinced it's truly impossible, but it's one of those attack scenarios where "put a gun to the sysadmin's head" begins to look like a pleasant and trouble-free option...

What's your gripe on in-browser JS crypto?

Is it worse than nothing, or just bad?

What alternatives would you suggest?

My gripe is the same as the overwhelming majority of people in my industry: that given unlimited resources, in your wildest dreams you couldn't imagine a less hospitable place for cryptographic integrity than the DOM.

Some people are of the opinion that the usefulness of being able to do crypto in people's browsers outweighs exactly how inhospitable it is. I don't share this opinion.

In most circumstances, something bad might be preferable to nothing at all. I think crypto is one of the rare exceptions where "bad" is actually worse than none.

My alternative suggestions are conservative: PGP and TLS

These suggestions aren't particularly exciting, however, so people keep looking for other, newer, ones.

I'm actually in the small minority of security people who don't think it's feasible to discourage people from trying to muck around with crypto. It's like sitting a kid in front of a television,handing them a video game controller, and then telling them not to play video games.

Crypto is an attractive nuisance. It also seems like it answers a lot of our problems (it actually answers far less than we think, and just creates new ones in their place), so people naturally are inclined to experiment with it.

So I hope someday to be wrong about crypto in the browser, because it'd be great. But right now, it's sort of like trying to fancy up a glory hole.

I'll admit that browser-based scripting isn't high on my list of secure environments either. It does, however, do a nice job of getting around the fundamental problem of finding some environment that's reliably and consistently available. It also nicely end-runs the problem of trusting a remote site to hold your data in confidence.

There's the remaining problem of key management, though for many people, browser-based password managers are a reasonable mechanism.

PGP/GPG and TLS still provide key management issues (with several notable registrar incidents in the past year). And even if you're, say, parking a public key on a site to autoencrypt material sent there (assuming it's not encrypted prior to upload), there's the question of how you're going to interact with encrypted data on that site. I see three basic options: server-side encrypt/decrypt, browser-based, or client-side non-browser utilities. In the latter case, you now have a wide range of environments (Windows variants, Mac, Linux, etc.) to support.

Not saying it can't happen, but good crypto is hard.

Even the pros (PGP) ended up using a server-based solution which had both public and private keys on it as their solution to the key-management problem.

http://www.w3.org/2011/11/webcryptography-charter.html

Something like this is the ONLY way I can see crypto in the browser gain any credibility and traction. Crypto in the JS is not only potentially the easiest attack vector, it's also abhorrently slow. With native browser constructs we get access to safe(r) implementations which cannot be DOM manipulated, MITMed or simply replaced at load time. We get access to speed boosts by running natively and on hardware supporting AESNI it can zoom.

Reply on news.ycombinator.com