in reply to Re^4: crypto with core modules only
in thread crypto with core modules only

The bit-composition is an issue for XOR which was not my proposition! The modulo solution I suggested based on a 100-year old algorithm makes the issue blissfully irrelevant - it doesn't matter in the least how many bits got flipped if the character is drawn randomly from the printables. Total red herring for me I am afraid, so please drop it.

Update: although I will say that if an enemy suspects your algorithm and has access to the encrypted messages, and the user makes frequent small changes and reapplies it, the enemy can use the fact that half the bits don't change to break the encrypted message by analysis - not even brute force being required. This is not a weakness of the official OTP algorithm.

Replies are listed 'Best First'.
Re^6: crypto with core modules only
by pryrt (Monsignor) on Aug 31, 2018 at 13:45 UTC

It appears you didn't notice, but in the Wiki:One-time Pad article you linked, the second sentence of the second paragraph specifically says, " On July 22, 1919, U.S. Patent 1,310,719 was issued to Gilbert S. Vernam for the XOR operation used for the encryption of a one-time pad.".

First off, this is precisely what tobyink said in Re^2: crypto with core modules only: that one-time pads can be easily implemented with XOR. And you've been arguing against him on this, despite the fact that the article you mentioned points this out, quite early on.

Second, you just mentioned your "modulo solution I suggested based on a 100-year old algorithm", trying to imply that it was somehow better by being older. But I'm pretty sure your implementation isn't a hundred years old. You might argue, "but mine is based on the algorithm". I would argue that so is the XOR solution.. And the XOR solution mentioned in the Wiki article, patented in 1919, has the advantage of (currently) being a 99-year-old implementation of the algorithm, whereas your description was made quite recently.

"if the character is drawn randomly from the printables". Apparently, you don't understand that the key for the XOR (the my \$encrypted = \$message ^ \$key; from tobyink's post) is a string of characters randomly chosen octets (though from the full range of 8-bit characters, rather than the limited quantity of "printable characters" that you suggest).

(regarding the update: if the user makes frequent small changes and re-applies it, then it's no longer a one-time pad; it's a multi-time pad with slight modifications, which does not have the strength of security that a true one-time pad has. But arguing that one-time pad can be misused by being reused has nothoing to do with the arguments of "add and modulo" vs "xor", so I'm not sure why you brought it up.)

To sum up, regarding the XOR implementation: It is still a one-time pad, so the underlying algorithm is as old as yours. It has the same random nature of the key as yours does -- but is slightly better, because it has 256 possible characters (in an 8bit-character string representation), rather than the 96 you've limited yourself to. The XOR is faster: it's one math operation per character, rather than the offset, add, modulo, re-offset that you described.

So many sentences arguing semantics. Yes the history is complex. Yes I might have missed that XOR has a place in that history. But Actually if the modulo version is more recent then there must be a good reason why that came to pass. I suggest it is that the electronic computer was invented in 1943 precisely for crypto-analysis. see “Colossus” invented by Turing and built in Dollis Hill post office, December 1943, to decode ‘Geheimschreiber’

Update: Anyway, tobyink tricked me into thinking the xor was his own idea rather than an older version - it's the way he wrote that reply to my post, without giving credit to anyone else. At least I already gave credit where it was due and claimed no invention of my own, even by omission.