In regards to security, Why is one-time pad encryption unconditionally secure against eavesdropping?

Also, why does the triple DES use an Encryption-Decryption-Encryption combination rather than an triple encription combination?

-
Those are two completely separate questions, don't put them into one. – CodesInChaos Sep 24 '13 at 15:52
The 3DES question has a duplicate on security.SE, Why triple DES used in EDE mode?, another duplicate Why do we use encrypt-decrypt-encrypt (EDE) in 3DES, rather than encrypting three times? and a related question How can 3DES encryption use decryption in the middle step? on crypto.SE – CodesInChaos Sep 24 '13 at 15:54

A Vernam cipher (the official name of the one-time pad) is secure because any encrypted value could equally be decrypted to any plaintext value. If I have the ciphertext value HFKCV, it could decrypt to HELLO, or START, or STOP!, depending purely on the key.

But the security rests on the bytes of the key being truly random, with the critical property being each byte of the key must be unrelated to every other byte of the key. (The security can also be broken if the key material is ever reused, but that enables a different attack than the one I describe below.)

The problem is that many so-called one-time-pads don't take into account the implications of a non-random key generation process. They believe that they can take the output of rand() or the output of a hash algorithm, and that it's sufficiently random. But these algorithms are often deterministic, outputting bytes that are related to each other, and that's enough to break the encryption.

Let's use a deliberately poor "random number generator" as a key generator to demonstrate the importance of the random number selection process. This poor random number routine takes the seed, adds one to it, and outputs that as a random number. To encrypt the plaintext message HELLO with this mechanism, we would have a generated key stream of 1, 2, 3, 4, 5, and the encrypted value would be IGOPT. As an attacker who learns that IGOPT == HELLO, I might look at the key stream used to generate it, and notice the pattern is 1, 2, 3, 4, 5. That could enable me to reverse-engineer the random number generator, and come up with a way to decrypt any message. (In this case, I learned the encryption function has shifted from a random one-time pad to "addition".) The important idea is this same approach to reverse-engineering works no matter what "random function" is used to generate the key material.

--

To answer your other unrelated question, 3DES used EDE in order to enable migration from old 8-byte-key installations to new 24-byte-key installations. Way back when, many financial institutions used single DES with 8-byte-keys to protect banking transactions and retail charge authorizations. Once single DES was discovered to be weak, they had to find a way to increase security while remaining backward compatible, because not every bank and retailer could synchronize changing all their encryption systems overnight. (The banks would have "hardware security modules" (HSMs), while the retailers had tens of thousands of PIN pads at their cash registers. All of them need to use the same base key for encryption. Changing a few HSMs was moderately expensive for the banks, but changing thousands of PIN pads was incredibly expensive for the retailers.)

Using 3DES in EDE mode enables you to use a single 8-byte-key for all three operations (called "keying option 3") and remain compatible with someone who only has single DES and one 8-byte-key. It's compatible because the first encryption is completely reversed by the following decryption, so the third encryption becomes the only encryption that is effective. This way a bank could silently upgrade their systems to be 3DES capable while keeping the same old 8-byte-key, while their customers continued to use single DES with the same key. Finally, their customers then upgraded their PIN pads to 3DES capable systems, which allowed them to be injected with a 24-byte key. Only then would communications be properly secured by 3DES.

-

The Wikipedia page on One-Time Pad has a reasonable explanation on why OTP is unconditionally secure; but here is a shorter one: OTP is unconditionally secure because any encrypted message could be the encryption of any other plaintext message of the same size, with equal probability.

For 3DES, see this answer, as @CodesInChaos suggests. Summary: it is for easier backward compatibility with DES, and a smooth transition.

-