Let's redifine things a little:
the password is what the user needs to know to decrypt the message
the key may, or may not, be the same as the password, but it is also needed to decipher the msg.
the rand, short for random, is the information about which cipher was used to initially encipher the plaintext
The key would not be the same as the password (unless someone was lucky). Its generated as a track on what the algorythm did randomly.
Let's start with the second method you suggested - it is easier to attack.
In order for someone to decipher the message, they need to have the encrypted message, the password, and the rand (actually, they don't need to 'know' the rand - the information concerning the rand is just passed to them - I'll discuss not knowing the rand later). So where do we put the rand? It can't go in the password - the rand is random! It has to be located within the encrypted message.
well, I was thinking the key stays local - but I guess you could use the password algorythm to hide it in the text.
So where do we put the rand. We can't do something obvious like encrypting the rand with some known cipher and putting it at the front or end of the message. It would be easy for someone to reverse engineer their own message and find the location. After they figured out which cipher is used to encrypt the rand, you're back to using just a single cipher. Worse yet, they may now know the key!
without the password, the key (or rand) is of little use - however, if the key is kept in the file - and it is placed based on the password - then one could eventually figure it out (if they had the algorythm).
Don't waste neurons thinking about it though. We don't need transmit the rand. Since we have the password/key, we just go through the first decryption algorithm and then use that result and try each of the 100 remaining possible ciphers. On average, it will take 50 tries to get it. No biggie - computers are fast at this. A good marketing guy will spin doctor this and have people thinking the extra time is just making their data more secure. This is much better then trying to transmit the encrypted rand (at least of the possibilities that I considered).
You lost me there - you have to have the key. Otherwise, when you try to decypher you will run through the 100 possible decyphers - but you will not know which one was the right one.
rand cypher 1 (oct, no scramble)
rand cypher 2 (convert to hex-20 unsing 2 decimals, no scamble)
Now, I didn't scamble the cypherbets 'cuz of time - but if I had, how would you know you broke the first cipher and could move on to the second?
We could even take this a step further and disregard the rand in your first example. If we had 5 weak ciphers and randomly enciphered the plaintext 3 times with any of the ciphers, we would have a 5^3 combinations of ciphers. 125 is within working range, if you know the key, and it might be possible to use an alpha-beta algorithm to reduce the problem space further.
This technique of enciphering a message multiple time doesn't always improve things though. For example, some ciphers don't provide any extra security when they're used multiple times. You could use a Caesar shift, monoalphabetic substitution or transposition cipher on a message a 1000 times an it wouldn't make a bit of difference. The original weakness just shines right through. Occassionaly, it makes things worse. If anything, I suspect these techniques buy a little more time and help foil automated attacks.
True enough - if you use the same shift (or even a different one) everytime, you are doing nothing. But look above - this isn't like that. I dropped 4 letters into 12 numbers back to 6 characters. Had I used transposition - and a different one for both - things get complicated. You could even have a method designed for frequency breaks by adding false characrters at a (seemingly) random interval.