Hacker News Reader

Comment by zeckalpha | Hacker News Reader

I may be wrong as I'm no security researcher, but I was under the impression that combining things like this (and rolling your own crypto in general) could potentially make things weaker. Is this the case here?

Edit: Reading it more, I'm more convinced. It looks like there was a discussion a few days ago: https://news.ycombinator.com/item?id=6401057

View on HN

There is no way this construction is weaker than the weakest of the three. To convince yourself of this, assume one of the ciphers is 100% broken and spits out all 0s. Then you're XOR'ing your ciphertext with all 0s (or some other known pad). So it's just a noop. As the FAQ says, because one cipher is not used as the input to another, there's no way a weakness can spread up or down the chain.

There was a discussion on twitter among cryptographers/security practitioners (search for @agl___), and in spite of some unnecessary flaming, we are almost certain now that the cipher cascade and the MAC scheme are both as strong as their strongest components.

See this publication for more information about the cipher cascade: http://rd.springer.com/article/10.1007%2FBF02620231

See this publication for more information about the HMAC construction: http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pd...

Combining algorithms, if done properly, isn't necessarily going to make things weaker. But doing it properly isn't trivial (which goes for crypto in general) and the more complex the construction, the more opportunities for screwing it up.

But at the end of the day it's still trying to solve the wrong problem. The chance of a well studied algorithm like AES having a significant weakness is much, MUCH lower than the chance that a particular program using it has a security flaw. Any effort spent layering Twofish and Salsa20 on top of AES would almost certainly be better spent making sure the usage of AES is totally secure.

It wasn't trivial to write TripleSec, which I why we did it and open-sourced it.

Any encrypted data you put onto a remote-server will live there forever, so your encryption has to be future-proof. I think it pays to hedge your bets here.

All of our implementations are tested against known test vectors. Side-channel attacks could be a problem though.

I have the same question, from the same position of ignorance.

can we get some tptacek up in here?

I've been under the assumption from reading some crypto over the years that in particular what your thinking of is applying the "same" crypto multiple times. Offering the same cryptography scheme multiple times is horribly bad. Like 3DES is horribly bad when implemented because it eats up the keyspace reducing the issue for it.

If the schemes of cryptography that you use do not reduce the amount of permutations/possibilities that you are using I see no reason why it wouldn't at least add a bit of extra difficulty in attaining the calculations behind the results.

This does sound like the right way to deal with cryptography with Javascript as pointed out by Triplesec: "authenticates with HMAC to protect against (adaptive) chosen-ciphertext attacks; and supplements the native entropy sources (window.crypto.getRandomValues in the browser and crypto.rng in Node.js) for fear they are weak."

Particulary because other ways of dealing with javascript random number generators (especially their api) is awful. You can read about some of that here: http://www.matasano.com/articles/javascript-cryptography/

But, I would still like to hear someone who knows more about using these three schemes back to back. Sometimes the permutations are effected in weird ways.

Reply on news.ycombinator.com