Return to Answer

Historical paddings:

In short, currently none.

• Currently, the first describer is Frank Miller in 1882. the OTP is patented by Gilbert Vernam in 1919 (U.S. Patent 1,310,719) this patent doesn't include any padding.

• The Venona project doesn't mention either

• Shannon doesn't define either

The OTP keystream obviously is a long stream to long-time use, i.e. one can encrypt many messages over time without using any bits again.

Note that to work with the fixed messages, the length of the message must be one bit less than the fixed size. Otherwise, one cannot decide that the padded message 1010111011001011 is message2: 101011101100101 or 1010111011001011.

The OTP keystream obviously is a long stream to long-time use, i.e. one can encrypt many messages over time without using any bits again. If a predetermined size exists to achieve the perfect secrecy, the long stream must be divided into chunks.

Note that to work with the fixed messages, the length of the message must be one bit less than the fixed size. Otherwise, one cannot decide that the padded message 1010111011001011 is message2: 101011101100101 or 1010111011001011.

Other paddings

The bit padding works for bits, there are other paddings that works in the binary case;

• ANSI X9.23 : Block-based padding, the remaining bytes in the last block is filled with 00 and finally the length of the padding is added.
• ISO 10126 : Same as above, instead of 00s random bytes are added
• PKCS#5 and PKCS#7 : can only support a message size of fewer than 256 bytes.
• ISO/IEC 7816-4: Identical to the bit padding, the byte 80 is added then the remaining bytes are set to 00

In OTP, one party generates a uniform randomly key, writes it in a roll of paper, or a book, or CD, or USB. They transmit it in person with reliable people to the other side.

The OTP keystream obviously is a long stream to long-time use, i.e. one can encrypt many messages over time without using any bits again.

• OTP with hiding the maximum possible length of the message;

  Wikipadia defn;

  One-time pads are "information-theoretically secure" in that the ciphertext provides no information about the original message to a cryptanalyst (except the maximum possible length of the message).

  Let both parties agree on a maximum length of the messages in advance, say $t$.

  Let the keystream is represented by $k_i$ and the message to be encrypted be $m$ with length $\ell$. Then the encryption is performed with the first $\ell$ part of the message. The remaining part is padded, here 10..0 bit padding is used since it is easy to apply even by hand.

  \begin{align} c_i &= k_i \oplus m_i , \quad\text{for } 0\leq i < \ell\\ c_{\ell} &= k_1 \oplus 1\\ c_i &= k_i , \quad\quad\quad\;\; \text{for } \ell < i < t\\ \end{align}

One time pad - how is the difference in length between the plain text & the OTP handled?

Two cases we have;

1. The OTP keystream is shorter: in this case, one should not send reusing the keystream. Otherwise, two(or many)-time pad use occurs, and that OTP is no longer informationally secure and can be broken.

   • How does one attack a two-time pad (i.e. one-time pad with key reuse)?

   • Taking advantage of one-time pad key reuse?

   One can break the messages into parts. This, however, may leak the information about the message length is longer than $t$ if the adversary observing the message traffic and two consecutive message sending is unusual.

2. The OTP keystream is longer: The 10.. padding as above.

10..0 padding (bit padding)

The padding simply works as adding 1 to the message then adding as many as 0s to fill the message size and possibly none. Consider only 16-bit length fixed messages;

message1 = 1010110          wiht padded 1010110100000000
message1 = 101011101100101  wiht padded 1010111011001011

The unpadding (removing the padding) starts from the end of the message, remove the trailing zeros if there are any, and then one 1.

Note that to work with the fixed messages, the length of the message must be one bit less than the fixed size. Otherwise, one cannot decide 1010111011001011 is 101011101100101 or 1010111011001011.

In OTP, one party generates a uniform randomly key, writes it in a roll of paper, or a book, or CD, or USB. They transmit it in person with reliable people to the other side.

The OTP keystream obviously is a long stream to long-time use, i.e. one can encrypt many messages over time without using any bits again.

• OTP with hiding the maximum possible length of the message;

  Wikipadia defn;

  One-time pads are "information-theoretically secure" in that the ciphertext provides no information about the original message to a cryptanalyst (except the maximum possible length of the message).

  Let both parties agree on a maximum length of the messages in advance, say $t$.

  Let the keystream is represented by $k_i$ and the message to be encrypted be $m$ with length $\ell$. Then the encryption is performed with the first $\ell$ part of the message. The remaining part is padded, here 10..0 bit padding is used since it is easy to apply even by hand.

  \begin{align} c_i &= k_i \oplus m_i , \quad\text{for } 0\leq i < \ell\\ c_{\ell} &= k_1 \oplus 1\\ c_i &= k_i , \quad\quad\quad\;\; \text{for } \ell < i < t\\ \end{align}

One time pad - how is the difference in length between the plain text & the OTP handled?

Two cases we have;

1. The OTP keystream is shorter: in this case, one should not send reusing the keystream. Otherwise, two(or many)-time pad use occurs, and that OTP is no longer informationally secure and can be broken.

   • How does one attack a two-time pad (i.e. one-time pad with key reuse)?

   • Taking advantage of one-time pad key reuse?

   One can break the messages into parts. This, however, may leak the information about the message length is longer than $t$ if the adversary observing the message traffic and two consecutive message sending is unusual.

2. The OTP keystream is longer: The 10.. padding as above.

10..0 padding (bit padding)

The padding simply works as adding 1 to the message then adding as many as 0s to fill the message size and possibly none. Consider only 16-bit length fixed messages;

message1 = 1010110          wiht padded 1010110100000000
message2 = 101011101100101  wiht padded 1010111011001011

The unpadding (removing the padding) starts from the end of the message, remove the trailing zeros if there are any, and then one 1.

Note that to work with the fixed messages, the length of the message must be one bit less than the fixed size. Otherwise, one cannot decide that the padded message 1010111011001011 is message2: 101011101100101 or 1010111011001011.