Schneier on Security

I think that there is a bias against OTP among cryptographers because OTP takes a problem that you need a cryptographer to solve -- message security -- and turns it into a problem that you don't need a cryptographer to solve -- key distribution. Cryptographers do not like approaches to problems that make them irrelevant.

For some situations, the key distribution is not a problem, such as in the military, if you want two bases, or a ship and a base, to communicate securely. It can also work for two persons who know each other and are sometimes in the same place at the same time, and other times are apart.

What about Michael Rabin's hyperencryption concept? Isn't this a kind of OTP with a clever solution to the key distribution problem?

@Ott: The cases you list are very, very unusual. For example, what ship only has the need to communicate with only one base? Most ships have to communicate with many more units in order to be of any use.

So, no - there is no conspiracy among cryptographers. It is just that the vast majority of cases involve a whole heap of people who need to talk to each other securely. And for that, OTP sucks.

@ThM: The hyper encryption concept has an easier key distribution problem than the OTP, but remember that the reason Public Key Cryptography was invented was that it was just too much hassle to exchange all those secret keys being used in symmetric ciphers!

So HE has the security of OTP (good), but the same key distribution problem as symmetric cihpers (bad).

Quantum key distribution can be used to create OTPs. Still inconvenient and cubersome and with serious limitations.

When I was in the Army, in the Signals arena (MOS 31k, a "wiredog") we used one time pads. Distributed in booklets, monthly, to be used only for short tactical messages. Never actually used it, as we had secure commo gear.

I have to disagree with OTPbeing less secure. Key distribution is not such a big issue for OTP becuase they are not supposed to be common. OTP is best used for special high security messages of limited length between two parties. I would suggest it is not a problem of good or bad systems but understanding which system is appropriate for your particular use.

As somebody who HAS dealt with private keys, I can say that private key distribution is, to some extant a "solved problemm" but one with significant operational issues.

Keying material for the entire operating period must be distributed beforehand. Particularly, with a one time pad, if you have a secure way of sending new keys, you could just use that to send the message. You need to be able to secure unused keys in a manner that prevents any surruptious access. And you need to be able to securely and confirmably destroy used keys.

Broadcasting isn't a problem per se, you just distribute the key to everybody. But of course you have multiplied the points of failure because the compromise of/by any of the recepients compromises ALL of the messages.

@djdii: Nobody's denying that OTPs are the correct choice in some circumstances; the argument is just that OTPs have a large problem in key distribution that prevents it from being useful in every situation where secure encryption is desired.

Seems to me that what a OTP is good at doing is batching secure communications. Suppose you send me a DVD-ROM of random numbers. This is a slow process. If you send it by courier it could take days. Once I have it, we can communicate at normal speeds, and if we do it right we have guaranteed permanent secrecy.

Obviously a OTP is not a general-purpose communications system. It requires more attention to physical security, and it's slow and expensive to set up. It is an attractive option for ultra-high-security communications between two or more highly secure locations.

As far as I'm concerned, OTP seems to be incredibly irrelevant today. Even for high security applications, it wouldn't seem to offer any advantages over a good symmetric cipher. Yes, OTP unbreakable in theory, while a symmetric cipher is not, but in practice, encryption systems aren't broken by attacking the algorithm.

Arguing that OTP works when you've solved the key distribution problem doesn't change things. If you've solved that, then even if you use a symmetric cipher, you've eliminated many of your issues. And as history has shown, a lot of potential issues remain...whether you use OTP or AES. The encryption algorithm you use only plays a small part in the overall security of your system, and I think the history of broken crypto suggests the algorithm doesn't even play a major part.

Cryptography as a mathematical discipline is light-years ahead of cryptography as an engineering discipline. The algorithms we have now are so good, and the systems they are used in are often so bad, that replacing the algorithm with a theoretically perfect encryption method like OTP wouldn't improve your overall security by very much. Venona proves that pretty well, I think.

Granted, OTP presents unusually difficult key security problems. But the cipher can be used to encrypt and decrypt messages in the field, quickly, and by hand, even by people who can't do complicated arithmetic in their heads.

Is there *any* other strong cipher that offers this level of cryptographic security that can be worked by hand?

I think pads are great for those one-time-only crucial messages that on rare occasions are actually useful.

So if "the eagle flies at dawn" means "invasion at normandy" and the "horse flies like dung" means "invasion at calais", you've got yourself a pretty useful communication approach, as the messages are high value, low bandwidth, and will never be repeated.

So categorically banishing one time pads as useless is a mistake. But it's clear and I suppose obvious that highly appropriate uses are not all that common.

"The randomness requirement means that the values cannot be generated by any algorithm; they really have to be random, and created by a physical process, not a mathematical one."

Physical process that cannot be modelled mathematically?

How strong is this requirement really?
x = sin(2*pi*n) for n = 0..N, is a valid event/outcome for some random process X, unlikely but valid.

What about self-modifying code?

And finally, formulae that touch on Gödel's incompleteness theorems.

I have even more tricks up my sleeve but would first like to hear how you guys respond.

Maybe one-time pads will come back about the same time that working memory implants for human brains are developed. Then you could just chip everyone with a few terabytes of random data sometime in early adulthood and only activate the OTP implants of those who needed secure communication.

(Yeah, I know this is an unlikely scenario. But I'm trying to highlight another set of problems with OTP. In addition to secure key distribution, you need secure, reliable long term key storage at both ends of the connection. Otherwise the sleeper agent gets the crucial message containing the plans to Dr Evil's laboratory -- in pdf, of course -- and after 12 years in the field can't find the USB 0.5 thumb drive with the OTP on it, or can't find an adaptor to plug it into a current machine...)

"Is there *any* other strong cipher that offers this level of cryptographic security that can be worked by hand?"

Yes. Dead people don't talk, cryptographically speaking. :P

One problem with OTP is that it can not be 100% random, it needs to be filtered to fit the constraints of the plain text used alphabet size.

In a 100% random system an endless run of zeros or ones or some repeating patern is "par for the course" (ie run length is unbounded).

Even though this issue has a very low probability this is obviously unacceptable for an OTP as the resulting cipher text will start showing the statistics of the plain text. Effectivly it becomes the same as using the same tape twice etc (and as VENONA showed some people will look for any opening they can get).

There are two obviously methods to fix this the first being fix the statistics of the plain text (usualy weak) the other is "filter the noise" of the random input in pad generation (usualy strong). In practice it is wise to do both.

All though the OTP has many issues that make it impractical for ordinary use, it still has an important use in key distrubution in an emergancy.

That is if for some reason a working key is lost or destroyed and cannot be supplied by the normal channels an emergancy OTP alows the exchange of a (new) key with just a pencil and paper.

However it does require an additional protocol to prevent certain types of attack that effect all stream ciphers, including hostile/duress use of the OTP.

However apart from exceptional use the OTP is generaly a curiosity that is of more use in authentication than in confidentiality and as noted if not used with other protocols suffers from all the problems any other stream cipher suffers from (apart from key prediction ;)

In most cases I would much rather stick with a modifed form of CTR as this at least limits the run length problem to at most 3B - 2 bits (where B is the number of bits in the cipher block).

Oh and do be carefull if you do try and use two or more CTR's combined as the run length problem can effectivly become unbounded again if you don't take care.

@paul: Either everyone has different sets of random data, in which case OTP crypto won't be possible, or everybody has the same set of random data, in which case you have the far more difficult problem of controlling access to the random data in every person who has it implanted. How can you trust a OTP cryptosystem where _everybody_ has a copy of the keying materials?

Now that USB thumb drives are so cheap and have such large capacities, I'd think that they'd be an ideal vehicle for distributing an OTP.

Perhaps combined with some steganography so the OTP is hidden inside a bunch of pictures, audio podcasts or video files on the USB flash device?

You'd probably only want to hide a small number of megabytes of OTP on an 8GB USB stick. But that should be enough to let your secret agent send/receive text e-mails for many months without running out of bits.

@john hardin:

Everyone has a different set. I'm positing some miraculous central authority that securely stores all the sets (and hands segments of them off as needed). Unimplementable, you say? My bad.

@ anonymous@10:15AM,

"I have even more tricks up my sleeve but would first like to hear how you guys respond.

The simple answer with a determanistic system is, "it is a question of state".

All determanistic systems that generate sequences require state information to be kept in order to calculate the next output.

Obviously the state is stored in some kind of finite memory device.

This has two conciquences, the first is that the state is obviously bounded at N bits (the size of memory used). This means that the maximum number of states is 2^N after which the sequence repeats.

The second less obvious problem is permutation of these states is effectivly governed either by fixed logic or fixed logic with further state information. It can be shown for non trivial sizes of memory that the number of possible permutations excedes the size of the state memory therefore only a subset of those states is possible.

This gives rise to the issue of predictability of the sequence in use by the logic.

It has been shown for many PRBS generators that if you have the output upto 2 times the number of state bits (ie 2N output bits), then the entire sequence of the generator becomes known to an attacker (this is a consiquense of amongst other things using mod2 addition in the feedback logic).

Therfore it can be seen that in general all determanistic generators become "known" at some point.

However two points arise from this, the first being how difficult it is to determin the sequence of the PRBS, the second is what if you change the sequence using a true physical random generator (TRNG) before the point at which the PRBS becomes known.

A case in point is the RC4 cipher it's output function is to add together two 8bit numbers and use the result to look up another number that is then output.

What if you had a TRNG that added a third number before the lookup of the output number?

Provided the TRNG changed it's output frequently enough then determining the output from the modified RC4 would be at some point moved from just possible to impossible.

Such systems are used to effectivly spread the entropy of the TRNG across the output of the PRBS producing many more effectivly random bits than the TRNG is capable of, and importantly in a dependable way.

I forgot to add a rider on,

'Therfore it can be seen that in general all determanistic generators become "known" at some point.'

In my above post of,

There are some generators such as the Blum Blum Shub ( http://en.wikipedia.org/wiki/Blum_Blum_Shub ) that are "theoreticaly secure" based on the presumption that certain functions can be truely "one way"

@paul: Would you use a cryptosystem that relied on a central authority to hand out copies of the keying material?

OTP reminds me on an SNL sketch, "Johnny Canal", in which John Malkovich played a canal advocate trying to get a network of transportation canals built.

"It's simple. If you need to get from New York to Boston, you get on the New York-to-Boston canal. If you need to get from Boston to New York, you get on the Boston-to-New York canal."

OTP reminds me of this:

http://www.theonion.com/content/node/39241

"Strom Thurmond Calls For Construction Of Transcontinental Railroad"

One thing occurred to me that is relevant here. I realise that because you can't generate OTPs or cryptographically secure random numbers algorithmically, this must be flawed, but I'm not entirely sure why. It's my own personal invocation of Schneier's Law.

However...

The digits of Pi, as far as we can tell by all existing statistical tests, are random. There is no pattern or long-range repetition to be found.

Therefore, if you pick a sufficiently large secret number X, then for a given message of length N, you could "create" an OTP of length N using the Xth to (X+N)th digits of Pi.

Also, because of the Bailey–Borwein–Plouffe formula, it is possible to calculate the Xth to (X+N)th bit (binary digit) of Pi without needing to first calculate the 0th to Xth bits.

Therefore, as an encryption algorithm, why not:

1) Generate/exchange a shared secret (the key) - e.g. "password"

2) Hash the key somehow - e.g. using crc32 on "password" we get 0x35c246d5.

3) Use the hash as a numeric index into the digits of Pi - e.g. 0x35c246d5 is 901,924,565, so your OTP starts with the 901,924,565th "bit" of Pi.

4) Keep generating bits of Pi for as long as you have bits in your message, and XOR them together.

I totally believe it won't work. But I'm not sure why, or where the weakness is. Is Pi not actually "random enough"? Is it something else?

During WWII the USA just hired a bunch of Navajo and solved the problem that way. Sounds like a great excuse to fund a ton on linguists and document all of the "dying" languages out there to me.

I don't know for a fact, but I would bet that OTP are used for guided weapons. A OTP can be downloaded into a missile, which is then fired, both parties can communicate securely until the missile arrives and explodes. Also I would imagine a similar system is used for fighter planes and aircraft carriers.

Correct me if I'm wrong, but the primary (only?) advantages of OTP are that; the key distribution problem can be handled any time before the message needs to be sent, it has very weak latency/time requirements and failures are not fatal if they can be detected before the key gets used. This implies that good OTP can be set up to only depend on good *Physical* security

The only difference between a key for a strong symmetric cypher and a one-time pad is size. The only reason OTP distribution is any more difficult than key distribute is that it's slightly inconvenient to distribute a 1 PB OTP, vs a 256-bit key. This becomes less of a difference over time.

Distributing a 1GB OTP instead of a small key would work fine in manu contexts today. Easy distribution of a 1 TB OTP is easily imaginable in my lifetime. Eventually, this becomes a non-issue. Of course, generating 1 PB of genuinely random data is a bit of an issue, but on the whole the OTP aproach gets better over time, which any specific symmetric encryption algorithm only gets weaker over time.

Bruce may be right for the rest of our lifetimes, but eventually everything will be OTPs, since we know "you can't hide secrets from the future with math."

@Skorj: Except there is a difference. When we distribute a 256 bit symmetric key, we do so by wrapping it in even harder asymmetric encryption. So, in order for an adversary to get our key, they'd have to break something even harder (the public key encryption). If we were to distribute the OTP, we'd have to wrap it in something even harder to crack - and there isn't anything.

Sure, you can distribute an OTP using Public-key crypto, but since it is weaker than OTP, why bother? Just send the message using PKC and be done with it.

@Karellen:

Just a guess here: What you have done is essentially "compressed" an OTP. Instead of sending the key, you send the offset into Pi. But you still have to send this offset.

But you still have the same problems as with an OTP:

1. Not reusing the same key. (Reusing OTP)

2. Distributing multiple keys (for multiple messages) securely.

...and so on.

@ Karellen,

"Also, because of the Bailey–Borwein–Plouffe formula, it is possible to calculate the Xth to (X+N)th bit (binary digit) of Pi without needing to first calculate the 0th to Xth bits."

Your mention of the Bailey Borwein Plouffe (BBP) formula tickled my old grey cells and I remembered an improved version was used in the Pi Hex project (which was a bit like the SETI@home project).

I googled it up and posibly found the problem you where looking for...

The Pi Hex project took something like 2 years and 1.2 million P90 CPU hours spread across a couple of thousand PC's to find three bits one of which was at bit position 10^15 + 60.

http://oldweb.cecm.sfu.ca/projects/pihex/...

So it is not exactly quick, I guess you could say it has done a memory/time trade....

You also need to consider that 10^15 (app 2^50) bits is not exactly a long way into Pi when compared to the length of sequence you could have generated with AES128 in CTR mode.

Also I confirmed my other grey cell nagging that the BBP has an issue.

BBP has problems with long runs of 1's in that you get uncertainty due to precision and rounding in the size of the computer "word" used.

However the BBP has been used to find other values as well as Pi so it has some utility.

Karellen,

In any truly random sequence of digits, there will be occasional runs of zeros. I think the formula for knowing what the chances are to have a sequence of consecutive zeros is
1 - ((1 - (0.1 ^ k)) ^ (n - k + 1))
where k is the number of consecutive digits, n is the length of the entire sequence, and ^ is the exponentiation operator. If that is the case, 100 truly random consecutive digits have a 63% chance of having two consecutive zeros, a 9.3% chance of having three consecutive zeros, and a 0.00000089% chance (about 1 in 110 million) of having ten consecutive zeros. If that happens in the wrong place, then simply XORing will definitely not help. Modifying your algorithm to avoid runs of digits in the key might open it up to other attacks. Any cryptographers should be able to tell you why. I certainly don't know.

Embassies communicating with their governments seems like a good fit for the use of OTPs. You have high security physical channels to distribute the OTP, and you know in advance that there is only one party to communicate with. Distribution can be in some compact digital medium (eg USB stick) stored in a tamper-proof container. Protocol is to securely erase the pad immediately after sending a message, even if you haven't used all the bits. The need for confirmable secure erasure probably dictates your choice of medium. (Paper tape would be great except the bit density is too low.)

@Clive, Shawn

I don't believe runs of zeroes/ones would be a practical problem.

Firstly, you *will* compress the message first. Those key-bits are expensive, so you shouldn't waste them. (Humans can and have used codebooks for this.)

A good compression algorithm will remove most all of the context an attacker would need to distinguish a plaintext fragment from a ciphertext fragment.

Secondly, there is some nonzero probability that data will encrypt to something that *looks* like plaintext. Provided this probability is equal to the probability of a zero/one run, an attacker can't know whether the 'plaintext' is just their own fantasy...

tcliu - yes, but because proper OTPs are random, they are normally uncompressable. So, being able to compress an OTP means that you "just" have a key-exchange problem. And, as Bruce pointed out, we already have some key-exchange algorithms, and if all we need to do is work on them instead of the encryption as well, then that makes things easier.

@Karellen: Yes, but those key-exchange algorithms are used for exchanging a "weaker" key by wrapping it in a "stronger" crypto.

What you want to do is exchange an incredibly strong key by wrapping it in a weaker crypto.

For example, would you exchange an AES key by encrypting it with ROT13?

@tcilu - I thought we exchanged symmetric keys inside public-key crypto because doing symmetric encryption is easier (e.g. less CPU-intensive) than public-key encryption.

Similarly, exchanging a 256-bit index into the digits of Pi is easier than exchanging as many bits of OTP as there are bits of message.

Yes, as you note, when exchanging symmetric keys you should use public-key crypto that is at least as strong as the symmetric cipher you are using (dependent on how you compare the relative strenghts of symmetric and public-key crypto, obviously), so therefore when exchanging a key into an infinite OTP you should again use a form of key-exchange that is at least as strong as the *key* you are exchanging.

(Note - although real OTPs are effectively unbreakable, if you have an infinite but known OTP which you index with a key, then the attacker still only needs to "search a keyspace" as big as the key you use to index it. Also, while it is possible that many keys will return a legible message, the number that do will decrease with the length of the message. It should be possible to calculate how many legible messages are likely given a particular key size and message length. If that number is small enough (less than 1?) then if an attacker does search the keyspace and find a legible message, then they can be confident that they have found *the* message, something that *is* impossible with a true, completely unknown OTP.)

@Clive Robinson

Ah yes. I see my mistake.

I had misunderstood BBP and thought that because it did not need to calculate digits of Pi preceding the one you were interested in, then it could calculate each bit of Pi in constant (O(1)) time. Looking more closely, this appears not to be the case.

Which is why the system is not computationally feasible.

Thankyou.

@ tcliu,

"For example, would you exchange an AES key by encrypting it with ROT13?"

Well if the AES key was truely randomly generated, how would you tell how it had been encrypted?

You could look at it as an OTP in reverse where you use a known plaintext to recover the random key.

Providing your oponents do not know (nor can work out) what the plain text is then...

@Clive
In addition to the runs of constants. In a large enough set of random characters you are going to have sections that repeat previous sections which is equivalent to reusing the same OTP.

RE: "Well if the AES key was truely randomly generated, how would you tell how it had been encrypted"
Security through obscurity, really, Clive?

@Karellen
Apart from the time constraint. Once you have function for creating your next random bit then you are no longer using a OTP, you are using a stream cipher. Your security, in that case, is supposed to reside solely in the key, not in the secrecy of your algorithm. The key, in the BBP idea is a relatively small integer. All I need to do is start cranking out digits of pi until I find the right ones (and keep all of them to decrypt future messages)
--
JimFive

It's worth going out to the original article and following the links down to a copy of Vernam's original paper on the subject. In fact, only about one third of the paper is actually about one-time pads (a phrase which apparently does NOT appear in the paper), while the rest of it is an interesting overview of the state of both crypto and codebreaking at the time.

He also recognizes the potential drawbacks of very long one-time pads, and devises some nice alternatives to allow trade-offs between security and practicality.

It's historical, and thus not up to date, but still quite interesting.

As a final note, I always think it's worth knowing what has come before. At some point, you might need to make a design trade-off -- such as working with massively limited computational capabilities -- and need to design within them. At that point, your knowledge of the point in history when "massively limited" was the norm will come in handy.

@ JimFive,

"Security through obscurity, really, Clive?"

No, I was just making the point that in effect encrypting a truly random string (the AES key) with a weak key produces an output that is the same as a plain text encrypted with an OTP.

That is that even after ROT13 a truly random string is still just that a truly random string. And that just looking at the output is not going to give you a clue as to the system in use.

And thus as long as the method is only ever used once the security would be the same as an OTP.

However if your AES key is not truly random or you use the method more than once, then as you say...

"So, being able to compress an OTP means that you "just" have a key-exchange problem."

@Karellen: The *only* problem with OTPs is the key exchange problem. If we had solved that one, we'd all use OTPs. But we don't. That's how hard it is.

"we already have some key-exchange algorithms"

But none of them are as strong as OTP. A cryptosystem is only as strong as its weakest link. If the key exchange protocol is weaker than OTP, then, well, what's the point - the whole system isn't as strong as OTP. If the key exchange protocol is as strong as OTP, then, well, what's the point - just exchange the message and be done with it.

There are situations where a OTP is perfect. The classic use is Navies, who have the power to securely transfer the OTP from the secure communications center to the secure locker aboard the ship. Once done, all transmissions can be reasonably expected to be secure.

You could do the same with anything that physically moves form a home base, assuming you can afford the key storage (since it's size is rather large).

I certainly hope they're using OTP to remote-operate those hellfire-equipped predator drones, for instance. Combat aircraft could also use them. (Take the OTP from the comm center to the plane just before takeoff)

Of course, most of the time, communications isn't like this. Most communication is between two widely separated points that don't directly meet and data transfer is voluminous, far beyond the practicality of OTP.

Cryptographers don't like OTP both because of its limitations and also its inherent unbreakability. Let's face it, nearly every cryptographer gets a particular thrill out of the possibility, or at least, the conceivability of breaking a code.

There is nothing wrong with that, especially since OTP is essentially "complete". There is no more research to be done. No next level to take it. We know it's limitations and it is extremely unlikely for anyone to ever overcome them.

@b:
> There are situations where a OTP is perfect.

Indeed, but there are very, very few. Even some that might seem to fit the bill at first glance actually do not. For example:

> The classic use is Navies, who have the power to securely transfer the OTP from the secure communications center to the secure locker aboard the ship. Once done, all transmissions can be reasonably expected to be secure.

Alas, no. OTP is not very useful to navies. The reason is key management in a multi-node network. Any given warship may need to send a secure signal to any other warship at least within its own fleet, and possibly to any other warship in the navy. If we use OTP to protect those links, then we have two choices:
a) Have only one, or a small number, of OTP channels shared between multiple users and require every vessel to keep tabs on which pages of the pad have been used. And of course, the moment that a vessel re-uses a page (for example, because it was out of communication range at the time that page was used) security fails completely. OR
b) establish a dedicated OTP set for each potential channel. This requires n(n-1)/2 sets of pads where n is the number of endpoints. For example, if you have just 50 vessels in your fleet, you need to distribute, manage, securely destroy and periodically replace 1,225 sets of pads. You need to somehow keep all of those in synch, regardless of the varying cruise durations of all those ships. Any time one of your vessels is lost -- even the tiniest little corvette -- you need to *immediately* redistribute the entire set, worldwide. This is a nightmare scenario which, as is typical for OTP systems, solves a relatively easy problem (strong ciphers) by greatly complicating the difficult one (key management.)

Given that all known failures in USN cryptology in recent times have been due to suborning of personnel involved in key distribution, I really don't think navies would be very interested in a solution that gives a hundred times more opportunities to the Walker families of the world.

Another issue is that the actual fleet broadcast system (apparently) continuously transmits nulls when there are no messages to send, so as to prevent traffic analysis. This means an immense volume of pages for each pad would be required for a long voyage.

> You could do the same with anything that physically moves form a home base, assuming you can afford the key storage (since it's size is rather large).

Only if it requires communication solely with that home base. Once you want to network with other friendly units, the complications rapidly multiply.

> I certainly hope they're using OTP to remote-operate those hellfire-equipped predator drones, for instance.

I doubt it. For one thing, the volume of data being transmitted from the drone is immense (many hours of real time high resolution video from multiple imagers), and in any case most of it is only tactically sensitive (i.e. we don't really care if the enemy cracks the cipher next week, just so long as they can't do it right now.)

In terms of the link in the other direction (command link), the most critical feature you require is not confidentiality but authentication. That is, you couldn't care less if the enemy finds out that you just sent the command "fire missiles" -- they'll know within a few seconds anyway -- but you really, really do not want them to be able to send a fake "fire missiles" command themselves. And whereas OTP provides perfect confidentiality when used correctly, it provides very weak authentication, making it an extremely poor choice for this application.

Another important aspect in this scenario is jamming resistance. There are many aspects to jamming resistance but from the point of view of choosing a cipher, you want low error propagation and self-resynchronisation. OTP does have low error propagation but it has no resynchronisation features whatsoever, making it, once again, a poor choice anywhere that may encounter electronic warfare.

> Combat aircraft could also use them. (Take the OTP from the comm center to the plane just before takeoff)

No, once again we have the multi-node network problem, but now you have it in spades. That aircraft requires secure communications to not only every other aircraft in the theatre, but also to all friendly ground units (possibly from multiple nations.) You still get that n(n-1)/2 problem but now, in a full scale conventional war n is many hundreds and may be as much as thousands. You need to update the lot every time a special forces FAC stops responding from his hidey hole behind enemy lines, even if it's probably just a flat battery. When you do the update, you somehow need to get to all those units, and all those FAC hidey holes behind enemy lines.

[...]

> Cryptographers don't like OTP both because of its limitations and also its inherent unbreakability. Let's face it, nearly every cryptographer gets a particular thrill out of the possibility, or at least, the conceivability of breaking a code. [...]

Certainly cryptographers find OTP trivial and *boring*. But that is by no means the only reason they dislike it so much. The main reasons, in my experience, are that OTP is so simple that:
a) the basic idea can be, and repeatedly is, re-invented by people who have simply skimmed through an introductory book -- people with such a limited knowledge of the field that they tend to seriously believe they are introducing something new and insightful, and develop unattractive and annoying persecution complexes when their idea is rejected; and
b) the basic idea can be grasped by people who -- not to put too fine a point on it -- do not have the mental equipment to grasp its weaknesses.
Putting these two features together means that trying to explain the finer points of OTPs rapidly becomes a pointless waste of life force.

@Roger:

>OTP is not very useful to navies. The reason is key management in a multi-node network. Any given warship may need to send a secure signal to any other warship at least within its own fleet, and possibly to any other warship in the navy.

You're making sweeping assumptions that make no sense at all.

Why do you assume that intra-ship communications is a requirement? Much like a police department or airline, you only need to be able to talk to a central dispatch.

Why do you assume that high volumes of data are required for communications? VLF/ELF transmissions with tiny amounts of bandwidth are still used to communicate with submarines. "Launch missile 2 to target C", or "Under attack, map grid gx452" don't require alot of data to express.

Why do you assume that key management is impossible? You have a finite number of ships, which will be at sea for a finite number of days. Someone creates the keys and delivers code books/code disks to the commander when you deliver the ship's mission orders. I'm sure this is done today.

At some point, you need to trust someone. If your communications/encryption guys and the guy commanding a boat with a few dozen nuclear warheads is betraying you, you have other problems.

It's easy to get spoiled by high tech and high-bandwidth. Once somebody like Iran or North Korea figures out how to shoot down a satellite, un-sexy technologies like shortwave radio are going to look pretty good. (And unmanned drones over Afghanistan controlled from Vegas are going to look rather dumb.)

Why do you assume that intra-ship communications is a requirement? Much like a police department or airline, you only need to be able to talk to a central dispatch.

This comms scheme would break down as soon as it went into action; both aircraft and policemen frequently want to communicate peer-to-peer, and ships operate in groups. The Royal Navy tried to micromanage the whole bang shoot from the radio antennas on top of the Admiralty building in 1914 and it didn't work at all well.

Further, the problem with sending OTPs to sea in ships is: what happens when the key is compromised, because it will be compromised? You've got to bring all the ships back to ports considered secure enough, and then bring the OTPs securely to them. And the enemy will be delighted if your navy vanishes from the seas every time there is a security panic. (Also, NATO and allied ships operate together, so you need perfectly secure INTERNATIONAL OTP distribution and revocation...)

Similarly, OTPs for drones have a serious problem; one end of the communications link may be at Nellis AFB, but the drones take off from dangerous forward locations where they are apparently serviced by Blackwater personnel. So, you've got to either set the OTPs before they are shipped, and then deal with the problem of resetting them in the field, bring them back to reset them, accepting the denial-of-service, or else trust a bunch of mercenaries who aren't officially in northwestern Pakistan with the OTP.

Once somebody like Iran or North Korea figures out how to shoot down a satellite, un-sexy technologies like shortwave radio are going to look pretty good. (And unmanned drones over Afghanistan controlled from Vegas are going to look rather dumb.)

In which case, the crypto must go into the field. And once forward air controllers are walking about on Afghan mountains or in Iraqi bazaars with'em, you have no chance of securing the OTPs.

Regarding runs of zeros:

The simple fact from modern cryptography is
Size of key space >= size of message space = size of encrypted message space.

As soon as you start removing special "dangerous keys" from the key space, you immediately loose perfect secrecy.

Eve wears a badge said:

"I don't know for a fact, but I would bet that OTP are used for guided weapons. A OTP can be downloaded into a missile, which is then fired, both parties can communicate securely until the missile arrives and explodes. Also I would imagine a similar system is used for fighter planes and aircraft carriers."

That's incorrect. All targeting data are uploaded into the missile before launch. Once the missile is launched, it's on its own, and can't communicate with the anyone. (I know. I used to work with both the Poseidon and Trident missile systems.)