Talk:One-time pad

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Padding as a form of authentication? 

message: 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)
thread_title:  link back and forthing 

message: 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)
thread_title:  Use cases, advantage, etc. 

message: 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)
replies: text: 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)
thread_title:  Error in example? 

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)
replies: text: 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)

text: 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)

text: 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)

text: 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)
replies: text: 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)

text: 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)
thread_title: Phony Message

message: 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)
replies: text: 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)
thread_title:  serious drawback ? 

message: 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)
replies: text: 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)
thread_title:  Why no 6-dice? 

message: 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)
thread_title: Making one time pads by hand

message: 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)
thread_title:  Khan Academy video 

message: "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)
thread_title:  OTP generation by a fres/traceable OS? 

message: 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)
thread_title:  authentication section is erroneous 

message: 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)
replies: text: 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)
thread_title:  True randomness requirements 

message: 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)
replies: text: +1. In the future, just delete it per WP:BOLD. -- intgr [talk] 00:47, 2 January 2014 (UTC)
thread_title:  BATCO 

message: 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)
thread_title:  False Messages Vulnerability 

message: 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)
replies: text: 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)
thread_title:  Update on the history of the invention 

message: 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)
replies: text:  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)

text: 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)
thread_title:  Re. "Authentication" - Invitation for extended debate - Please help with sources  (Wanting Change) 

message: 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)
thread_title: Edit claims unknown authors are wrong

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  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)
thread_title:  All we need is random! 

message: 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)
thread_title:  Removed factoid about invasion of Grenada 

message: 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)
replies: text: DVDs are not random. If it isn't random, it isn't a one time pad. Jc3s5h (talk) 14:02, 9 March 2023 (UTC)
thread_title:  DVD movies as OTP