Hacker News Reader

Comment by istvan__ | Hacker News Reader

Somebody from the security community could shed some light on why this is a good/bad idea.

Roughly the upside is that (in theory) the attacker needs to defeat each cipher separately (barring that the combination offers some shortcuts where one cipher interacts with another so that some computational complexity can be eliminated). Downside is that the performance takes a hit (processor/bandwidth [if blocksizes don't match, dunno if this is an existing risk]), which might not be trivial.

Disclaimer: I assume that existing, proven implementations are used and out from one cipher is handed over to another as input, keys and IVs and other crypto mumbo jumbo are not recycled and that the implementation does not offer new side-channel attacks somehow etc etc.

Personally I'd wait for a while to allow more competent people to analyze the library. In the meanwhile one can do performance profiling to roughly calculate how much beefier servers are needed in a real-world scenario due to extra crypting and decrypting :-)

A good blog entry on the topic:

http://blog.cryptographyengineering.com/2012/02/multiple-enc...

With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant.

[1] http://tonyarcieri.com/whats-wrong-with-webcrypto

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Both of the articles have some flaws (that Matasano one is really bad/dated actually).

Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...

It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.

The article that I posted, while older, presents a more realistic and objective look at the JS crypto problem. I chose to criticize the matasano article as "dated" because some of the positions it takes are no longer accurate. The older article does not depend on dated information to make its points.

This is really good.

I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.

Thanks for sharing.

I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once.

I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?

If you are going to the trouble of layering encryption like that you may as well using a MAC with similar construction. It is poorly thought out. I would also be much more worried about scrypt than AES in the future, it has had much less review yet is not layered in the same way.

Also the go reference implementation is not idiomatic, It does not conform to the interface of other encryption functions in the standard library.

EDIT: I was wrong, they do double up on MAC's but do not on the KDF.

something something roll your own crypto [1]

[1] https://security.stackexchange.com/questions/18197/why-shoul...

See this instead: http://www.cryptofails.com/post/75204435608/write-crypto-cod...

Thanks everybody, much value as usual!

Reply on news.ycombinator.com