unbreakable encryption by means of simple subtraction

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.

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

Quote:

---

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

---

and

Quote:

---

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!!

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.

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

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.

Code:

---

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:

Code:

---

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.

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.

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.

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...

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.

draziw> you obviously didn't read the entire thread cause key exchange was the first thing I mentioned in the post right before yours ;)

well guys, in all fareness key exchange is generally a problem with most encryption anyway...

well guys, in all fareness key exchange is generally a problem with most encryption anyway...

OK, first I'll reply to the thing about the random number generator. Darkes said earlier that relying on a random number generator is not a good idea because you can check every seed rather than every key and this can easily be done in a matter of minutes. While this is usually true, I have a solution that makes a bruteforce check of all keys virtually impossible. Instead of using a 32-bit or 64-bit seed like most random number generators, you could use either a single large key or about eight 32-bit keys. You could easily get 256 bits worth of data off of any given word or phrase using SHA-256 or MD5 or some other hash algorithm. There is no way to check all possible keys once they get big enough. If you applied this to obtain a 2048-bit key or something then noone would ever be able to check them all.
Next, key distribution... first of all, as 8*B@LL said, key distribution is a problem with pretty much all cryptography unless you get into asymmetric ciphers and that's not what this is. I would recommend using the Diffie-Hellman key exchange method in combination with the procedure I just described above.
Probably I'll end up using SHA-256; I might change it for greater output or maybe I'll just have the user enter multiple phrases, either one would work. For now, the cipher seems to be working great-- noone's even gotten close to breaking it. Soon I'll put out the algorithm for the PRNG on this forum along with an encrypted message and all you guys can try to break it if you want... :)

Quote:

---

Originally posted here by 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.

---

ive been playing with this "encryption" method for a while, writing up differnet ways to combine a given text or data stream with a psudo-random 'key'. theres multiple ways to get the same thing done, including letting the computer do all the conversions for you and use the ASCII standard character values. this also lets you cypher any data, not just plain text. any way, the method ive come to use for the key distrobution is so simple that you all pimply overlook it. i create a 700 meg random chatacter text file on a CD, then snail mail it to whomever (or for the really paranoid, hand it to them personaly) its going to. simply never use the same data block twice, mark it off limets with a little text file in your home directory that tells you what byte to start at, complement this by puting the starting bit on the front of the cyphered file. its that simple. but natuarly both partys have to have the exact same CD or data loss will occur. also, if it your not to paranoid about the data then you can reuse the CDs miltiple times but keeping in mind that everytime you use the same 'key' block that portion becomes less secure to whomever is watching you. and another thing, i dont often encrypt and send data thats more than 700 megs..... cause im my book and via email, thats a hell of alot of emails!

i know what your gonna say also, if you gotta give them the CD by hand to begin with then why not just give them the data you wanna send them? easy. it only works for if you are planing something like ongoing corespondance.......

for those of you interested:

how i came up with this method of key distrobution was basicly in the Army. how we did it in the army was we got the key handed to us (basicly) before we left garrison. used the key we were assigned thruout the mission, and destroy the key (well actualy erase) after we come back. that simple. then next time we get a diferent key. the army uses a much less technologicaly advanced cypher method than anything used today. just for those of you interested......

well i hope i shed some light on this little potic of key distrobution

also, i hate to tell you but your doing something that is not patentable, your trying to claim a patent on subtraction basicly when you think about it. and theres for to be alittle more to the mathmatical formula before any patent office will let it get thru. sorry....

In relpy to LoggOff's comments - yup, agree with you completely.
It really depends on what you are using this for - just because something is technically unsophisticated (after all, one time pads have been used for centuries with just pencil & paper), it does not mean it is insecure if used correctly. As you mentioned the important things are how the key is generated, and how it is distributed. Putting random data onto a CD will work, as long as no copy of this is kept on the individual PCs - any working copy of the data should be permenantly erased after use. Which means that your security comes down to keeping the CD(s) physically secure, and making sure that the key itself is as random as you can make it.

LogOff: I meant that I would patent the random number generators and algorithms specific to this encryption method, not subtraction in general :)
Also, I just want to clarify how key distribution works under this system, as it seems to be what everyone's talking about right now. First, you put in a password. This password can be as long or short as the user wants it to be. This password is then put through a secure hash algorithm that has 1024- or 2048-bit output. This output is used to seed a highly secure pseudo-random number generator that produces a key of arbitrary length. This system could be useful in other ways than encryption by subtraction; one could easily use it to produce large keys for AES or something.
To distribute the key, all you need to remember is the password. You just convert it to a series of numbers and send it with the Diffie-Hellman key exchange method. I know that I'm not the first person to come up with this; it seems to be the best way.
I'm almost ready to post a sample of encrypted material, if anyone wants to try to break it. I'll post the algorithm that created the key too.

Quote:

---

First, you put in a password. This password can be as long or short as the user wants it to be. This password is then put through a secure hash algorithm that has 1024- or 2048-bit output. This output is used to seed a highly secure pseudo-random number generator that produces a key of arbitrary length.

---

All you need is the password. so what is the purpose of the hash???? Also, if your random number generator only has one seed, then it isn't even close to being random. Even a simple one like the rand () command uses 2 seeds. The time and the input from the microphone port.

It just seems like you are doing extra steps which will do nothing but take extra time.

ok fair enuf about the patent, wish you luck with it then, the main problem that you have in the the key that lesens the security is that it is not random really. you have a base of a password and from that with the use of the hash algorithim its simple to figure the hashed key or the key, however you use it. if you use a key that is of equal length to the data to be encrypted then you can encrypt each character with its own personalised key character sothat each character that you want encrypted has its own key character in a way. if its dont this way then yes, key distro becomes alot harder and if you want physical security just use one of those miniCDs that only hold 50megs of data, thats still alot of data to be encrypted and its at the same time replacible if the CD gets stolen. its not 700 megs of wasted data thats not used. see what im saying? i dont know, i kinda like this method better than a password based method that has a hash at the end of it all. a hash disnt really stop someone cracking it like john-the-ripper style and for the data above 2k youll start using the key over again which by simple nature of it starts to defeat the point of having the key a non fixed length. i think that if this has the potential to be an equal bit to data key length........ if a =26 and b is your key and b =25 then you subtract a-b=z ..... ok if you dont know that the key is b then you simply cant guess cause you come up with every posible answer as a posible answer, c might be the key, d might be the key........... and so on there by creating a uncrackable code.... get it? sorry if i sound alittle ranty, i dont mean to.

>All you need is the password. so what is the purpose of the hash???? Also, if your random number generator only has one seed, then it isn't even close to being random. >Even a simple one like the rand () command uses 2 seeds. The time and the input from the microphone port.
>
>It just seems like you are doing extra steps which will do nothing but take extra time.

First of all, the random number generator does not have only one seed. It takes the output from the 2048-bit hash and divides it into sixty-four individual 32-bit seeds. This is more secure than any other purely mathematical pseudorandom number generator that there is right now. What you said about the time and mic is called entropy seeding. The problem with entropy seeding is that is can almost never be repeated. Unless you decrypt at the exact same time on the exact same computer with the exact same system status, you will not get back your original message even with the right key. Entropy seeding is useless in cryptographic applications.
Second, the hash algorithm is completely necessary. If you merely convert a password to ASCII numbers and use that as the seed, then the message can be cracked much more easily. Most people will not enter a password more than 32 bits in length. But if a small password goes through a 2048-bit hash, it comes out as a 2048-bit string of data. If this is converted to many small seeds for a random number generator, it will always be more secure than a single small seed. The hash's purpose is to increase (or decrease if necessary) the size of the password to make it more secure for random number generator seeding. If you use a single password as the seed then the cryptanalyst doesn't have to try nearly as many keys. For a single 64-bit password, there are 2^64 number of possible keys; but for sixty-four 32-bit seeds, there are (2^32)^64. With that many keys, it would take extremely long to check each one. Longer than RSA, AES, 3DES, Blowfish, or anything else. That's the reason that this method could be used for other things than just my subtraction thing.
So, to answer Souleman's comment, the hash is to produce multiple seeds from a single password and there are sixty-four seeds, not one.
Also, what LogOff said sounds like a onetime pad. They are indeed unbreakable but like you said key distribution gets annoying. That's actually why I originally came up with the random number gnereator idea; you could use it with modulated output to produce keys for a onetime pad.

ne1 read... Between Silk and Cyanide?

brings up a nice point about randomness.

further reading: DC-stuff newslist

(I challenge you to Break Wynacht's code...i'm on my fourth month of it)

Quote:

---

The problem with entropy seeding is that is can almost never be repeated.

---

Thats the point of a random number generator. If it can be easily repeated, its not even psudo-random.

Quote:

---

If you merely convert a password to ASCII numbers and use that as the seed, then the message can be cracked much more easily.

---

If my password is "ABC" I don't care if you put it through a 5 Meg hash, all you need to break it is "ABC"

Adding more steps does not make something more secure. One of the original DES test algorithims went throough something like 64 "boxes" It was actually weaker then the current one, which goes through 13 (if I rememeber correctly).

First of all, in cryptography the point of a random number generator is NOT to give irreproducible results. THe whole point of the random number generator in this algorithm is to produce keystreams. The user gives a password which is converted into seeds for the random number generator. The random number generator gives modulated output and reseeds itself to give more output for as many iterations as are necessary. When the user enters a certain password, a certain key will invariably come up. This way, when the user decrypts the message all he has to remember is the password. If it were not this way; that is, if the same password did not always produce the same results due to the use of system entropy as a secondary seed, then when the user tries to decrypt he will fail because the system status will have changed in some way and the key will be different. This will produce incorrect output of decrypted text.

Say I encrypt "apple" with password of "dog" and it comes out as "djfghkjdf". Now, if the same output occurs with each seed then I can enter "dog" and get back the key to reverse the process. But if entropy is used, then the second time I enter "dog" I will not get the same output, and I cannot decrypt my message. This is why entropy seeding is COMPLETELY UNNECESSARY in cryptography.

Second, I will state the purpose of the hash as clearly as I can...

For a n-character ASCII password, the number of possible keys is 95^n. If a single password is used then there will invariably be a limit on password size. If the limit is 20 then a computer only has to chech 95^20 keys to break the password. But if a hash is used, then the user can use a password of literally any length. The hash will shorten it if it is too long but not just cut it off. And if you are using a hash to shorten long passwords then you want the hash output to be as large as possible so that different paswords will produce the same hash as rarely as is possible. If you have a 32-bit hash then there will inevitably be two passwords of over 32 bits whose hashes are alike. By using a large but secure hash, we allow the user to use a password of arbitrary length while minimizing the chance that two passwords will come out with the same hash.

Finally, extra steps actually do make things more secure. A combination lock with 3 numbers is always more secure combination-wise than a lock with only two. Similarly, AES

sorry, my last message go cut off-- I was going to say that AES is only a more complicated setup of the same Fiestel networks used in DES, but everyone knows it is more secure.

he he he, he said "only has to chech 95^20 keys".... he he he, its the ONLY that gets me, its kinda like Bill gates is ONLY the ritchest man in the world.......

sorry, ill start acting my age again

95^20 is nothing if you've got supercomputers and all that good stuff...but (2^32)^64 is! If you had a billion billion computers and each could check a billion billion keys per second, then it would take 1.02476554006x10^591 YEARS to check each possible key. And nothing's that fast anyway...

hmmmm thats a good calculater you got to figure those numbers, i know that the XP towertoys calcualtor only toped out at 512 bit numbers...... what are you doing those calculations on? just curious cause i havent figured out a good calcualtor tool in linux yet

LoggOff: I use a TI-89. It's really great- it'll solve multivariable equations, graph in 3D, and handle really big numbers right down to the units digit usually. I recommend it strongly. Also, I program it a LOT; mine right now has about 10 crypto programs. TI-89 uses a computer algebra system so it's as good as one of the expensive software ones for computer (if not as fast...!)

yeah i used the 83s before, but i dont care for a calculator that is trying to be a Palm clone, and besides i dont have near the cash to dish out to the unit to begin with. but uts cool that it does those high precision numbers tho

have i missed something?
i take it the algorithm is to be public domain, and the decrypt relys on the possesion of a password. This is called password protection. even Winzip does this.
it doesnt matter if your algorithm generates a key of aleph3 bits based on more random seeds than could be stored on every quark in the universe (assuming that physists discover that they are actually rather large sticky notes) - the encyphered text is only protected by a password.
Worse you have suggested that your algorithm allows for your more convenient, shorter kind of password.
what key would your algorithm output if the password was "dictionaryAttack"?

djf: Of course you could use a dictionary attack against a stupid user. However, you don't have to use a normal password. The algorithm supports full ASCII and passwords could be a large number or something. While it is possible to encrypt with just a password, it is at least as weak as you said. I am certainly not suggesting that the algorithm be used solely for password protection: the examples of using a password as a key that I showed are just proof-of-principle examples. I would suggest that if one were to seriously use this algorithm that he or she should use a very large hash seed and possibly encrypt with multiple rounds. To get up a large hash seed, you could easily gather system entropy, as described in previous posts, and send it to the person who will receive your message by means of the Diffie-Hellman key exchange system. This way, you have a truly unpredictable hash seed.
I only used passwords as hash seeds in the examples in previous posts because it is a lot simpler to use "dog" than "fd5g465gdfd132k1jgh5145" or something like that. Obviously if anyone who knows about cryptographic attacks were to use this algorithm, that person would not do so. The difference between this and most algorithms is that keys can be arbitrarily long, and thus it is impossible to check each one. In an application like WinZip, each key is a limited number of bits. So if, in something like WinZip, I were to use a random key "11060799421205080995", all a cryptanalyst would have to do is check every key until he or she gets the right one. In an algorithm like mine, there is no way to do this, so a piece of ciphertext encrypted with a key like "110801202038804105001505005566838687114929556840035223224005316192826214404016504627426260" is virtually unbreakable, and larger and more complex keys can easily be used.