How is secure for OTP implementation to use pages smaller than the payload?

Question

I am wondering how is should i implement one-time pad encryption in my code.

I use 16-byte pages at the moment, and the implementation in Golang from the page: https://github.com/ryanuber/go-otp/blob/master/otp.go (line 83 is the Encrypt() method).

However, the data i need to encrypt sometimes (not always) is larger than 16 byte.

// Page must be at least as long as plain text
if len(page) < len(payload) {
    return nil, fmt.Errorf("otp: insufficient page size")
}

result := make([]byte, len(payload))

for i := 0; i < len(payload); i++ {
    plainText := int(payload[i])
    secretKey := int(page[i]) // ln 95
    cipherText := (plainText + secretKey) % 255
    result[i] = byte(cipherText)
}

What i did is commented out the page length check, so encryption now ignores the length problem; using modulus while indexing page (line 95):

secretKey := int(page[i % len(page)])

So, if i encrypt data buffer say of 10 megabytes, is it still secure, and if not, why?

Answer 1

This is a really, really, really bad idea. First off, this is not a one-time pad, as you're using the same pad to encrypt multiple blocks of data. This is exactly the same as sending multiple messages separately encrypted with the same pad.

There are multiple trivial attacks against this scheme:

1. If you have any known plaintext, the attacker can xor bytes of the known plaintext against the ciphertext and recover bytes of your pad. Then they can move to each position where that pad byte is reused (i.e., +/- len(page)), xor the pad byte, and recover more plaintext.
2. Frequency analysis at each position is potentially trivial.
3. Since the value of each pad byte only affects the matching output bytes, brute force attacks are possible against each byte separately (though it will be harder to know which value is correct, it will still be possible).

Answer 2

If you use a byte more than once, it's no longer a one time-pad.

If your key repeats, the result can be broken, because the underlying data probably contains redundancies. Googling for something like "breaking repeating key xor" will get you started on techniques.