# 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.

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.)

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.

• "Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin." (John Von Neumann, 1951, quoted by Donald E. Knuth at the beginning of chapter three on Random Numbers in TAOCP volume 2, third Edition).
– fgrieu
Commented Jul 21, 2018 at 16:33
• This saying by Von Neumann was very cute for its time but is it really true? There is a whole industry dedicated to designing PRG's that attempt to do exactly what Von Neumann was warning against: taking a truly random small seed and using the seed in a deterministic algorithm ( arithmetical method) to generate a longer pseudorandom string that is indistinguishable from a truly random string. The loophole that lets us "get away with this" is that randomness is in the eye of the beholder. Commented Jul 22, 2018 at 14:09
• I love the missives and concepts involved. I'm not sure that there is such a thing as a 'truly random seed'; one may find patterns in "cosmic noise" - so would even the cosmos produce a truly random - anything? One should argue that the pattern I find may not be the same pattern that another would find (in cosmic noise). The underlying question is this, especially in considering 'the eye of the beholder': 'if a pattern will always appear, is it repeatable and/or consistently identifiable?' Commented Jul 22, 2018 at 18:45
• @PaulUszak: Yes Paul, we think these physical processes are truly random, but can you create a binary string based on these phenomenon and PROVE mathematically in ZFC that the string has no hidden pattern and therefore it is next-bit unpredictable? Commented Jul 25, 2018 at 23:40
• @JosephLatouf Sorry, but this answer is promoting snake oil. Commented Sep 3, 2019 at 0:32