I'm still new to information security, but I have read a bit about the one-time pad. The point that sticks out to me the most is that it is supposedly unbreakable. Has this method of encryption ever been incorporated in any internet web applications on a larger scale? How would they pass they key?
The problem with a one time pad, is that is must be equal in length (or longer) than the data being encrypted , and must never, ever, be reused.
Just as you indicate,
how would they send the key?, the OTP must then be sent in a secure way... however that is the problem that is usually left to the user and is generally why OTP is useless.
If you have the ability to send a large OTP securely, then you might think you could simply send the stuff you want to encrypt directly to the recipient over that secure channel.
However the benefit of a OTP is to move secrecy through time. If you have a secure channel now (e.g. an in-person meeting) you can exchange an OTP. You have banked some secrecy for later. Later when you do not have a secure channel, you can use up a part of your pad to make your message secret.
The improvement over OTP is where they make a small seed (a key) and use an expander called a PRNG to expand that key into what is essentially a stream cipher. This way you're only sending a small amount of data securely, and can encrypt lots of data with that expanded key. This is called "key stretching".
How would they pass they key?
This gets to the root of where OTPs came from, and indeed how they got that name.
This is for correspondence during wartime with ships or other similar agents[*]. When the ship leaves port, they head out with a pad of random data. When they receive an encrypted communication over the radio, they decode it using the indicated sheet from their random pad, and then destroy that sheet.
So what's the level of secrecy of the transmission? If the pad is used and implemented correctly, then the secrecy of the message is the same as the secrecy of the pad. It has nothing to do with the secrecy of the radio transmission. Instead, however careful they were in handling and storing the decryption pad determines how vulnerable the message is. They're effectively using the OTP technique to confer the level of secrecy of an object delivered at one point to a message delivered later on.
That is the technique's (only) use and purpose. If you see OTPs in use today for general cryptography, then the user almost certainly doesn't understand what he's doing. This technique cannot be correctly incorporated into common electronic communication, and is totally inappropriate for things like web applications.
[*] Not sure if this was ever actually used for shore-to-ship communication, but the concept of an agent leaving base for a period of time fits the "ship" metaphor most closely. Often OTPs were used by spies.
Not really "Internet", but the one-time pad is documented to have been used for the Red Phone (a westernly-biased name; I don't know how they called it in Moscow). The pads were exchanged on magnetic tapes, sent by planes on a weekly basis. It is possible that the current system still uses a similar encryption method.
This makes sense: though the one-time pad requires as big a key as the data which is to be transmitted, it still yields a time-based advantage: you can swap keys in advance, at a time when bulk secure transfer is feasible, and then use them when time is of the essence (e.g. ten minutes before launching the ICBM, not ten minutes after).
However, according to USE OTR's presentation at FOSDEM 2014, Pidgin is by no means secure software because it has 300,000+ lines of poorly audited C code, a lot of which is dealing with parsing binary data. It should be fairly trivially exploitable, and once exploited the attacker could simply siphon out the cleartext.
Security seems to be improving with the upcoming Pidgin 3.0 but if you're paranoid enough to use OTP, you should never use Pidgin (or even general-purpose operating systems for that matter).
Also OTP in Pidgin has not seen wide use because there is to be a good IM cryptosystem called OTR which is more than sufficient for the vast majority of use cases.
Not supposedly; Claude Shannon famously proved that one-time-pad has "perfect secrecy", and cannot be broken with a brute force attack.
But no-one uses it on the Internet because it turns out that in practice, you don't actually need perfect secrecy. I'm fine if you can brute force the encryption I'm using if it is going to take you twenty million years to do.
And alternative encryptions schemes have a big advantage over one-time pads - the keys can be much smaller, and so they are much easier to protect and exchange.
E.g. finnish Pohjola bank uses one-time pads. I got first one through normal snailmail and I have gotten new ones when I visit the bank. One list has 350 entries and I need one to sign up and another for accepting the payment of bills. If the amount is larger (thousands of euros) the bank sends as a textmessage the information which one-time number I choose. Feels very secure and handy, at least as long as I don't know how the numbers are created. The list folded down is exactly the same size as a credit card in my wallet.
WikiPedia article has pretty good description on the practical weaknesses of OTP, and why not used in modern computing.
To it I can only add that even on modern networks transmission is not perfect and bits can flip, and thus messages are checked (I believe by including a hash of original message) to verify that message was delivered intact. Without it, there would be no way to validate that the message received actually made it through the wire intact and is thus a valid message. This, inturn, would take away from perfect secrecy since now it can be brute forced (with success of brute force evaluated by matching the hash to original).
For example, let's look at the example in the article in section "Attempt at cryptanalysis" which illustrates that attacker cannot know whether 'LATER' is the original message for a brute-forced potential key 'TQURI'.
Let a transmission validation (a.k.a. decryption validation) hash function be defined as
H = Sum(characters) Mod Count(characters), that is summing up all characters of the message and then modulo-division by number of characters.
With such hashing function, original message
HELLO would be tagged with hash code
(7 + 4 + 11 + 11 + 14) % 5 = 2. The recipient of the message would then take decrypted message, recalculate the hash over received data, and validate that the result is
Now, evaluating potential brute-forced key
TQURI, the decrypted text is
LATER. Without the hashcode to validate the message, the interceptor has no way of knowing if the key
TQURI actually worked or not (perfect security). With hash key, interceptor can now validate by calculating hash key for
LATER which is
(11 + 0 + 19 + 4 + 17) % 5 = 1. Since calculated hash code
1 does not match original message's hashcode
2, interceptor now knows that the original message is not
LATER and the key
TQURI is not a valid key, and thus continue to enumerate and brute-force keys until a key produces a matching hashcode (not perfect security due to brute-forcing ability).
The one-time pad is hardly ever used for reasons already covered. As has been pointed out it has perfect security (assuming it was generated from a truly random source) -- since the "password" is of equal length to the message, there is no possible statistical deviation from "perfectly random" with which to break the password.
Modern encryption algorithms try to approximate a one-time pad by using what is called a
key schedule. The key schedule is used to generate the "pad" as needed. However, they are not perfect, which is why it is not recommended to encrypt messages over a certain size -- for instance, AES-128 is not recommended for use with "messages" over 1TB in size.
Before moving to an mobile app my bank used something like that for signing and logging in. They sent a card (via registered mail) with one time codes that in combination with my PIN was used to verify login.