Talk:One-time pad

Padding as a form of authentication?

I've removed the following claim, because it is not backed up by a reference.

The classical pencil and paper techniques of padding and Russian copulation can block such a substitution attack by denying the attacker knowledge of where to modify the cipher text.

The problem here is that both methods are heuristical and the arguments are mainly based on unproven assumptions. This looks rather odd compared to the information theoretical secrecy of the one-time pad and the security guarantees of the universal hashing. In particular, the supposed strength of adding some padding seems to assume that there is some variable length padding that is prepended to the message. I.e., this is an implicit assumption not made clear in the text. Without a clear definition of what the supposed countermeasures are it is not possible to make claims about the strength of those countermeasures. Hence the text is vague and does not add content to the article. Without a reliable reference it is unclear whether these countermeasures provide significant strength. 62.203.12.206 (talk) 17:15, 26 December 2008 (UTC)

First of all, the entire section on authentication is unreferenced. One time pads were used for decades at the highest security levels and I am not aware of any authentication problems encountered. The substitution attack described in the section is common to all stream ciphers and depends on an adversary knowing the exact offset from the start of the ciphertext to where the characters to be altered lie. It is obvious that random length padding or Russian copulation at a random offset prevent an attacker from knowing this. The best an attacker can do is guess the position, which has a likelihood on the order of 1/n, when n is the length of the padding or the message respectively. While that is not as strong a protection as what can be achieved with modern methods, it makes it much more likely that an attack will be detected than succeed. Also the security guarantees of universal hashing depend on the availability of a trusted computer, something hard to achieve in the real world. We can remove the entire section as unreferenced, but if not, I beleive the comments I added are needed for balance. --agr (talk) 20:31, 26 December 2008 (UTC)

There are two main claims in the contested section: (1) The one-time pad does not provide authentication. Several of the references given for this article talk about this problem. (2) Universal hashing can be used to provied information theoretical authentication. Universal hashing has its own wikipedia article an is reliably source. Furthermore just because something else is not referenced doesn't mean you have a free pass to add whatever you like to wikipedia. Regarding you proposal: a success probability of 1/n (assuming for the moment that this is indeed the correct result) for an authentication scheme that has length O(n) is a weak result, as the success probability is not negligible. Hence such a result is of no interest. A slightly different matter is, if the authentication you proposed was used in the pre-computer age. But again in this case some reliable reference would be necessary and the addition would would probably be better in the history section. 81.62.44.149 (talk) 11:22, 27 December 2008 (UTC)

link back and forthing

An external link to a Javascript implemntation o fa one-time pad has been included, and then deleted and then included again. We're verging on the 3RR rule here, so I thought some discussion would be well. The link is to a dark site (lots of dark gray with lither gray text) which is actually otherwise reasonably well designed.

The trouble is with the underlying design of the program. It is in Javascript, which is touted as an advantage, since it runs on client-side and so doesn't depend on the Internet or any server thereon while it runs. Well, that's perhaps good, but Javascript has a very dodgy history of design security issues, and much history of implementation squabbles (the language specification being somewhat "variable"), nearly all of which is bad from a security perspective, and so from a cypher implementation perspective. But still worse, the program design simply avoids the central issue of the one time pad, to wit, randomness. The programs user is left with finding a source of randomness, and given a few pointers to websites which might help.

This is inadequate and reduces the supposed program's relevance to an article on one-time pads to nullity. A virtuous stance of not attempting to (questionably at best) generate random data programmatically leaves the offered software without any virtue whatsoever.

This should not be a link in this article. It fails any reasonable test of link quality. It should not be allowed to be added anytime in the future as well. There is no reason to believe it will ever become anything like a reasonable link, as the significance of the one-time pad is fundamentally linked to the base concepts of communication and information theory. Don't bring this link back. ww (talk) 21:31, 30 March 2009 (UTC)

superencryption scheme

Shouldn't this "the combination would be at least as strong as the strongest layer." be "the combination would be at least as strong as the weakest layer." The strongest layer is OTP can you achieve the strength of OTP if you combine with another weaker encryption system? To me it looks like the encryption would be at least as strong as the weakest link, but not as strong as OTP, right? Or I totally missed the idea... man with one red shoe 22:09, 30 April 2009 (UTC)

Makes perfect sense to me... If a given message is encrypted using the Caesar cipher, and then with OTP, being able to break the Caesar cipher layer alone doesn't give you the plaintext -- you also have to break the strongest (OTP) layer. -- intgr [talk] 19:10, 1 May 2009 (UTC)

Well, I thought like this, if one-time pad is theoretically unbreakable a combination of one-time pad and another method cannot be "at least as strong as" because you can't have anything stronger than "unbreakable". But I guess in case of the discovery of the one-time pad the cypher would still have the strength of the weakest link... (the difference between "theoretically" unbreakable and the real-life) I still find that sentence a bit awkward... man with one red shoe 23:48, 15 May 2009 (UTC)

I think you have a point here. The statement is unclear and possibly incorrect. It reminds me of the paper by Maurer and Massey "Cascade Ciphers: The Importance of Being First". There the authors show that a superencryption with two ciphers and idependent keys is at least as strong as the first cipher, but not necessarily as strong as the second cipher. If two stream ciphers are used then the order is exchangeable and hence the cascade is at least as the stronger stream cipher used in the cascade. Note they are talking about stream ciphers not OTPs. On the other hand assume that the first cipher in the cascade uses compression. Then the encryption of n random letters is distinguishable from the encryption of n letters 'a', if the latter results in a shorter ciphertext. Hence the cipher is not semantically secure. Adding a layer using a OTP doesn't change the length of the ciphertext and therefore the cascade isn't semantically secure either. Since the statement is confusing, potentially incorrect, unreferenced and simple just doesn't make sense I'm removing it from the article. 92.106.132.178 (talk) 04:56, 16 May 2009 (UTC)

man with one red shoe: Your reasoning is logically inconsistent. "at least as strong as" means "strength is equal to or greater than"; the cascade needn't be stronger than OTP to satisfy the condition; it suffices if it's just as strong. I can't see what's unclear here.

I don't have time right now to digest the paper though. -- intgr [talk] 11:40, 17 May 2009 (UTC)

don't know about that, it might be logically valid but not linguistically correct, for example nobody says "at least as strong as God" you'd say "as strong as God". But I think my confusion here was between theoretical strength and practical (while OTP is theoretically unbreakable, it might still be breakable if somebody recovers the pad, so yes, superencryption would offer more protection, but I would still not call it "stronger than OTP" because it sounds weird in the context) man with one red shoe 15:10, 17 May 2009 (UTC)

Use cases, advantage, etc.

The article talks about the advantage and lack there of of OTP, particularly that to implement OTP you need to securely transport something just as big as the plain text. However it doesn't (or didn't last I checked) bring in the point that the constraints on transporting the key are much more relaxed: 1) It has very relaxed latency constraints in that the next key taking weeks to arrive is not a problem as long as the last key isn't used up yet. 2) Security failures are acceptable as long as they can be reliably detected before the key gets used. In effect, OTP trades one set of constraints for another, sometimes easier, set of constraints.

I attempted to add that in a while back but never really liked what I ended up with (and someone else yanked it back out again) so if someone who is a better writer than I could figure out how to work it in somewhere... —Preceding unsigned comment added by 99.72.154.66 (talk) 20:10, 6 July 2010 (UTC)

How it is impossible if one can check if the final grammar of a text is simply linguistically sane?

I don't get that from the article. --Athinker (talk) 11:30, 7 January 2011 (UTC)

I assume you mean "why can't someone try all the keys and figure out which give a sane output"

The answer is partly given in the "Attempt at cryptanalysis" section. With one time pads, every fitting-length outcome is possible. By applying this proposed cryptanalysis, you will get a list of all possible linguistically sane constructions, but you still don't know which one was intended to be transmitted. Thus you aren't any wiser regardless of whether you have the ciphertext or not. -- intgr [talk] 17:40, 7 January 2011 (UTC)

Error in example?

The example says "If a number is larger than 25, then the remainder after subtraction of 26 is taken in modular arithmetic fashion". Should this not be 26? Paul Magnussen (talk) 18:46, 10 April 2011 (UTC)

The example is correct. The result of the modular operation should be in the range 0 .. 25, since 0 corresponds to A and 25 corresponds to Z. Thus any result up to 25 is in the correct range and any result 26 or higher must be reduce modulo 26. Also, since the addition of two integers <= 25 can be at most 50 it is possible to do the modular reduction with a single subtraction. 85.1.93.222 (talk) 21:26, 10 April 2011 (UTC)

So ... how may pads do you have to use in sequence to beat the best super computer. (answer later) — Preceding unsigned comment added by 71.232.252.76 (talk) 20:25, 25 May 2011 (UTC)

Phony Message

This is about the "Dubious" tag I added to the following sentence: "The straightforward XORing with the keystream creates a potential vulnerability in message integrity especially simple to exploit—for example, an attacker who knows that the message contains "Meet Jane and me tomorrow at 3:30 pm" at a particular point can replace that content by any other content of exactly the same length, such as "3:30 meeting is cancelled, stay home", without having access to the one-time pad."

Something seems wrong. If the assumption is that the key is simple "mod 26," maybe, but the paragraph needs to be more clear, especially for non-experts, like myself.

Take ENABLE, the correct message from BOB, and DEFEND, the phony message Charlie wants Alice to get. For simplicity, everything's just plus one (but Chariie doesn't know that). Therefore, the code is FOBCMF. Charlie can send EFGFOE, which Alice will see as DEFEND, thus being fooled.

But Charlie cannot afford to get the phony message wrong. He must have 3 things: the real encrypted message, the real unencrypted message, and certainty that simple mod 26 substitution was used. He has no way of being certain of this last (unless he has a copy of the key). Just because FOBCMF gets ENABLE, does not mean EFGFOE gets DEFEND.

If Bob and Alice just agree on a different ordering of the alphabet, Charlie is stumped. He might make educated guesses, but the message is too short to be certain of the substitution key.

Different substitution is not universal hashing or message authentication.

This is a very important paragraph in this article. Would someone with expert knowledge please rewrite it so that it is clearer and less ambiguous. Anthony717 (talk) 10:00, 30 July 2011 (UTC)

It's standard in analyzing any crypto system to assume the attacker knows the details of the system used, in this case how the key is combined with the plaintext to encode the message. Also there is no requirement that the attacker knows the unencrypted message, just it's exact format. --agr (talk) 15:22, 31 July 2011 (UTC)

I added the dubious tag to this and came in here to create a section and I find there is already this one. The assertion "an attacker who knows that the message contains "Meet Jane and me tomorrow at 3:30 pm" at a particular point can replace that content by any other content of exactly the same length, such as "3:30 meeting is cancelled, stay home", without having access to the one-time pad" seems plainly wrong to me and needs to be either removed or very convincingly supported. GS3 (talk) 17:23, 30 October 2011 (UTC)

I added a reference to the article. This is very standard stuff; the technical term is malleability. There is a worked out example there and at stream cipher attack. Do a google search on "one time pad malleability " and you'll find lots of other references.--agr (talk) 19:29, 31 October 2011 (UTC)

I am still not seeing it and it goes contrary to everything I know. I would say the opposite is "very standard stuff". The reference link you added just leads me to the cover of a book and I would need to see what it says. Can you cite the exact text and examples which support the assertion? At stream cipher attack I cannot see any "worked out example"; only a bare assertion. Can you please provide a clear supporting citation and a worked out example? For instance, there is a simple example in this article where Alice encrypts the plaintext "HELLO" using the key "XMCKL" which results in cyphertext "EQNVZ". Suppose an attacker wants to change the message to something else *and does not know the key*, how can he do it? I believe there is no way. Please show us how "malleability" allows this to be done because I am not seeing it. I think it is pretty well established and accepted that one time pad keys are an uncrackable system. Thanks.GS3 (talk) 16:31, 3 November 2011 (UTC)

I'm not Arnold, but no, this is a legitimate flaw if you use an invertible function (as stated in the lines leading up to this), and the attacker knows your plaintext. Without looking at your key (except for verification) at the end - if the key is A + B % 26. , I take H (7) + ?? = E (4) (mod 26). Therefore, 7 - 4 = - ?? mod 26. -3 == ?? mod 26. Therefore -3 + 26 = ?? mod 26, which means ?? == 23 mod 26 - which is X. Which should be the key. I've derived the key for the position from the function, ciphertext and plaintext. Similarly, E (4) + ?? == Q (16) % 26.  ?? == 16 - 4 % 26. ?? = 12 (M). etc. Now I know the key and function, so if I want to change the first character to F, I just do F (5) + X (23) == C (2 mod 26). Etc. etc. An OTP is uncrackable in the sense that if all I have is the ciphertext, even if know the algorithm, but without the OTP or the plaintext, I cannot possibly generate one or the other. As any result is possible. This is of course useless for all further messages, since the OTP key is not reused, but if I intercept the message and know a portion of it, I most certainly can manipulate it. — Preceding unsigned comment added by 24.5.145.245 (talk) 00:24, 6 November 2011 (UTC)

A Google search for "one time pad malleability" (including the quotation marks) leads to class notes for a single class, nothing else. If I understand this phenomenon, a person who knew the exact format of messages, but not the key, could change a value in a message, but not know what it would be changed to. For example, if the symbol set for the key were only upper case letters, the space, and numerals, and the plain text were "PAY_ALICE_______5" and the name field was known to be 6 characters, then a space, then a six character payment field, an adversary could alter the message to read "PAY_ALICE__5T_8QP", and would have no idea what the recipient would see in the payment field after decryption. Jc3s5h (talk) 17:01, 3 November 2011 (UTC)

See my above comment, if you know what it said before, you can decipher that portion of the key, and then you're able to change it at will. Also, it's not one time pad specific - it can apply to many stream ciphers - http://en.wikipedia.org/wiki/Malleability_(cryptography) — Preceding unsigned comment added by 24.5.145.245 (talk) 00:26, 6 November 2011 (UTC)

Nope. That is not what is being asked. The assertion is "an attacker who knows that the message contains "Meet Jane and me tomorrow at 3:30 pm" at a particular point can replace that content by any other content of exactly the same length, such as "3:30 meeting is cancelled, stay home", without having access to the one-time pad". That is what is being asked. Just corrupting the message without being able to determine what the corrupted message will be is not the same thing at all. GS3 (talk) 19:31, 3 November 2011 (UTC)

I have added the "dubious" tag again to the phrase in question. Please do not remove it until this matter is convincingly settled. After some time if the phrase is not proven I will remove it. It just seems very obviously wrong to me. The XORing operation is extremely simple and is done on characters one by one. You have the plaincharacter, the key-mask character and the cyphercharacter. If you know two of the three you can obtain the third. If you know only one you have no way of obtaining the other two because each depends on the other. No way. This is true for one or for a million characters as they are encoded and decoded one by one. That is the basic principle underlying the one time pad. GS3 (talk) 13:03, 5 November 2011 (UTC)

You seem to be missing the fact that in order to manipulate a portion of the ciphertext to a known value, I would generally need to have the ciphertext value in the first place. Otherwise I wouldn't be able to replace one section of it in the first place (I wouldn't know the rest of the message). If I know the message contains "foo" at a given point, and I know the cyphertext says "bar", then I do in fact know two of the three, and can work out the third- like add key mod 26, I can most certainly compute b - f (mod 26) a - o (mod 26) and r - o (mod 26) to get that particular portion of the OTP. (4, 14, -3). Now I can apply the key to my new message ZIP, (25 + 4, 8 + 14, 14 + -3) to get CWJ. See above for a worked out example of this (from my same IP) 24.5.145.245 (talk) 00:00, 6 November 2011 (UTC)

First, I want to apologize for resurrecting this issue, but I also had the same reservations mentioned above when I read the article a few minutes ago. This interception method only works if the attacker knows the methodology of the OTP; if it is simply addition, then it can be beaten. However, it would be very easy to counter this potential attack by mixing in other or additional operands. In the case of a physical pad this would be easy to communicate; for a digital form (like a simple list of random numbers) it would not. For instance: if the second term was = +7+(first plain term) [which would need to to be physically communicated on the pad], then the attacker would be stymied. Perhaps this is viewed as something other than OTP (like a form of superencryption)? If so, then I apologize again; my knowledge of the subject is very limited. It just seams to me that such an vulnerability would be easy to counter. Nwilde (talk) 17:53, 28 November 2017 (UTC)

serious drawback ?

Why is the need of a "careful treatment to make sure that it continues to remain secret from any adversary" listed as a serious drawback of one-time pads? This problem seems common to every cryptosystem known, whether it is based on symmetric cryptography (the key must remain secret) or asymmetric cryptography (the secret key must remain... secret). — Preceding unsigned comment added by 82.121.127.28 (talk) 20:24, 2 November 2011 (UTC)

Some cryptographic protocols prevent an attacker from reading earlier messages even if the secret key is compromised. See perfect forward secrecy--agr (talk) 02:22, 6 November 2011 (UTC)

"Perfect Security"

Is it really still acceptable to describe one-time-pad as 'perfect security'? Any cryptographic encryption can eventually be broken by a computer, particularly if you are able to validate whether a guessed key was able to decrypt the data successfully or not.

One-time-padding, like all encryption, is ultimately bound by time constraints; a one-time-pad is only "perfectly" secure so long as it's only used once, and that the message, if intercepted, is useless beyond the time that it would take to brute-force the encryption, which in itself is a requirement that is subject to chance as computers get faster and faster. For example, no matter how well implemented a one-time-padding scheme is, if it's only being used to encrypt 8-bits of data then pretty much any device with a microchip can decrypt that. It's only really a viable method so long as the data is at least a certain length (which is where, confusingly, padding schemes should almost always be combined with one-time-padding). This length will increase over time as computing power available to an attacker increases as well.

For example, if you used a one time-pad to encrypt a newly issued credit-card number, then I wouldn't consider that secure, as it's relatively easy to match a credit card number to test for success, and the data isn't long enough to prevent it being decrypted within the 3+ years that that card would be valid for. Similarly, the fact that one-time pad exposes the length of the data is also significant, as that could (to continue the example) expose the fact that the data contains, say, five credit card numbers, allowing you to break the data down into five smaller, easier to break pieces. Haravikk (talk) 19:04, 14 August 2012 (UTC)

With a one time pad, there is no way to distinguish one guess from another guess of the same length. Consider the case of the case of a credit card number that has encrypted with a one-time pad. There is nothing associated with the cryptogram that would lead a cryptanalyst to favor one guess over another. So one would do just as well guessing credit card numbers, and using whatever scheme is available to test the guesses them, without bothering to intercept the cryptogram. Padding could be useful however. If one observed someone receive a 16 character cryptogram, one might surmise it is a credit card number, and it would be a good time to begin employing non-crypanalytic means to discover the number.

First, note that the title of the section is "perfect secrecy" and not "perfect security". Perfect secrecy has a formal definition, which basically means that an attacker can not distinguish the ciphertexts of two equally long messages. As you noticed and as it is also pointed out in the section "problems" perfect secrecy does not include every security notion. In particular, perfect secrecy does not imply authentication, which is frequently a requirement for a secure cryptosystem. Thus the main problem here is not an incorrect claim, rather it is that the term 'perfect secrecy' is sometimes misunderstood. 178.195.225.28 (talk) 21:10, 14 August 2012 (UTC)

Why no 6-dice?

In the section on making pads by hand: "Six-sided dice should not be used." Why is this? 99.4.123.58 (talk) 01:24, 30 August 2012 (UTC)

I tried to clarify how to use six sided dice to make a random digit one time pad. I think the editor who said they should not be used was suggesting 10-side dice were more efficient for this purpose, which they are.--agr (talk) 19:30, 3 September 2012 (UTC)

Making one time pads by hand

I copied the section on Making one time pads by hand, which was deleted, to the Wikibooks article: http://en.wikibooks.org/wiki/Cryptography/One_time_pads --agr (talk) 18:53, 14 January 2013 (UTC)

Unsourced statement

The article claims

In discussing the one-time pad, two notions of security have to be kept distinct. The first is the perfect secrecy of the one-time pad system as proved by Shannon (Shannon security). The second is the security offered by state-of-the-art ciphers (e.g. AES) designed with principles learned in the long history of code breaking and subjected to extensive testing in a standardization process, either in public or by a top notch security service (empirical security). The former is mathematically proven, subject to the practical availability of random numbers. The latter is unproven but relied upon by most governments to protect their most vital secrets (insofar as publicly known thus far)."

I would like to see a citation for the claim made in the last sentence. Why should governments use any method other than OTP for their most vital secrets? That governments use state-of-the-art-ciphers for this seems not plausible at all, given the fact that one runs a substantial risk of the cipher being broken, and storage capacities of even something as small as an USB stick that easily provide storage for random numbers in large enough quantity to allow for any practically conceivable application in environments where secrecy is vital, perhaps even where it is merely a desire. --rtc (talk) 21:43, 13 April 2013 (UTC)

I've added an NSA cite for the US government use of AES-256 at all levels or classification. Perhaps they are not telling the whole truth, but absent a reliable source to the contrary we take their word for it. --agr (talk) 04:11, 14 April 2013 (UTC)

The Wikipedia article makes a bad job expliaining this, but it's because one-time pads are useless in most scenarios: https://www.schneier.com/crypto-gram-0210.html#7 -- intgr [talk] 11:44, 14 April 2013 (UTC)

I think the phrase in our article, "most vital secrets", is unfortunate. My guess would be that the most vital secrets would have an effective classification beyond top secret; chances are even the name of the classification is itself top secret. Hence, a cite telling us that AES can be used for top secret really doesn't tell us what is used for "most vital secrets".

Schneier's argument against one-time pads is the usual one: the difficulty of distributing long keys. I would think there would be a select set of most vital secrets where the key distribution hassles might be worth it. Of course situations will also arise where a most vital secret must be sent to a destination which does not ordinarily deal with these secrets, and is thus not equipped with the crypto method(s) used for the most vital secrets, and so a less-trusted system will have to be used. Jc3s5h (talk) 14:11, 14 April 2013 (UTC)

Is Schneier's argument up to date? When did he make it? Some years ago, it was quite valid, but as technolgy progresses, things change. Also, if we are talking about asymmetric encryption combined with symmetric encryption to extend efficiency, I would agree. Then it does not make much sense to use OTP: The increase in efficiency inherently is lost again, with hardly any gain in secrecy (since the asymmetric part is the weakest and might still be broken). But for completely symmetric encryption needs where key exchange happens outside of some asymmetric framework, one needs a secure exchange of keys anyway, and with today's technology, it does really not make much of a difference whether the key is 256 bits or 256 Gigabytes. Standard flash technology makes it easy to store large OTP keys and (taking all necessary precautions into account) securely delete any part that has been used up, even on very small devices. A 8 kbit/s phone with a 256GB key inside, for example, would need to survive a cumulative call time of 8 years before depletion of the key--this probably exceeds the lifetime of such equipment by far! --rtc (talk) 15:39, 14 April 2013 (UTC)

Let's just take out the part about "most vital secrets", it cannot be verifiable and is not terribly relevant.

As for the usefulness of OTP, you're missing the point: it's not that "the OTP key is too large" or "key management is hard", it's that it defeats the purpose of encryption if the key is as large as the data you're storing (barring some exceptions, which Schneier highlights).

In order for any (symmetric) encryption to be secure, you have to store the key securely. OTP, requires the key to be at least as large as the data. And you cannot ever re-use the key.

So if you have a secure and large enough medium to store the key, why not store the whole data there in plain already? Again, we already established that the storage must be secure anyway.

Because the data may not exist yet. You can exchange the keys through physically secure (real-world) means, and then use them for future data exchanges. For instance share a 1 TB HDD with your correspondent during a meeting, then use it for future exchanges. 217.128.255.181 (talk) 13:15, 9 July 2013 (UTC)

Also, with OTP you can't derive the key from a human-learnable password like you can with symmetric encryption. The pad has to be truly random, not generated from a deterministic process. Otherwise you'd just be reinventing stream ciphers. -- intgr [talk] 22:24, 14 April 2013 (UTC)

"So if you have a secure and large enough medium to store the key, why not store the whole data there in plain already? Again, we already established that the storage must be secure anyway." If anything, you are disputing that symmetric encryption makes any sense outside of an asymmetric framework. All symmetric methods require a secure medium to store the key, so it can only be a question of whether the medium is large enough, and that this is not a problem with today's technology was exactly the point I was making. You seem to implicitly make the incorrect assumption that the human brain is under all circumstances the only secure storage and hence the key must fit into human memory. You will have a hard time finding any medium other than the human brain which is better in even one single respect than modern mass data storage, such that your argument could possibly make sense. I actually described an obvious, practical use of OTP in secure phones (such as for "most vital secrets"), so how can you claim that "it defeats the purpose of encryption"? --rtc (talk) 23:44, 14 April 2013 (UTC)

Sorry, I don't want to get bogged down in an argument about the usefulness of OTP, which is unrelated to the real issue. My bad for bringing it up.

As said before, I agree that this claim doesn't belong in the article. We don't know what "most governments" do with their "most vital secrets". Per verifiability policy we should stick to saying what we do know.

I made an edit to that end. While I couldn't find a reference for "[empirical security] is used by the vast majority of practical cryptography uses", I would guess nobody really disputes that? -- intgr [talk] 08:59, 17 April 2013 (UTC)

Much better now. --rtc (talk) 19:32, 17 April 2013 (UTC)

Khan Academy video

After reading the lead section of this article and the Example section (lots of 'blah blah blah'), I checked the tiny Simple English article about the subject (almost nothing there). I then decided to watch a less than three minute Khan Academy video about the subject (here) and I immediately understood the - very simple, as it turns out - concept of the one-time pad. I'm not sure what exactly this says about me, the Wikipedia articles or the Khan Academy video, but maybe it would be useful for certain visitors if we'd add the Khan Academy video to the External links section? --82.170.113.123 (talk) 18:18, 23 May 2013 (UTC)

OTP generation by a fres/traceable OS?

"One approach might be to use an older laptop for OTP generation, purged and rebuilt with a fresh, traceable copy of an open source operating system, such as Linux or BSD"

This doesn't look like a very good advice. Assuming you don't code the OTP generation software yourself, using a fresh version of an OS introduces a possible source for baked-in malicious code targeted at tagging or negatively affecting the OTP generation software. Since the system isn't going to be connected, security issues of older OS versions are irrelevant. So the installed OS version should preferably be one that predates the OTP generation software (and the OTP software should only rely on the OS for I/O, not generation, that goes without saying). 217.128.255.181 (talk) 13:11, 9 July 2013 (UTC)

authentication section is erroneous

it confuses mod 26 addition with the use of a random number to conclude that the message can be changed withOUT knowing the OTP values.

the whole point of a OTP is that you can NOT read the message at all without the pad and thus cannot change the message at all with vanishingly small probability.

the mod 26 stuff tossed into this section does not belong and is confusing as well as erroneous wrt the example. — Preceding unsigned comment added by 108.18.29.96 (talk) 18:44, 17 July 2013 (UTC)

If an attacker knows both the plaintext and the corresponding ciphertext for a section of the message then the attacker can extract the relevant section of keystream and use it to change the message. Perhaps this could be made clearer? Doctorhook (talk) 21:54, 21 July 2013 (UTC)

The whole section seems to be confusing the ideas of authentication and integrity checking. First of all, OTP actually does have authentication by design. Authentication doesn't work if multiple parties use the same pad, but if every participant has their own unique pad then the pads act as authentication in and of themselves. Having per-user pads is actually very simple and doesn't negatively effect physical key exchanges. This is not a new idea and even the Soviets were using multiple pads per communication channel.

As far as integrity goes it should be mentioned that nearly any cipher, including OTP, can incorporate a simple hashing function to verify against corruption or data tampering(ruling out a full-fledged MITM attack of course). This would "defeat" a known plaintext attack in the sense that the recipient would know that the message has been tampered with if the given and computed hashes don't match. The only way that Mallory could forge a new hash would be if she knew the entire plaintext, which is wildly unlikely unless there's been a serious problem in the way that the OTP was implemented. However, using a hash could also make an OTP cryptext potentially breakable through brute force.— Preceding unsigned comment added by Ravenstine (talk • contribs) 21:49, 28 September 2013 (UTC) Revised Ravenstine (talk) 21:54, 29 September 2013 (UTC)

True randomness requirements

This section is poorly referenced. Also because of its size and detailed content, it is more appropriate for Random number generation. I propose to delete it from the article and copy it here, to the talk page, in case someone wants to re-use it in another article. The Yeti 23:05, 31 December 2013 (UTC)

Please don't copy to talk page, that makes talk pages unnecessarily long with stuff that has no relevance to discussion. It's still available in the article history if someone goes looking for it. -- intgr [talk] 10:53, 9 January 2014 (UTC)

BATCO

BATCO is not an OTP system, six so-called keys correspond to the same encipherment table and there is always a limited chance for repeated uses of a key. I commented out the paragraph and I shall delete it if there are no objections. The Yeti 17:03, 1 January 2014 (UTC)

+1. In the future, just delete it per WP:BOLD. -- intgr [talk] 00:47, 2 January 2014 (UTC)

False Messages Vulnerability

I am going to try to provide context via Occam's Razor. The weakess of mod 26 allows false messages if the unencrypted source message and the encrypted message is known. Using global random mixing for each OTP that applies to all letters in each tied encryted message removes this issue. I am going to seriously press this simple fact. Obviously there will be little literature to help. — Preceding unsigned comment added by Anthony717 (talk • contribs)

The Wikipedia Verifiability policy is a pillar of Wikipedia and editors who don't believe in it should find someplace else to write. Jc3s5h (talk) 09:46, 3 August 2014 (UTC)

Adding the "NUMBERS" RNG-PRNG to the external links

Although using a pseudo-random number generator theoretically never achieves perfect secrecy, the program is useful in practice to generate one-time pads. The huge size and the limited use of a given random seed, the astronomical number of possible generator states, the whitening by combining 14 generators and the irregular partial use of the output make it infeasible to retrieve or predict the generated output. Numbers 8.3 is therefore a good software alternative to generate one-time pads. If you want to increase its security even more, you can load and mix multiple external files with randomness (mp3, wav, jpg, bmp...), or even true random (hardware RNG's) to generate truly random data or one-time pads with unbreakable encryption. My intention is not to promote or advertise this product, but i simply want to add it because there are no links in the article to a one time pad generator, i though i should add this one because it is pretty secure, and it has the option to create truly random numbers, ergo, unbreakable one-time pads.

Here is the link: http://users.telenet.be/d.rijmenants/en/numbersgen.htm

and the programs help file which explains how the program works and how to use it: https://drive.google.com/file/d/0B_2GCGSUZON9S20xWEVIY2hkZW8/view

Amon16 (talk) 21:42, 4 February 2015 (UTC)

@Amon16: You (and the author of this program) are misunderstanding what a "one-time pad" means. One-time pad is a cryptosystem that's impossible, even in theory, to break — if you're doing it right. But when you go from truly random numbers to a PRNG, then you're no longer using a "one-time pad", you're using a stream cipher to generate the keystream. And no matter how strong it is, it's computationally possible to reverse its output back to its original state (perhaps not in the lifetime of our Universe, but that's a separate issue).

You're totally right saying that stream ciphers are very strong. And in addition to that, nobody should trust a plain hardware RNG without CSPRNG post-processing in practice. Both of those are arguments to not use one-time pads in the first place.

The fact that the author of this program makes such claims is a strong indication that they don't understand modern cryptography very well, which is further reason not to trust it. It ticks several warning signs from Bruce Schneier's warning signs about snake oil cryptography, so I am opposed to linking to it from the article. -- intgr [talk] 22:09, 4 February 2015 (UTC)

@Intgr:"But when you go from truly random numbers to a PRNG, then you're no longer using a "one-time pad", you're using a stream cipher to generate the keystream. And no matter how strong it is, it's computationally possible to reverse its output back to its original state (perhaps not in the lifetime of our Universe, but that's a separate issue)." - i agree, but the program has the ability to use external randomness. Files with external randomness can be loaded into the generators to change their output stream, which the autor clearly notes in the description of his program, that you CAN NOT make true OTP's unless you load trully random data into the buffer from an external source. For example, if you load a .mp3 file with true random "white noise" into the buffer, the source which is used to generate the keystream is truly random and the result should be truly random, because even if you somehow mathematically figure out how everything was generated, you would still need that external source of randomness to brake the generator entirely. Thats why there are rules which need to be followed to make most out of it. If you dont follow those rules the pads generated can be compromised. The program by itself does NOT produce true OTP's, but it has the ability to do so if certain protocols are followed. Also, you say that the author has a misunderstanding of one-time pads or modern cryptography. The author of this program is Dirk Rijmenants, and you have his paper "Guide to Secure Communications with the One-time Pad Cipher" in a PDF here in the external links on this page :)

On the other hand, the generator could be added to the external links page, but it should be noted for safety reasons that it can create reasonably secure keystreams but it is unknown if it can create "true random" one-time pads. To use it on your own risk. It was created for crypto-enthusiasts, so if anyone wants to experiment with it, why not. Amon16 (talk) 23:02, 4 February 2015 (UTC)

I don't think the link should be added because the "External links guideline, point 11 of the Links normally to be avoided says "Blogs, personal web pages and most fansites, except those written by a recognized authority. (This exception for blogs, etc., controlled by recognized authorities is meant to be very limited; as a minimum standard, recognized authorities who are individuals always meet Wikipedia's notability criteria for people.)" The link does not seem to be written by a recognized authority.

Also the help section of the site makes bold pronouncements about the security of the software, but there is no reason to believe these pronouncements.

Finally, the page linked to and the associated help file confuse the distinction between a one-time pad and whatever the proper term is for the output of the program; whatever it produces, it certainly doesn't produce one-time pads. Jc3s5h (talk) 23:29, 4 February 2015 (UTC)

@Jc3s5h: - Is there a way to test if the claims the author of the program made are true?

whatever it produces, it certainly doesn't produce one-time pads. - can you please elaborate a bit more? Amon16 (talk) 00:41, 5 February 2015 (UTC)

Amon16 asked "Is there a way to test if the claims the author of the program made are true?" It doesn't matter. Encyclopedias are places for reliable information, not dumping grounds for speculation, leaving the reader to figure out what is good and what is junk.

A true one-time pad consists of truly random characters, arranged in a suitable format. Since the software described in the link messes around with any truly random data that might optionally be fed in to it, it doesn't produce one-time pads. Jc3s5h (talk) 00:48, 5 February 2015 (UTC)

@Jc3s5h: If one xor a bit stream A (external randomness), that is truly/ideally random, with a bit stream B (Program generators) that is independent from A, then the result C is theoretically also truly random. However I suppose the question is: How do you ever manage to get the really truly random A, nothing that all physical apparatus are involved is not 100.00% ideal/perfect. Amon16 (talk) 01:30, 6 February 2015 (UTC)

A defining aspect of a one-time pad is that there are as many bits of entropy in the key as there are in the message. This allows proof of security without any other assumptions. Another benefit is absolute deniability. In a stream cipher, like NUMBERS, if an adversary can obtain the RNG seed, say by compromising the computer that generates the pad, and finds the ciphertext in a message they can connect to you, they can not only decode the message, they prove its content. Assuming the message is in human language and is significantly longer than the seed, it is very unlikely that two valid human language messages will decode from a pad section generated by the same seed. By contrast, such a proof of content is not possible with a true one-time pad, if the pads are destroyed after use. A pad that decrypts the ciphertext to any message of the same length can be easily constructed by xoring the desired message with the ciphertext. For this reason alone (there are others), NUMBERS should not be linked to from this article.--agr (talk) 16:39, 5 February 2015 (UTC)

@Jc3s5h: A defining aspect of a one-time pad is that there are as many bits of entropy in the key as there are in the message. This allows proof of security without any other assumptions. Another benefit is absolute deniability. - i have tested the entropy of the generated keys and the cypher text with Randomness test programs, and the entropy of the cypher-texts was alway around that of the key so this program passes this assumption.

In a stream cipher, like NUMBERS, if an adversary can obtain the RNG seed, say by compromising the computer that generates the pad, and finds the ciphertext in a message they can connect to you, they can not only decode the message, they prove its content. - first of all, by that logic, all sources of random numbers can be compromised. Yes, there is a possibility that the computer that is used to generate numbers is compromised, but there is also a possibility that when you generate random numbers for example with dices someone is recording you with a video camera, or if you use any other source of randomness that someone is eavesdropping and that there is a possibility that the source itself is compromised. This is not a valid argument. You can bypass this problem considerably by having an absolutely secure computer with no external connections, and every time when generating keys, feed it with random external data that is permanently destroyed after use. If you want to take it one step further, you can format all data on the computer before using the program, and after its use, completely wipe the disk again with crypto-secure erasing algorithms. Perfect security can never be archived, but you can get really close to that. Also, if one xor a bit stream A (external randomness), that is truly/ideally random, with a bit stream B (Program generators) that is independent from A, then the result C is theoretically also truly random, if this is true, then the output is no longer a stream cypher but true random data.

Assuming the message is in human language and is significantly longer than the seed, it is very unlikely that two valid human language messages will decode from a pad section generated by the same seed. By contrast, such a proof of content is not possible with a true one-time pad, if the pads are destroyed after use. - the message cant be longer than the seed, because after every 10 000 generated characters the program needs to be reseeded. And the seed depth of the program is 4.1 x 10^1348 (4480 bits) + if you add external randomness its even bigger.

A pad that decrypts the ciphertext to any message of the same length can be easily constructed by xoring the desired message with the ciphertext. For this reason alone (there are others), NUMBERS should not be linked to from this article. - but this is the strenght of the OTP's. Every cyphertext generated by OTP's can be decrypted into some other meaningful sentence in any language of the same length. I dont see why this would be a weakness. Amon16 (talk) 01:30, 6 February 2015 (UTC)

For the OTP, deniability is neither a strength nor a weakness. There may be situations where you desire the ability to prove that a cipher text corresponds to a plaintext, others where you may prefer there be no way to prove it. In the case of NUMBERS, the 4480 bit seed is much smaller than 10,000 characters, so it would be possible to prove a particular cipher text corresponds to its plain text by producing the seed, since, assuming the RNGs issues are cryptographically strong, it would not be feasible to construct a seed that generates a pad that decodes the true cipher text into a forged message. With an OTP it is trivial to do make a pad that decodes a given cipher text to any message of the same length. Ergo, NUMBERS is not an OTP.--agr (talk) 17:31, 6 February 2015 (UTC)

the seed itself is smaller than 10,000 characters, but the seed can be mixed with external randomness, here is a picture of the internal layout of the program:

http://s22.postimg.org/b0ojnyssx/Internal_layout.jpg

You can mix up to 1,000,000 bytes of external randomness with the program generated seed to generate characters, if 1 character equals 1 byte than the seed is 100 times larger before reseeding is initiated. Also, that random seed is also used in two independent generators numbered 13 & 14 to make random interrupts in the output. An attacker can never get the internal states of the generators without a complete output. But for that to be true, the file that was used to load 1,000,000 bytes of external randomness needs to be destroyed permanently after use, that way there would be no mathematical way to reproduce the seed.

This is from the programs internal description:

"Also, the combined generator output is not used entirely. After every 17 to 23 outputted characters, between 3 and 13 characters are skipped. These random skip values are calculated by the independent 13th and 14thgenerator. Both values are derived from the same two generators but there are 9 generator cycles between them. The number of skips is calculated by ((genout13 XOR genout14) Mod 11) + 3 and the start of the next skip is calculated by ((genout13 XOR genout14) Mod 13) + 17. Any attacker not only faces the task of retrieving all individual generator streams, but the series of output bytes, required for analyzing the generators, is incomplete. He does not know where and for how many bytes the stream is interrupted. To know this, he must know which bytes are missing, which would only be possible when he could predict the output stream.

External randomness can be inserted into the generation cycle (more about external randomness is found in chapter 1). Numbers does not mix the external randomness directly with the combined generator output. Instead, the randomness is inserted into to ARC-4 byte generation cycle. By XOR-ing the external random byte with the swap position j, we not only add randomness to swap position j and to the output s(s(i) + s(j)), but we also change the content of array s. Therefore, inserting a single random byte into the cycle will change all following output completely, in contrast to mixing external randomness directly ith the output. Each inserted byte, even when equal to the previous, will affect the output in another way, as it is only one variable within the calculation of j.

If the external byte is true random, then j and the calculation of the output will also be truly random. In that case, the output will be suitable to generate real one-time pads. However, even non-secure randomness will still result in a complex and drastic change of the current and all following output bytes. Any insertion of external bytes, strong or very weak, will improve the security of the generated output considerably."

assuming the RNGs issues are cryptographically strong, it would not be feasible to construct a seed that generates a pad that decodes the true cipher text into a forged message. - such pads need to be generated manually, pads that turn cyphertext into a forged message are astronomically unlikely to be generated by any true random source, they need to be designed.

Amon16 (talk) 19:44, 6 February 2015 (UTC)

Depending on how external randomness is mixed in and the quality of that external randomness, this scheme may or may not approach one bit of entropy per bit of pad. This talk page is not the place to carry out the kind of professional review needed to determine if it does or not or if it has other problems.--agr (talk) 21:26, 6 February 2015 (UTC)

You are right, for the program to have any credibility it must be professionally reviewed and confirmed from an authorized source. Amon16 (talk) 22:41, 6 February 2015 (UTC)

@Intgr: Before taking for a fact that the author of NUMBERS (me) doesn't understand cryptography, you might do a background check. If you take the effort to read what NUMBERS is, and isn't, you'll see that I write that "you can generate and print series of crypto secure random numbers or letters, formatted as one-time pads". Crypto Secure doesn not mean absolute security, and formatted as doesn't mean "is one- time pad". Further, "using a CSPRNG theoretically never achieves Shannon's perfect secrecy' and that 'you can add external true randomness to generate real one-time pads.".

If you take the effort to read the manual, you will read exactly what NUMBERS is and isn't, and will read when and how you can generate real one-time pads and when not. Check out how the generation works and how true randomness can be introduced in such a ways that real randomness is produced, and not simply generated by the CSPRNG, and under which strict conditions you can generate OTPs. Please read chapters 3, 4 and 5. It also explains how not to use computers to generate OTP. The information is clearly stated. Software that explains correctly how OTP works, and warns for incorrect use, can hardly be called snake-oil (snake-oil is software that promises false things). I clearly don't pretend to have invented any unbreakable OTP scheme to male money. If you read the paper "complete guide to using OTP" (see public Papers section on website [1]) you'll find that I clearly explain the the how and why of OTP. But all this is irrelevant to the discussion, this is not a place to advertise anything.

I happen to come from the field, have quite a bit of experience with OTP (not the programmer or security wannabe kind) and am currently active as crypto historian. I'm very well on par with OTP, its technical/practical issues and its history. (see my http://users.telenet.be/d.rijmenants/en/onetimepad.htm . Take the trouble to read through that page and tell me if you still think I don't understand OTP. If anyone has done more research on OTP, both technically and historically, and also has any experience (intgr?) in the field of OTP, then feel free to contact me, I'm always really happy to collect more genuine sources and references for research purposes.

If you want to support wikipedia, please rely on actual sources and facts, as I do, and not on random (what's in an name) talk that people submit. Btw, I never asked for NUMBERS to be linked here, nor anywhere else, nor do I have any financial benefits whatsoever (so what's up with the snake-oil?!) I don't even support NUMBERS getting linked here blindly. I won't loose any sleep on how people judge the software. I just regret people stating things beforehand without checking the facts, something that makes or breaks the credibility of Wikipedia. Dirk (talk) 21:13, 9 March 2015 (UTC)

@Drdefcom: First, I apologise for claiming that you don't know understand one-time pads.

I don't know why you single me out, I only made one post and there seems to be a consensus in this discussion that this program does not produce one-time pads and that it's best not to link to it from this article.

"you'll see that I write that "you can generate and print series of crypto secure random numbers or letters, formatted as one-time pads". Crypto Secure doesn not mean absolute security, and formatted as doesn't mean "is one- time pad"."

That's some subtle word play, but from a quick reading of the web page, I imagine most people will come to the understanding that this is a program claiming to produce one-time pads.

In the same vein, I did not say that the program is "snake oil" (though I can see how one can interpret my post that way). I only stated that I see lots of parallels with Schneier's snake-oil guide. For example reading, stuff like...

"The output of 14 independent generators, each one initialized by its own random 320 bit key, is combined to generate the random output. The 4,480 bit sized seed to initialize the generators is derived from mouse movements and process time measurements of these movements. It requires 6 passes or 26,880 bits to complete the pool of seed bits. Seed depth is 4.11*10¹³⁴⁸. Every 17 to 23 output characters, between 3 and 13 characters are skipped. [...]"

... should make anyone familiar with modern cryptography wince. Sorry, it's easy to dismiss the web page, I did not feel the need to delve into the manuals.

It is not required to "rely on actual sources" to oppose adding content or an external link, if the content itself isn't supported by citations. That would be shifting the burden: "The burden to demonstrate verifiability lies with the editor who adds or restores material". Linking to a web page that claims to be hosting secure software isn't sufficient to claim that the software is secure. Are there any independent reliable sources saying that this program can produce true one-time pads?

There are also many other reasons to not be adding this link, such as WP:NOTLINK; plain and simple external links are largely irrelevant to Wikipedia's mission and editors tend not to spend lots of time investigating them, as there are more productive ways to improve Wikipedia. I would have preferred not to be dragged into this debate again, but what can I do. -- intgr [talk] 01:20, 10 March 2015 (UTC)

intgr, you're far too kind, stiking trough that part of your comment ;-) Buu let us take the discussions where it should be: verifiable sources. Wikipedia should indeed verify its sources, but they do a pretty bad job at it. I know the guidelines for Wikipedia and have contributed several years (mostly Dutch but also English Wiki, mainly crypto equipment), until I gave up long ago fighting against people who just copy any random text into articles or claim to know what good or bad sources are. Commercial firms and subsidized links are by definition bad sources. For cryptography, this includes most of the commercial so-called crypto gurus who earn money by writing and selling books, and certainly journalists and scholars of the current copy-past generation. Yes, they are proficient in copying, also my work (btw, for some plain copied texts, I never gave Wikipedia or the editors permission). Now, this might not be a problem for every-day kitchen and garage info at Wikipedia, it is however a real problem when written by authors who only know the subject from reading the Internet and using the right-button of their mouse to add text.

Did anyone take the effort of checking the references in the OTP wiki article? Some of these “trusted” sources are either plain copy-past or random articles from magazines and commercial websites. Good job! Is wikipedia serious about descent sources for this article? If so, they should start redacting, heavily. Its references and research are pretty poor. I stopped long ago correcting nonsense that people put in the Wiki.

As for some of my work, the website and all content is created for educational purposes, no commercial goals. I collaborate with numerous experts, organizations and archives to produce authentic information. We all take our job serious, and we either check our sources or get the facts and documents ourselves (at that moment, we become the source, a point some are missing here). Any idea how long it takes to get an article published, for instance, in Cryptologia? I have, and Wiki could learn from how they check their sources. I repeat, I’m not the one who asked for, nor am I in favor of NUMBERS getting linked here, and without any contextual info, as is available on my website. Feel free to remove it, really. I vote for removal (since wiki is more of a democracy than science) But, be honest, instead of just talk talk talk, clean up the references when you’re at it.

Oh well, it’s been a few years ago I worked on Wikipedia, and now I remember why. Nevertheless, good luck with evaluating any new sources or references.Dirk (talk) 17:32, 10 March 2015 (UTC)

Just a quick question regarding sources/references. It's quiet logical that software isn't linked at Wikipedia, since you don't know how it performs or whether it contains malicious code. That it isn't peer reviewed is another question. However, following Wikipedia's rules on sources, I'm curious what Wikipedia's policy is regarding original never before published research? An example; some recent research regarding use of OTP by commercial firms. Never been referenced, as it is new. Only source is the author. According the Wiki rules, it should not be linked, it’s personal research, site, etc etc. Common sense and those familiar to the subject would take this for accurate information. Wiki probably not. On the other hand, the weirdest things and high-school papers are taken for truth, also at the OTP wiki page. I suppose that's Wikipedia's dilemma. Arbitrary evaluation of sources? Houston, we have a have a credibility problem ;-) PS; Do NOT LINK the BAPCO article, respect copyrighted work ;-)Dirk (talk) 18:36, 10 March 2015 (UTC)

I'm aware that people have differing opinions about how well the Wikipedia community is doing and that's fine. This is not the time and place to be debating that. If you want serious responses to your questions, you should tone down on the trolling.

First, you are conflating two different concepts: "linking" as you say, and using something as a source, are covered by entirely different guidelines.

As far as Wikipedia is concerned, that is not "original research" but a primary source. The reliable sources guide discourages self-published sources like blogs except "when its author is an established expert whose work in the relevant field has been published by reliable third-party publications". -- intgr [talk] 08:35, 12 March 2015 (UTC)

Right, I wouldn't have any problem using the http://rijmenants.blogspot.be/2015/02/bapco-s-use-of-one-time-pad-during-wwii.htm link as a ref for a statement like "OTP was occasionally used by commercial firms during WW II" since it is relatively uncontroversial historical statement that is backed up by ample and clear primary sources from an established online archive that is easily checked. Or it might be an external link "Example of OTP use by a commercial firm during WW II." --agr (talk) 11:02, 13 March 2015 (UTC)

Update on the history of the invention

It seems like the section on the history of the invention relies heavily on Kahn. There was a recent paper published by a historian who, at Kahn's urging, reconsidered the claim of credit for the invention of the OTP. The historian's paper is at https://mice.cs.columbia.edu/getTechreport.php?techreportID=1576

Perhaps there should be some amendment to the section?

Hawkinsw (talk) 04:39, 20 April 2015 (UTC)hawkinsw

I see the author has placed a list of his publications online. I don't know if there is any peer review required to place papers on the mice.cs.columbia.edu website, but Professor Bellovin seems to qualify for the expert exception to Wikipedia's guideline concerning self-published sources. Jc3s5h (talk) 14:53, 20 April 2015 (UTC)

Re. "Authentication" - Invitation for extended debate - Please help with sources (Wanting Change)

My argument (awaiting sources, mine or others): I believe that Wikipedia should use accessible language to discuss debatable issues. The "Authentication" issue is, to me, quite debatable. I can't imagine being a spy. But I can imagine being a average person. If I were an average person put in a situation, like in the movies, where I needed a one time pad (OTP) to escape the bad guys, I would know two things: (1) Each character in the key must be randomly selected using a physical method, such as drawing letters from a bag; and (2) The key must include a scrambler derived from the random selection of all needed characters. My assertion is that any average person clever enough to use an OTP would automatically know this. Further, I ask, why would a person of average intelligence and good sense risk using fancy math to scramble an OTP (to prevent false or misleading messages) when they could just draw messages from a Scrabble bag? I know that Wikipedia is not meant to be original research, but the Authentication section is so obtuse and misleading for average people that it needs intervention. However, I need support before doing any edits. Anthony717 (talk) 06:25, 12 November 2015 (UTC)

I don't think the section on authentication is misleading. In fact, it addresses an important topic: the one-time pad is sometimes called perfectly secure, a clear misconception given that it lacks authentication. Commonly used encryption modes (e.g. AES with HMAC) are preferable since they prevent a larger range of attack scenarios. But you are certainly right: Wikipedia is not the right place to discuss original research. 2A02:120B:C3C8:F260:605E:CAD4:F2B8:FC2A (talk) 08:11, 12 November 2015 (UTC)

Thank you for agreeing about original research (but that does not include the talk page). I'm looking for sources. Part of the attraction of one time pads is that they don't require math. If the recipient can substitute characters once for encryption, he can do it twice to prevent false messages, and the second key only needs to be as large as the character set. If the recipient has multiple keys, the keys will also need page numbers to match to the messages. It may take a while to find a source, because mathematicians find these ideas too obvious to write down. Anthony717 (talk) 11:46, 12 November 2015 (UTC)

Creation of scenario in hope of getting sources: I'm working on this point long term, so I ask for patience (on the talk page). The reason for this section is to argue that the authentication section needs a colloquial paragraph, and the reason I'm sharing is to encourage input. Therefore I would like to create a simple scenario using pseudo-random numbers (only 10 characters makes it simpler). Alice (good) wants Bob (good) to get to the auction at dawn, but Charlie (bad) wants Bob to sleep late until the auction is over. The translation "5341876140" means "Get there by dawn." The translation (each previous plus one) "6452987251" means "You can sleep in because the auction doesn't start until noon." Bob's key (that Alice handed to him weeks before) is "-3,-6,-4,-1,-5,-3,-7,-0,-6,-8," which means he has to subtract these amounts from the numbers on the letter that Alice sends him. Therefore the message is "8982303108." Of course Charlie, being an postman, steams open the envelope and forges the message "9093414219." It is important to note here that the arbitrarily simple example is essential: If "pen and paper" OTP encryption is not perfectly uncrackable and perfectly authenticable (with perfect dice), then there are important questions to be asked about the concept. I want to repeat the scenario with Alice knowing that Charlie works at the Post Office. I am tired now, but I know I will need to add a key to each character to Bob's sheet, and that will change some of the above numbers. Anthony717 (talk) 05:24, 15 November 2015 (UTC)

Edit claims unknown authors are wrong

This edit by 103.1.57.224 makes this change:

There is some ambiguity to the term because some authors incorrectly use the terms "Vernam cipher" and "one-time pad" synonymously, while others refer to any additive stream cipher as a "Vernam cipher", including those based on a cryptographically secure pseudorandom number generator (CSPRNG).

The paragraph claims that some authors use the terms "Vernam cipher" and "one-time pad" synonymously. Unfortunately, these authors are not named. No single authority is in charge of cryptography, nor is one single authority in charge of the English language. Before we can decide if these authors are incorrect or not, we would have to know who they are, their stature in the cryptography community, and how widely accepted their definitions have, or have not, become.

Unless we find out who the author are, we should either leave the passage alone, or completely remove it. Who are we to say that some unknown authors are wrong? Jc3s5h (talk) 14:09, 13 September 2016 (UTC)

References

Latest talk

The authentication section is getting better, but it still needs practical thinking. The whole article needs practical thinking. The whole article is annoying. How do you use totally random one time data to send false or misleading messages? Since a one time pad is possibly perfect, the detractors need to use some layperson language to serve other than themselves. — Preceding unsigned comment added by Anthony717 (talk • contribs)

All we need is random!

We just need a squence of random numbers. We can for example use MD5 or some other hash function to calculate it. The random sequence must not be transfered, if the same sequence is calculated while encrypting and decrypting.

--84.118.82.226 (talk) 18:14, 6 February 2018 (UTC)

No. If you're using MD5 or some other deterministic function to generate the random numbers for the pad, then you've basically built a new cipher -- which is not a one-time pad. The CTR mode of block ciphers is like a one-time pad, where the pad is generated with a block cipher. -- intgr [talk] 18:33, 6 February 2018 (UTC)

I skimmed CTR mode and it does not appear to be random, it appears to be deterministic. The sequence of numbers or characters used for a one-time pad must be completely random. Jc3s5h (talk) 19:57, 6 February 2018 (UTC)

@Jc3s5h: Yes, that was my point, I brought up CTR mode as an example of something that's like OTP but actually isn't, as the pad is generated by an algorithm -- similarly to MD5 proposed by IP editor here. -- intgr [talk] 10:11, 7 February 2018 (UTC)

Removed factoid about invasion of Grenada

Hi. I wanted to log that I removed a fact mentioning that books containing one-time pads from Cuba were found in a warehouse during the 1983 U.S. invasion of Grenada. I spent quite a while searching for a source for this and could find nothing besides sources that re-publish this article. If anybody finds such a source or objects to this removal, please add it back! — Preceding unsigned comment added by A40585 (talk • contribs) 20:50, 5 June 2022 (UTC)

Ah, one more thing, there is a copy of this document on one of those sketchy course note/exam reupload sites that wants my email. The link is here https://www.yumpu.com/en/document/view/30002213/4-secret-bits-harvard-school-of-engineering-and-applied-sciences-/21 if you want to throw your personal information into the abyss but maybe help find a good citation for 2 facts in this article (that the OTP and quantum crypto are intimately connected and the 1983 invasion of grenada. A40585 (talk) 02:36, 7 June 2022 (UTC)

DVD movies as OTP

Hi, I "invented" this method at University. Interesting note here, the more obscure the DVD the better, ie a film that is long out of copyright. Also worth noting that the only data you need to send is the ISBN which doesn't change, and the offset within the encrypted stream. The decode and encode operations only need the most basic of computers, ie a Pentium class CPU and optical drive. Supposedly this is being used by (folks) in (location) to send data to UK authorities in real time in a way that can't be intercepted, but at the moment I can't confirm or deny this. 78.111.195.1 (talk) 07:50, 9 March 2023 (UTC)

DVDs are not random. If it isn't random, it isn't a one time pad. Jc3s5h (talk) 14:02, 9 March 2023 (UTC)

NSA Orion and Medea description

I think that it is inaccurate to describe the second line (or the other side) alphabets as random (as in randomly mixed). They are still sequential (but reversed) - the randomness comes from random shift (or rotation) of each second line.

Also it may be worth mentioning that unlike Diana they include digits so the alphabet is 36 characters long which simplifies and shortens encoding numbers. 46.113.0.10 (talk) 22:52, 29 September 2024 (UTC)