SSL supports a number of ciphers, but is it possible to stack/nest the ciphers, and process the plaintext in stages? My adversary may be able to easily crack one or more of the stages, but to decode my message, they need to crack them all if I can use multiple ciphers.

For example:

ciphertext = Encrypt(plaintext, key, alg=[1,2] )
           = Encrypt1(Encrypt2(plaintext,key2),key1)

If I want to establish a connection protected by Blowfish, elliptic curve, a weak substitution cipher of my own making, and 3 rounds of 3DES with different keys, can SSL do this?

Since all of the ciphers may have unknown weaknesses, using all of a wide selection of possibly secure ciphers will require my advanced persistent threat to be proficient in all of them. If just one of the ciphers holds up, my message remains secure (provided the ciphers do not share key information). I wish to transmit an enigma, wrapped up in a mystery, etc.

  • 1
    SSL is called TLS for over 10 years now.
    – Philipp
    Apr 9, 2014 at 20:54
  • Just FYI, if you're afraid that all ciphers are vulnerable individually, layering them won't help.
    – KnightOfNi
    Apr 9, 2014 at 21:09
  • Thanks for all the great comments about encryption snake oil and weak ciphers. It is interesting that the gods of encryption so dislike cascading algorithms - the main driver of my question was not whether it is approved by the kindly censors of encryption ideas, but whether it can be done with standard software.
    – Des Cent
    Jul 9, 2014 at 11:32

3 Answers 3


SSL is called TLS nowadays.

During a TLS handshake, client and server agree on a cypher-suite. A cypher-suite is a combination of a key exchange algorithm, a bulk encryption algorithm, a hash algorithm and a pseudorandom function.

The TLS specification defines a fixed list of possible cypher-suites in Appendix A.5.

When a client connects to a TLS server, it sends the server a list of the cypher-suites it supports. These suites must be from the lists defined in the specifications. The client can not propose a custom one. The server then picks one (1) of these cypher-suites. That suite is then used for encryption.

A standard-compliant TLS server will not allow you to layer multiple cyphers, nor will it accept any cypher not listed in the specification.

But when you use TLS to wrap your own protocol, you can of course add further encryption on the application level. TLS just transports bytes. What these bytes represent doesn't matter.


SSL/TLS is a protocol for sending "application data" as a bidirectional stream of bytes, so you can send through it anything that can be encoded as bytes, i.e. anything that fits at all in the memory of a computer. If you want to apply extra encryption layers of your own, nothing will prevent you.

Now believing that such cascading of encryption algorithms will do any good to your security is a known delusion, unfortunately quite common. Encryption algorithms, when used properly (e.g. as they are used in TLS), are not the weakest part of the system; they are the strongest part. When you are attacked, it won't be through breaking the algorithms. Adding extra algorithms won't help. Actually it will probably hurt, if only because the extra complexity will kill your performance and induce you not to use TLS at all in some cases, because of that gratuitous overhead. See this answer for more discussion on the subject.

Believing that your homemade algorithm will also help is also a common delusion. The main part of training as a cryptographer is to learn that nobody can build by himself an algorithm which will be reliably secure. Thus, professional cryptographers don't create algorithms that way; instead, they publish candidates, to be inspected by their colleagues. If none of these well-meaning other cryptographers found anything bad to say about the new algorithm after a few years, then we may begin to imagine that the algorithm might be quite robust after all. This is the only known method for designing secure algorithms. You cannot do it by yourself, all alone, by definition. I cannot either. Nobody can.


Well, think of it this way:

Each encryption produces an output. Let's invent an encryption and represent it with f(). We'll say that the message you are encrypting is "Hello World." f("Hello World") will produce an output of some sort. Let's say that that output is... 1234567890. Now, what happens if we create another scheme, say d()? d("1234567890") gives us another output, we'll just say it's 0987654321. Now, what would happen if you sent "0987654321" through SSL/TLS? You'd get the equivalent of this:

ssl(d(f("Hello World")))

So, in short, yes, it is possible. However, as @Phillip said, it may or may not be supported by the server you are trying to contact...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .