Hacker News Reader

Comment by d2 | Hacker News Reader

Delivering cryptographic software via a network, having it run in a "maleable" runtime and creating a user expectation that it will be secure, is not new.

We've been doing this on the desktop for years.

I'd like to pose a question to the authors:

Don't all the premises you've based "Javascript Cryptography Considered Harmful" on apply equally to downloaded desktop software?

-A chicken egg problem

-A malleable runtime for apps with admin access

-Code verification being defeated by other hostile apps on the system

-Inability to trust the secure keystore because of the chicken-egg problem and other hostile apps installed prior to the crypto app's installation.

-The weakness of pseudo-randomness

View on HN

We've been doing this on the desktop for years.

It didn't hold up well against attack there but there was usually an underlying bit of assumed trustworthiness on the local network that shifted the blame.

But protocols designed for enterprise desktops always turn out to be an unmitigated disaster when run across a hostile internet, particularly from a security perspective.

Kerberos fits your description ("protocols designed for enterprise desktops") exactly. The hardest thing I've found about running it across a hostile internet is dealing with NAT issues. The (latest version of the) protocol itself is pretty decent from a security perspective.

Then again, the original version of it, when it was designed for enterprise desktops, would not be particularly effective.

Actually, Kerberos was designed at MIT for the explicit scenario of an untrusted network: "I'm OK, you're OK, the network is hostile".

It may work acceptably for VPN-like applications, but how does it work for actual internet applications? E.g., how do you enroll new clients into the authentication realm over the internet?

Yes, it was designed for an untrusted network. But, there are good reasons why older versions of the protocol are not trustworthy today, which go beyond the increase in computer power relative to the key space [1].

The problem with enrollment is more or less the same as the problem with enrollment using any other crypto trust scheme. In the most secure situation, you'll want to start the process in person.

In practice, with kerberos you have to trust the KDCs holding your keys. With asymmetric systems, you have to trust the CAs who have signed the keys of the parties you are communicating with.

I agree that it isn't a good solution for what we might call "web scale" applications. It is a reasonable way to do password authentication, but federated authentication would require establishing cross-realm trust between identity providers and relying parties.

[1] http://web.mit.edu/kerberos/krb4-end-of-life.html

Downloaded desktop software is generally written in a compiled language like C, and for example can't easily be XSSed to inject JavaScript.

Yeah but C has its own problems--buffer overflows and the like. Just because it doesn't have exactly CSS doesn't mean it lacks similar problems.

We're talking about "problems" in the context of "things that make cryptography hard". The other security flaws of C/C++ are orthogonal to this issue.

This isn't a value judgement on Javascript. I like Javascript. The hard fact of the matter is, not every good programming environment is going to be suitable for cryptography.

Perhaps, but almost all buffer overflow, remote code execution bugs are very similar to XSS attacks--feed the program something it doesn't expect along with some junk for it to execute. The mechanism is different but the concept it the same.

No, the concept is not the same. C programs aren't designed to execute code from third parties.

If you think C programs aren't vulnerable to XSS-like attacks, you need to take a security course.

In the context he's talking about, C programs aren't vulnerable to "XSS-like attacks"; C programs rarely deal with content-controlled code.

Buffer overflows.

Reply on news.ycombinator.com