unbreakable encryption by means of simple subtraction

[lordshinmei]

A normal onetime pad uses modular arithmetic to perform rotations on plaintext. An "e" might rotate to a "b" if the key number is greater than 21. This operation is memory-intensive and difficult to perform by hand. So why not encrypt in a way that uses the basic principle of the onetime pad but in a simpler and faster way? Say you have some text that you want to encrypt. You take a chart (or you could program this whole process into a computer) with the ninety-five printable ASCII characters and an additional five characters, numbered from 00 to 99. You convert the text to a stream of numbers using this chart.
Then you create a key the length of the message using a secure random number generator, or just make one up and write it down. It is easier to use the generator because then you only have to remember the seed rather than the entire key. Anyway, you take the key and subtract it from the text. If you get a negative number it is fine. The answer is the ciphertext.
Since there is an infinite number of pairs of numbers whose difference is the ciphertext, it is impossible to decipher it without the key. A bruteforce search of all keys will yield literally every possible string of text. This means that there will be an infinite number of answers that make perfect sense even though they are wrong.
Anyone could easily do this by hand, and it would be EXTREMELY fast on a computer. Here is an example.

"ABCabcDEF" is converted to 34 35 36 66 67 68 37 38 39.

Using some algorithm or just making it up, you get a key: 12 35 53 19 71 22 66 66 42.

Subtract. 343536666768373839
-123553197122666642
--------------------------------
219983469645707197

If you just have the number 219983469645707197 then there is no way to find the message or the key. Also, the key can be longer or shorter than the message, it does not have to be the same length.
Nobody steal my idea; I'm getting it patented and U will be screwed over.

[Rewandythal]

Well, they wouldn't necessarily make perfect sense, for example if you had two solutions:

the nuclear missiles are being moved at 0300GMT from location A to location B along the M1 motorway

and

the cabbage patch is being watered at 2300GMT by an automated watering system along the length of the garden

And you knew that the source of the message was not Gardeners Weekly, you could make a fair guess as to which message was accurate!!

[lordshinmei]

Rewandythal said earlier that if you take the wrong key and get the wrong answer that seems to make sense but not in context with the message's subject, then you will know that it is wrong. However, there will always be a number that gives you

"the nuclear missiles are being moved at 1200 EST from location C to location D along the M2 motorway"
rather than the correct answer,
"the nuclear missiles are being moved at 0300 GMT from location A to location B along the M1 motorway".

This is true of any message. How would you know which one of these answers is correct? If you had that much information aailable you wouldn't even need to intercept messages. And it is a proven fact that these answers will both come up if every feasible key is tried. The only way to decrypt is to use the key; there is no way around it.

[Rewandythal]

Very true, I was illustrating the point that you can filter out most of the possible outcomes by context.

[lordshinmei]

Okay, here's something interesting...
It only works with subtraction!
Say you add them together. There is NOT an infinite number of positive numbers whose sum is a given number. If you allow negative, then this might work, but you could just consider that to be subtraction anyway.
If you multiply them, then all you have to do to crack it is factor the ciphertext and try all of the different combinations of factors.
If you divide, then theoretically there is an infinite number of possibilities, but you would lose precision by writing it as a decimal and writing it as a fraction would be useless.
The only one that works correctly is subtraction. This makes it unbreakable even though it's extremely simple.

[Cheeseball]

Subtract.    343536666768373839
                   -123553197122666642
                  --------------------------------
                    219983469645707197

well...doing it like this means we know the plaintext can be found by adding unknown values to the ciphertext. Also just to note, your key needs to be at least as long as your ciphertext or you will risk the left digits being leaked from the plaintext conversion to the ciphertext, such that:

Subtract.    343536666768373839
                   -                                       2
                  --------------------------------
                    343536666768373837

also if the numbers go negitive we can tell the key was longer than the plaintext, and get a better idea of which keyframe we would be working in. Also we can get a decent idea of the size of the plaintext by the size of the ciphertext due to the restriction of needing a key as long as the ciphertext will result in a plaintext within a few number places of the original message. Also at the point you want to make this secure you would be running something that is "relatively" a onetime pad....because if you ever reused the key there would be ways of crunching the possible keys out of the ciphertext because sure there is a possbility that two possible keys are in the same keyspace, but if you reuse the key again, on a different message, only one of those keys will still work, and that will be the correct one.....ok....enough of my rant....As far as I am aware everything I said here is correct.

[lordshinmei]

What you said is true. But about the part where you said that the ciphertext gives us a good idea of the size of the plaintext and key... this is not always true.

119124302439284
- 119124301751147
--------------------------
688137

This is not even close to the plaintext or the key. I realize that you would probably not use a key that close to the plaintext, but in a large message a section like that will probably come up; and if many people used this algorithm then you would have no way of knowing whether or not this happened.
Also, I have to disagree with the part about being able to find the plaintext by adding unknown values to the ciphertext. The reason that his will never work is that you will come up with multiple answers that make sense, any one of which could be right. Say you have some ciphertext and you try adding "121232124" and you get a set of coordinates. Then you try adding "1313462679" and get a totally different set of coordinates. You can narrow the possibilities down, but you can never fully crack a message encrypted in this way. The answer could be one of a large number of feasible possibilities.
The larger a message this is used on, the longer it takes to encrypt/decrypt, but the security is equal for any message length.
And you said that if you get a negative answer then you know that the key was bigger than the plaintext. Great. What good does that do you? There is still an infinite number of possible messages. The message could be "2" and the key could be "3", or the message could be 10^2343 and the key could be 10^2343+1 . You can always find an arbitrarily large pair of numbers with a given difference.

[darkes]

Intrigued as to how your patent application is going. As far as I know, this is not a new idea, so it will be interesting to see if anyone else has patented it. Relying on just a seed for your random number generation is not a good idea, as to break it all you need to do is to reproduce the seed itself (might be easier than you think). The whole idea of a onetime pad is that the key is truly random (or as close as you can get to that) - so for example if you close your eyes, and type random letters on the keyboard, that is pretty random. After having saved the key to external media, you make sure that the original copy on your PC is permenantly erased.

[souleman]

The biggest problem, as with ANY encryption, is key distrobution. How do you get the key to the message recipient without giving away ahything you don't want to.

Also, like darkes said, I am pretty sure I have seen something pretty close to this before. Converting text to all numbers has been used for centuries. People have tried many many things with these numbers. This is still a simple substution cypher which works from right to left instead of left to right.... IE....
xyz<------------plain
-abc<------------key
____
vvv <--------------cypher simple subtraction....

so:
def
-abg
___
aaz because you are borrowing from the e on the f...

[draziw]

Ummm... sorry - I've not read this entire thread... but the very first thing that puts a stake in to this... key exchange.

There's probably a few more assumptions that might have some good holes in them, but, in short, if you can't securely exchange the keys between sender and recipient, it doesn't really matter a whole lot... it's not going to work anyway.