Mathematical formula for switching the key for OTP?

Question

Instead of generating the random key for the one time pad cipher over and over again, is there a mathematical formula that allows you to switch the key to a new key? The new key must be as random and secure as the original key.

Answer 1

Instead of generating the random key for the one time pad cipher over and over again, is there a mathematical formula that allows you to switch the key to a new key?

No.
_{(Please keep reading…)}

A single mathematical formula won’t cut it. That’s where cryptographic algorithms come in. There are more than a hand full of cryptographically secure pseudo-random number generators, stream ciphers, et al which could be used to create a cryptographically secure key… but when having to fall back on those, you might as well simply use them in the first place and drop your one-time-pad idea.

In fact, I’m wondering a bit: What research have you done? I’m asking because you seem to have skipped some of the important parts of what defines OTP.

Per definition, OTP requires the “key“ to be…

1. a truly random one-time pad value,
2. generated and exchanged in a secure way.
3. at least as long as the message, and
4. only to be used once.

Related to Point 1: Please note that it says “truly random” and not “pseudorandom”. Fact is that no mathematical function by itself can be truly random. Meaning: if you would use a math function (for example: a multiply-with-carry construction) it would definitely not satisfy the definition of OTP.

In a best case scenario, you would be dealing with a CSPRNG or a stream-cipher alike solution. As you probably know, those do exist and indeed provide cryptographically secure randomness (to some extend), but when thinking along that path you really have to ask yourself if you really want to use a car to ride a horse.

Instead of trying to make a square wheel round, it would be more constructive to revalidate your idea and check on already existing stream ciphers and/or cryptographically secure pseudo-number generators. A simple “it looks random so it must be secure” thing definitely won’t be able to handle the job! In case of doubt, look at the numerous PRNGs which have been cryptographically broken (and practically destroyed by cryptanalysis within the blink of an eye).

Related to Point 2 up to Point 4: That “exchanged in a secure way” is important because OTP can only be as secure as the key exchange procedure, which tends to be a problem when messages or data packages size up to a few megabyte or even gigabytes*.

Surely that’s where your question rooted. Yet, trying to find a way around the problem via a math function is neither OTP. nor cryptographically secure.

Last but not least…

The new key must be as random and secure as the original key.

I wonder how you are planning to compare that. See, a truly random source is unpredicable. Same goes for things like cryptographically secure random number generators (assuming they’re not flawed or broken in some way).

Wrapping it up:

If you really want to stick with OTP, you’ll have no other choice (thanks to its definition) than to use a truly random, cryptographically secure source.

If that’s not available, you could fall back on something like a CSPRNG, or a stream-cipher alike construction (for example: HMAC-based). As said: a simple “mathematical formula” won’t do it. Only a cryptographic algorithm would come near the term “truly random”.

As an alternative: if you want something that’s both cryptographically secure and practical to use (which you indicate to be your main issue), you should definitely look beyond OTP. For example: stream ciphers like Salsa/Chacha. In the broadest sense, stream ciphers ”simulate” the one-time-pad idea. Using them you wouldn’t need to think about working around OTP annoyances.

Also, I think it is worth noting that there’s nothing wrong using good, well-vetted block cipher like AES/Rijndael.

(Funny enough, you could even use a block cipher like AES to create a CSPRNG construction which you could then abuse to create your one-time pad values. But that’ld be overkill since AES does a good job when it comes to encrypting data – which makes considdering OTP pretty superfluous.)

Answer 2

I would like to address two aspects of your question, however, before I do, I must briefly mention "Multiple Use Pads" (MUP rather than OTP). MUPs are similar to OTPs except that, they may be reused in a digital environment, and are practical and efficient - meaning they don't have to be a truly (perfectly) random byte array.

1. "The new key must be as random and secure as the original key". as e-sushi pointed out, the concept of a truly random OTP that is computer generated is unrealistic. That said, my approach and research has focused on "re-use" so that it isn't necessary to obtain additional MUPs; if a new OTP is needed for each new message (as it was with paper and pen: see Venona project), then OTPs will never be practical and secure. This goes to the second aspect or your question that I would like to address below.
2. "Mathematical formula". Allow me to begin by saying that I see math more as a 'pattern' based vision that uses discipline and appropriate skills to generate algebraically based expressions (known as formulae). Not all patterns can be confined to an algebraic platform. I have seen many attempts at using formulae, such as generating the OTPs with a smaller key. Bottom line, a smaller generator effectively results in, not a true OTP, but a much smaller "key" (generator) that can be broken/discovered.

Bottom line: gain the advantage of "unlimited key sizes" without the need to generate a perfectly random byte array, and without the vulnerability associated with key reuse.

Note: I am new to this site, and have just become aware that I must cite that I am the founder of CORAcsi and the developer of MUPs.