Mathematical formula for switching the key for OTP? 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.
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…


a truly random one-time pad value,
generated and exchanged in a secure way. 
at least as long as the message, and
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.)