5

I understand that one of the requirements (and a major drawback) of OTP is that the key has to be as long as the message is.

What happens if I have a key that is shorter? The message would only get encrypted partially, right?

For example if my Key was "The" and my message was "Hello, there" the resulting ciphertext would have to be only three bytes long. Right? In this case only "28 13 9" (in decimal format).

I just want to confirm that my understanding is correct and that the key doesn't wrap around or something like that.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
  • 6
    If the key is shorter than the plaintext, **it's not an OTP**. How that cipher handles wrap-around is up to how it is defined, but usually the key is repeated from the start (and you get a Vigenere cipher). – Thomas Dec 18 '13 at 01:20

2 Answers2

6

"One-Time Pad" is more a concept than a strictly-defined algorithm. If there was a specification of an "OTP encryption algorithm" (say, in RFC format or similar), which tells where each byte goes and when, then that specification would tell you what happens when the key length does not match the data length. Moreover, if, in the case where the key is shorter than the data to encrypt, that specification told you anything else than: "if the key is shorter then encryption must be aborted"; then that specification would not qualify as a true implementation of the "One-Time Pad" concept.

In that sense, there cannot be any "key wrapping around" for a One-Time Pad because then the "pad" (i.e. the key) is no longer "one-time".

An OTP algorithm specification would be quite simple, but there is still room for variants. When the data to encrypt is a sequence of bits (as is typical in computers), then it is customary to talk of the OTP with XOR as operation for encryption and decryption. However, any group operation can do the job. For instance, if the data is a sequence of octets (aka "bytes"), as is also very typical in computers, then you can do an OTP with a byte-by-byte integer addition (modulo 256), while decryption would use subtraction. This also works well and fulfils the One-Time Pad concept. Many pre-computer uses of OTP (with papers and human brains) worked with letters, in which the operation was mathematically equivalent to addition modulo 26 (the underlying group being, in that case, Z26, mapped to the A to Z letters).

I am not aware of any established, well-defined specification for a computer-based one-time pad, because, let's face it, for practical usages one-time pad tends to suck. We can find traces of the OTP concept in some degenerate cases (for instance, ElGamal encryption can be mathematically described as a Diffie-Hellman key exchange resulting in a shared key, which is then used to encrypt the short message to send with a custom one-time pad operating in the same group as the DH part).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Thanks, your answer help me understand concepts I wasn't aware of before. –  Dec 18 '13 at 21:42
2

This is an implementation specific question.

If I were to implement OTP I might re-use the key, incorrectly, and encrypt the message fully with the key. As you can see, the drawback of this is the security is nonexistent.

If you implemented the OTP then your implementation would be correct and ensure a proper OTP. Your message would be truncated to be the length of the key and part of your message would be missing. The drawback to your implementation is users may not have a large enough key and lose part of the message.

``What would happen'' isn't a very good question since at the end of the day someone has to build the software/hardware and decide what would happen, and then implement it.

With that said, what SHOULD happen to ensure security is the message is truncated....like you guessed