draziw> you obviously didn't read the entire thread cause key exchange was the first thing I mentioned in the post right before yours ;)
Printable View
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... :)
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!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.
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.
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.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.
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.