Re: Multiple layers of encryption

"Joseph Ashwood" <ashwood@xxxxxxx> writes:

As has already been indicated, multiple layers is generally overkill,
the reference you are looking for is "Cascade ciphers: The importance
of being first" by Maurer and Massey, basically it says that if the
keys are indendent, it is no weaker than the inner most cipher., if
the keys are not independent all bets are off.

Note that this paper is old and its notions of security are weaker than
those usually considered by modern cryptographers. In particular, the
paper considers security against known-plaintext attacks; modern
cryptographers consider chosen-plaintext attack as the /weakest/ attack
profile worthy of attention: if an encryption scheme is weak against
chosen-plaintext attack, don't use it.

It's very easy to prove that a cascade of independently keyed encryption
schemes is as secure as the strongest component under chosen-ciphertext
attack. This formally justifies the use of cascades.

I also have to completely agree with David, and it is worth repeating exactly
what he said:
I second Kristian's advice. I'll go a bit further: I wouldn't recommend
around screwing around with block modes or implementing crypto stuff
yourself. I'd recommend using TLS or GPG or something like this that has
already been carefully vetted by cryptographers, if you possibly can.
From your post I infer that you are not already a crypto expert, and
building your own crypto is error-prone if you are not a crypto expert.

I'd have to dissent slightly from this. TLS is almost a very good
protocol, but (a) it has a number of unpleasant sharp edges -- e.g., the
requirement to cope with fragmented key-negotiation packets -- which
make implementation more complicated than it ought to be, and (b) the
whole X.509/PKIX certification model is utterly hopeless. In the light
of (b), especially, I can't honestly recommend `vanilla' TLS.

I don't have anything against OpenPGP as a protocol suite or GnuPG as an
implementation. And I do agree that designing crypto protocols for
production use is best left to experts.

-- [mdw]
.

Relevant Pages

  • Re: My little something...
    ... It's entirely possible to chain an attack through both and recover the ... your "proper crypto design methodology is like this" space, ... It is real-world crypto, with a real-world role. ... bringing in a law that allows a Policeman to demand keys and/or plaintext, ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... ]> crypto primatives it should make no difference. ... made a reasonable guess as to how much predictability there is in the ... If I can use this data in an attack, ... There is more than enough evidence that drinking and accidents are ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... While it may use crypto to "mix the pool" and to ... distill entropy in the input it should not depend on ... If I can use this data in an attack, ... assume that AES whatever is NOT secure. ...
    (sci.crypt)
  • Re: strengthening /dev/urandom
    ... If I can use this data in an attack, ... "Blocking on more entropy input exposes traffic analysis of event ... "Assuming AES256/SHA256 are secure is a bad judgment." ... > a hobby, not a crypto expert. ...
    (sci.crypt)
  • Improving the AONT pakagetransform
    ... That aside in in Ron's all or nothing package transform you take a ... a long message of English text you first encrypt it say with AES in a ... At this point say your stuck with 40 bit crypto you then encrypt ... Yet the fact is such an attack even with the larger ...
    (sci.crypt)
Quantcast