It seems that OTP encryption is unbreakable. I have read some articles (Wikipedia, Blogpost, etc.), but I could not find any information about how they are used.

If I wanted to create a messenger service, how would I distribute the OTP keys? Both the sender and the receiver need this key before the message is sent, right?

And how do I make sure no one else gets these keys?

  • 1
    $\begingroup$ The receiver doesn't need the "key before the message is" sent; the receiver only $\hspace{1.45 in}$ needs the key in order to decrypt the message. $\:$ $\endgroup$
    – user991
    Apr 23 '15 at 8:58
  • 7
    $\begingroup$ Both parties could meet in person and exchange a disk containing the pad. Or perhaps you send a diplomatic courier with the key material in a sealed bag. The annoying key-distribution is one of the reasons why one-time-pads aren't very popular. $\endgroup$ Apr 23 '15 at 9:38
  • 1
    $\begingroup$ OTP has only a very limited scope where it is actually useful, it is more interesting from a theoretical point of view (that it is provable unbreakable - under the assumption that the key known only to the participiating parties and no one else): If you a) have a secure communication now and b) can make sure that the key is stored securely, then you can use OTP in the future to send a message. But the fact that the key needs to be as long as the message itself still limits it quite severely. The disc for a meeting in person or via courier are examples of that "save channel now". $\endgroup$
    – tylo
    Apr 23 '15 at 10:46

If you perform the distribution digitally (using networks) then you have a problem. Unless you use another one time pad you lose the perfect confidentiality as the distribution itself won't deliver perfect security. But using another one time pad is pointless: you would lose exactly as many key bits as you are distributing, while you are only protecting the data for confidentiality, not integrity and authenticity.

So basically you'll probably have to physically distribute the keys. That kind of burden is probably not very useful. Hence we mostly treat the one time pad as a theoretical cipher. One very big reason for this is that - although not proven secure - there are many (stream) ciphers that are thought to be secure. There is simply no need for a one time pad.

So the key management / key distribution is extremely awkward for one-time-pads not just because of the size, but also because anything you do with the key breaks the perfect secrecy you are trying to achieve.

  • $\begingroup$ i have been thinking about this a lot yesterday. what if: i encode a message base 85 then encrypt it with a onetimepad (that was physically & securely exchanged). use this onetimepad to encrypt and newly create onetimepad and send both the message and the onetimepad to the recipient. now the receiver of the message gets the message and a new onetime pad for the next message. it may be a two time pad but only arbitrary data (no proper words) were encrypted. is there a problem with that? btw i claim © copyright to this idea 😃 $\endgroup$
    – yamm
    Apr 24 '15 at 7:40
  • $\begingroup$ Yes. As explained you need as many bits from pad 1 to distribute pad 2. The net effect is that you have exactly as many bits left, minus the ones you used for the (encoded ) message of course. And the bits may be changed by an active attack on top of that. $\endgroup$
    – Maarten Bodewes
    Apr 24 '15 at 7:46
  • $\begingroup$ as i understand the problem with reusing onetimepad is that you attack it with either Frequency analysis and pattern matching. this doesnt apply to encoded data, right? $\endgroup$
    – yamm
    Apr 24 '15 at 7:53

Use a trusted messenger. If possible, transfer the OTP yourself.

Sending OTP keys over the Internet is usually not a very good idea because "the distribution itself won't deliver perfect security" and one must worry about "integrity and authenticity", as Maarten Bodewes has said. Moreover, it is reasonable to assume that using a OTP might attract some eyeballs, automated and otherwise, onto your traffic.

There is another option: steganography. But you are still going to burn a lot of your precious truly-random bits because you do not want to send any of your keys unencrypted.

An advantage of using a trusted messenger that is seldom brought up is how one can limit metacontent (metadata) during key exchange. Look at it as a security question and then a choice: what collection platforms are there likely to be, and does it matter whether I get on them or not?

Create your OTP on an air-gapped device that has never (and cannot) touch the internet or any other device whatsoever, then lose your phone and put the OTP in your future correspondent's hand.


Your question is now 4 1/2 years old, and things have moved on for pad distribution (at least in the professional arena). Hobbyists are still stuck with pigeons and USB drives secreted about their bodies, having clandestine meetings and physically exchanging bits.

Professionally, there are an ever increasing number of quantum key distribution networks (QKDNs) which send the OTP material via laser beams. In essence it happens like the following, with ALICE beaming her true random bits from her TRNG (typically a beam splitter) to BOB:-

enter image description here

After some processing and validation, BOB and ALICE are both in possession of key material suitable for OTP use. Voilà.

And as for "how do I make sure no one else gets these keys?" It doesn't matter. The distribution of the photonic based keys is governed by the Observer effect which means that in an ideal QKDN, if nasty EVE reads the photons, ALICE/BOB will be able to tell as their polarisations will have changed. They then invalidate that particular key transmission and redistribute. There are more nuances to QKDNs than punched paper tape distribution used to have, but essentially the focus of trust shifts from the courier to the QKDN provider.

Image is an extract from a longer answer...


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.