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. Of

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/ 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.