Re: A new, fast and "unbreakable" encryption algorithm
On 2015-12-04 04:42, Ismail Kizir wrote: Clemens, You really don't know what you are talking about. Don't you? :) And this is my last mail about the subject. I don't want to keep the list busy. The original, unencrypted "plaintext" file was all zeroes. When I uploaded to blogspot, it appeared all "red" and it still is. And it has not any "red" cyphertext :) http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html It looks a lot more like you don't know what your talking about. Human perceptions of 'randomness' do not align with actual mathematical definitions of it. From a mathematical standpoint, 'random' means that given any arbitrary number of previous values, it is impossible to predict what the next value will be. An excellent example of something that 'looks random' to a human but really isn't is machine code. To anyone who's never dealt with it, it looks just like a jumble of bytes. To someone who has dealt with it, it's pretty easy to predict certain patterns, and if you know what to lock for, you can even tell to a certain extent what type of processor it's for (for example, machine code for the MSP430 tends to have lots of 0x4303 words in it, because that's the translation of a NO-OP). Try importing an executable file into Gimp or Krita as a raw image, you'll see definite patterning in a couple of places, but most of it will look like static. Similarly, do the same but with an audio import into something like Audacity, you'll get a mix of silence and static with a handful of odd fixed frequency tones mixed in. Both of these seem perfectly random to most people, but they really aren't, they just seem that way because the structure of the data doesn't fit in the context in which it's being viewed. I've run essentially the same tests that Clemens did, and got the same results, and as such agree with him and Pavel. Given the output, it's trivially possible to infer the input in a given set of cases, and given that, it's not unreasonable to assume that it's possible to directly infer the input in any arbitrary case. Saying that it's a good encryption algorithm because the output looks different than the input is not a valid argument, you have to do a proper analysis of the output, which means more than just encrypting a bitmap and seeing if you can recognize a pattern in the result. The algorithm is of little practical use beyond the type of thing that ROT13 or a Caesar cipher would be used for (IOW, I might consider using it to obfuscate something to annoy someone who's just being nosy, but I would not by any means trust it for anything that I wanted protected from unauthorized access). On Fri, Dec 4, 2015 at 9:34 AM, Clemens Ladisch wrote: Ismail Kizir wrote: What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. On the pictures, there is also an example of "full 0"(it appears red, but it is full 0 bmp) example. And it "looks" perfectly random. No, red is _not_ perfectly random. When I see a red picture, I have evidence that the plaintext was zeroes. Regards, Clemens smime.p7s Description: S/MIME Cryptographic Signature
Re: A new, fast and "unbreakable" encryption algorithm
Clemens, You really don't know what you are talking about. Don't you? :) And this is my last mail about the subject. I don't want to keep the list busy. The original, unencrypted "plaintext" file was all zeroes. When I uploaded to blogspot, it appeared all "red" and it still is. And it has not any "red" cyphertext :) http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html On Fri, Dec 4, 2015 at 9:34 AM, Clemens Ladisch wrote: > Ismail Kizir wrote: >> What means "did not look random"? > > A plaintext consisting of repeated bytes (zero, or other values) > eventually makes your algorithm go into a loop, which results in > repeated bytes. > >> On the pictures, there is also an example of "full 0"(it appears red, >> but it is full 0 bmp) example. >> And it "looks" perfectly random. > > No, red is _not_ perfectly random. When I see a red picture, I have > evidence that the plaintext was zeroes. > > > Regards, > Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Clemens, You really don't know what you are talking about. Don't you? :) And this is my last mail about the subject. I don't want to keep the list busy. The original, unencrypted "plaintext" file was all zeroes. When I uploaded to blogspot, it appeared all "red" and it still is. And it has not any "red" cyphertext :) http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html On Fri, Dec 4, 2015 at 9:34 AM, Clemens Ladischwrote: > Ismail Kizir wrote: >> What means "did not look random"? > > A plaintext consisting of repeated bytes (zero, or other values) > eventually makes your algorithm go into a loop, which results in > repeated bytes. > >> On the pictures, there is also an example of "full 0"(it appears red, >> but it is full 0 bmp) example. >> And it "looks" perfectly random. > > No, red is _not_ perfectly random. When I see a red picture, I have > evidence that the plaintext was zeroes. > > > Regards, > Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
On 2015-12-04 04:42, Ismail Kizir wrote: Clemens, You really don't know what you are talking about. Don't you? :) And this is my last mail about the subject. I don't want to keep the list busy. The original, unencrypted "plaintext" file was all zeroes. When I uploaded to blogspot, it appeared all "red" and it still is. And it has not any "red" cyphertext :) http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html It looks a lot more like you don't know what your talking about. Human perceptions of 'randomness' do not align with actual mathematical definitions of it. From a mathematical standpoint, 'random' means that given any arbitrary number of previous values, it is impossible to predict what the next value will be. An excellent example of something that 'looks random' to a human but really isn't is machine code. To anyone who's never dealt with it, it looks just like a jumble of bytes. To someone who has dealt with it, it's pretty easy to predict certain patterns, and if you know what to lock for, you can even tell to a certain extent what type of processor it's for (for example, machine code for the MSP430 tends to have lots of 0x4303 words in it, because that's the translation of a NO-OP). Try importing an executable file into Gimp or Krita as a raw image, you'll see definite patterning in a couple of places, but most of it will look like static. Similarly, do the same but with an audio import into something like Audacity, you'll get a mix of silence and static with a handful of odd fixed frequency tones mixed in. Both of these seem perfectly random to most people, but they really aren't, they just seem that way because the structure of the data doesn't fit in the context in which it's being viewed. I've run essentially the same tests that Clemens did, and got the same results, and as such agree with him and Pavel. Given the output, it's trivially possible to infer the input in a given set of cases, and given that, it's not unreasonable to assume that it's possible to directly infer the input in any arbitrary case. Saying that it's a good encryption algorithm because the output looks different than the input is not a valid argument, you have to do a proper analysis of the output, which means more than just encrypting a bitmap and seeing if you can recognize a pattern in the result. The algorithm is of little practical use beyond the type of thing that ROT13 or a Caesar cipher would be used for (IOW, I might consider using it to obfuscate something to annoy someone who's just being nosy, but I would not by any means trust it for anything that I wanted protected from unauthorized access). On Fri, Dec 4, 2015 at 9:34 AM, Clemens Ladischwrote: Ismail Kizir wrote: What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. On the pictures, there is also an example of "full 0"(it appears red, but it is full 0 bmp) example. And it "looks" perfectly random. No, red is _not_ perfectly random. When I see a red picture, I have evidence that the plaintext was zeroes. Regards, Clemens smime.p7s Description: S/MIME Cryptographic Signature
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir wrote: > What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. > On the pictures, there is also an example of "full 0"(it appears red, > but it is full 0 bmp) example. > And it "looks" perfectly random. No, red is _not_ perfectly random. When I see a red picture, I have evidence that the plaintext was zeroes. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Pavel, What means "did not look random"?? On the pictures, there is also an example of "full 0"(it appears red, but it is full 0 bmp) example. And it "looks" perfectly random. What are trying to do with your baseless allegations? Ismail On Fri, Dec 4, 2015 at 12:35 AM, Pavel Machek wrote: > Hi! > >> Check this out please; just visual proofs: Better than thousands of lines: >> http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html > > Trouble is... it is hard to prove your encryption can not be broken, > but it is very easy to prove your encryption _can_ be broken. (*) > > And it looks like Clemens did just that: > >> > Anyway, I tried to modify your program to encrypt a large message >> > consisting only of zero bytes. The result did not look random. > > Sorry. > > Pavel > (*) And no, those pictures don't really prove anything. > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hi! > Check this out please; just visual proofs: Better than thousands of lines: > http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html Trouble is... it is hard to prove your encryption can not be broken, but it is very easy to prove your encryption _can_ be broken. (*) And it looks like Clemens did just that: > > Anyway, I tried to modify your program to encrypt a large message > > consisting only of zero bytes. The result did not look random. Sorry. Pavel (*) And no, those pictures don't really prove anything. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir wrote: > What means "did not look random"? A plaintext consisting of repeated bytes (zero, or other values) eventually makes your algorithm go into a loop, which results in repeated bytes. > On the pictures, there is also an example of "full 0"(it appears red, > but it is full 0 bmp) example. > And it "looks" perfectly random. No, red is _not_ perfectly random. When I see a red picture, I have evidence that the plaintext was zeroes. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Pavel, What means "did not look random"?? On the pictures, there is also an example of "full 0"(it appears red, but it is full 0 bmp) example. And it "looks" perfectly random. What are trying to do with your baseless allegations? Ismail On Fri, Dec 4, 2015 at 12:35 AM, Pavel Machekwrote: > Hi! > >> Check this out please; just visual proofs: Better than thousands of lines: >> http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html > > Trouble is... it is hard to prove your encryption can not be broken, > but it is very easy to prove your encryption _can_ be broken. (*) > > And it looks like Clemens did just that: > >> > Anyway, I tried to modify your program to encrypt a large message >> > consisting only of zero bytes. The result did not look random. > > Sorry. > > Pavel > (*) And no, those pictures don't really prove anything. > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hi! > Check this out please; just visual proofs: Better than thousands of lines: > http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html Trouble is... it is hard to prove your encryption can not be broken, but it is very easy to prove your encryption _can_ be broken. (*) And it looks like Clemens did just that: > > Anyway, I tried to modify your program to encrypt a large message > > consisting only of zero bytes. The result did not look random. Sorry. Pavel (*) And no, those pictures don't really prove anything. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hello Clemens, Check this out please; just visual proofs: Better than thousands of lines: http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html Regards Ismail Kizir On Thu, Nov 19, 2015 at 11:05 AM, Clemens Ladisch wrote: > Ismail Kizir wrote: >> The essential logic of the algorithm is using the key as a "jump >> table" which is dynamically updated with every "jump" we make. > > Sounds like RC4. Please tell us how you are avoiding the weaknesses > that make RC4 insecure. > >> Briefly, to decypher a ciphertext, a cracker needs to find out the >> key, and, to find out the key, cracker needs to find out the >> plaintext, because the key is dynamically updated according the >> plaintext during encryption process: Impossible! > > That problem has been solved for a long time: > https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation > > > Anyway, I tried to modify your program to encrypt a large message > consisting only of zero bytes. The result did not look random. > > > Regards, > Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hello Clemens, Check this out please; just visual proofs: Better than thousands of lines: http://ismail-kizir.blogspot.com.tr/2015/11/visual-proofs-of-hohha-dynamic-xor.html Regards Ismail Kizir On Thu, Nov 19, 2015 at 11:05 AM, Clemens Ladischwrote: > Ismail Kizir wrote: >> The essential logic of the algorithm is using the key as a "jump >> table" which is dynamically updated with every "jump" we make. > > Sounds like RC4. Please tell us how you are avoiding the weaknesses > that make RC4 insecure. > >> Briefly, to decypher a ciphertext, a cracker needs to find out the >> key, and, to find out the key, cracker needs to find out the >> plaintext, because the key is dynamically updated according the >> plaintext during encryption process: Impossible! > > That problem has been solved for a long time: > https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation > > > Anyway, I tried to modify your program to encrypt a large message > consisting only of zero bytes. The result did not look random. > > > Regards, > Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Lukasz, Clemens, Herald, Others Linux and Open Source Enthusiasts: You are all invited to collaboratively improve our encryption algorithm at: https://github.com/ikizir/HohhaDynamicXOR Write down every weaknesses you find, every idea to improve; every code piece you think necessary. Let us not disturb kernel group anymore. Thank you very much in advance On Thu, Nov 19, 2015 at 2:31 PM, Ismail Kizir wrote: > Francly Lucasz, > > I am not an expert and never claimed it. > And I accept it's vulnerable to side channel attacks like the one you > mentioned. > With this occasion, I want to emphasize one point: > I don't claim that the my algorithm is perfect. > But, take a look at this: > > But, I am sure, this "dynamic key model" is the right way to follow > for the encyption. > You are all on the top of the "IT food chain" guys. > It is a GPLed algorithm and code. > Let's develop it ourselves for ourselves. > Let's think together. > For example; Clemens's "all zero" file is another weak point. I am > thinking about it too. > Help me. Criticise the algorithm. wrote you all to be criticised. > Show me the weaknesses Let's think together and get it better. > Some people think that's not the right place for this discussions and > they may be right. Write me privately please. And I am constantly > updating the code on > http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html > > Ismail Kizir > CTO, Hohha Internet Services Ltd. > > On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach > wrote: >> It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >>> Hello, >>> >>> I've developed a new encryption algorithm, which dynamically changes >>> the key according to plaintext and practically impossible to break. >> [...] >>> I will be glad to see my algorithm included in Linux distributions. >>> Please feel free to ask if you have any questions. >> >> How resistant to side-channel attacts is or can be an implementation of >> your algorithm? Not being an expert I am a bit worried about this >> particular line >> >> XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); >> >> which if I understand it correctly makes a memory access depending on >> secret data. Because memory accesses are note constant time operations >> due to cache one might try (and succeed?) learning about secrets by >> measuring time required to encrypt or decrypt data. >> >> -- >> Łukasz Stelmach >> Samsung R Institute Poland >> Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
It was <2015-11-19 czw 13:31>, when Ismail Kizir wrote: > On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach > wrote: >> It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >>> Hello, >>> >>> I've developed a new encryption algorithm, which dynamically changes >>> the key according to plaintext and practically impossible to break. >> [...] >>> I will be glad to see my algorithm included in Linux distributions. >>> Please feel free to ask if you have any questions. >> >> How resistant to side-channel attacts is or can be an implementation of >> your algorithm? Not being an expert I am a bit worried about this >> particular line >> >> XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); >> >> which if I understand it correctly makes a memory access depending on >> secret data. Because memory accesses are note constant time operations >> due to cache one might try (and succeed?) learning about secrets by >> measuring time required to encrypt or decrypt data. > > I am not an expert and never claimed it. And I accept it's vulnerable > to side channel attacks like the one you mentioned. With this > occasion, I want to emphasize one point: I don't claim that the my > algorithm is perfect. But, take a look at this: > > But, I am sure, this "dynamic key model" is the right way to follow > for the encyption. The issue I am attempting to point out is that even if mathematically an algoritm is perfectly unbreakable (there is no easier way to recover plaintext than a brute force attack) and its implementations are/can be fast (in terms of clock cycles per encrypted byte) it may be of no practical use because of possible side-channel attacks (the more pracrical an attack the less usefull an algorithm/implementation). Sometimes side-channel vulnerabilities can be fixed in software but they need to be well understood. IMHO if you want to "sell" your algorithm you need analyse its possible side-channel weaknesses too. Moreover, if you'd like your algorithm to become a part of Linux kernel I recomend you prepare a patch plugging it properly into crypto/ directory. Kind regards, -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: A new, fast and "unbreakable" encryption algorithm
Francly Lucasz, I am not an expert and never claimed it. And I accept it's vulnerable to side channel attacks like the one you mentioned. With this occasion, I want to emphasize one point: I don't claim that the my algorithm is perfect. But, take a look at this: But, I am sure, this "dynamic key model" is the right way to follow for the encyption. You are all on the top of the "IT food chain" guys. It is a GPLed algorithm and code. Let's develop it ourselves for ourselves. Let's think together. For example; Clemens's "all zero" file is another weak point. I am thinking about it too. Help me. Criticise the algorithm. wrote you all to be criticised. Show me the weaknesses Let's think together and get it better. Some people think that's not the right place for this discussions and they may be right. Write me privately please. And I am constantly updating the code on http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html Ismail Kizir CTO, Hohha Internet Services Ltd. On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach wrote: > It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. > [...] >> I will be glad to see my algorithm included in Linux distributions. >> Please feel free to ask if you have any questions. > > How resistant to side-channel attacts is or can be an implementation of > your algorithm? Not being an expert I am a bit worried about this > particular line > > XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); > > which if I understand it correctly makes a memory access depending on > secret data. Because memory accesses are note constant time operations > due to cache one might try (and succeed?) learning about secrets by > measuring time required to encrypt or decrypt data. > > -- > Łukasz Stelmach > Samsung R Institute Poland > Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: > Hello, > > I've developed a new encryption algorithm, which dynamically changes > the key according to plaintext and practically impossible to break. [...] > I will be glad to see my algorithm included in Linux distributions. > Please feel free to ask if you have any questions. How resistant to side-channel attacts is or can be an implementation of your algorithm? Not being an expert I am a bit worried about this particular line XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); which if I understand it correctly makes a memory access depending on secret data. Because memory accesses are note constant time operations due to cache one might try (and succeed?) learning about secrets by measuring time required to encrypt or decrypt data. -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir wrote: > The essential logic of the algorithm is using the key as a "jump > table" which is dynamically updated with every "jump" we make. Sounds like RC4. Please tell us how you are avoiding the weaknesses that make RC4 insecure. > Briefly, to decypher a ciphertext, a cracker needs to find out the > key, and, to find out the key, cracker needs to find out the > plaintext, because the key is dynamically updated according the > plaintext during encryption process: Impossible! That problem has been solved for a long time: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Anyway, I tried to modify your program to encrypt a large message consisting only of zero bytes. The result did not look random. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir wrote: > The essential logic of the algorithm is using the key as a "jump > table" which is dynamically updated with every "jump" we make. Sounds like RC4. Please tell us how you are avoiding the weaknesses that make RC4 insecure. > Briefly, to decypher a ciphertext, a cracker needs to find out the > key, and, to find out the key, cracker needs to find out the > plaintext, because the key is dynamically updated according the > plaintext during encryption process: Impossible! That problem has been solved for a long time: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation Anyway, I tried to modify your program to encrypt a large message consisting only of zero bytes. The result did not look random. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: > Hello, > > I've developed a new encryption algorithm, which dynamically changes > the key according to plaintext and practically impossible to break. [...] > I will be glad to see my algorithm included in Linux distributions. > Please feel free to ask if you have any questions. How resistant to side-channel attacts is or can be an implementation of your algorithm? Not being an expert I am a bit worried about this particular line XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); which if I understand it correctly makes a memory access depending on secret data. Because memory accesses are note constant time operations due to cache one might try (and succeed?) learning about secrets by measuring time required to encrypt or decrypt data. -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: A new, fast and "unbreakable" encryption algorithm
Francly Lucasz, I am not an expert and never claimed it. And I accept it's vulnerable to side channel attacks like the one you mentioned. With this occasion, I want to emphasize one point: I don't claim that the my algorithm is perfect. But, take a look at this: But, I am sure, this "dynamic key model" is the right way to follow for the encyption. You are all on the top of the "IT food chain" guys. It is a GPLed algorithm and code. Let's develop it ourselves for ourselves. Let's think together. For example; Clemens's "all zero" file is another weak point. I am thinking about it too. Help me. Criticise the algorithm. wrote you all to be criticised. Show me the weaknesses Let's think together and get it better. Some people think that's not the right place for this discussions and they may be right. Write me privately please. And I am constantly updating the code on http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html Ismail Kizir CTO, Hohha Internet Services Ltd. On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmachwrote: > It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. > [...] >> I will be glad to see my algorithm included in Linux distributions. >> Please feel free to ask if you have any questions. > > How resistant to side-channel attacts is or can be an implementation of > your algorithm? Not being an expert I am a bit worried about this > particular line > > XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); > > which if I understand it correctly makes a memory access depending on > secret data. Because memory accesses are note constant time operations > due to cache one might try (and succeed?) learning about secrets by > measuring time required to encrypt or decrypt data. > > -- > Łukasz Stelmach > Samsung R Institute Poland > Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Lukasz, Clemens, Herald, Others Linux and Open Source Enthusiasts: You are all invited to collaboratively improve our encryption algorithm at: https://github.com/ikizir/HohhaDynamicXOR Write down every weaknesses you find, every idea to improve; every code piece you think necessary. Let us not disturb kernel group anymore. Thank you very much in advance On Thu, Nov 19, 2015 at 2:31 PM, Ismail Kizirwrote: > Francly Lucasz, > > I am not an expert and never claimed it. > And I accept it's vulnerable to side channel attacks like the one you > mentioned. > With this occasion, I want to emphasize one point: > I don't claim that the my algorithm is perfect. > But, take a look at this: > > But, I am sure, this "dynamic key model" is the right way to follow > for the encyption. > You are all on the top of the "IT food chain" guys. > It is a GPLed algorithm and code. > Let's develop it ourselves for ourselves. > Let's think together. > For example; Clemens's "all zero" file is another weak point. I am > thinking about it too. > Help me. Criticise the algorithm. wrote you all to be criticised. > Show me the weaknesses Let's think together and get it better. > Some people think that's not the right place for this discussions and > they may be right. Write me privately please. And I am constantly > updating the code on > http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html > > Ismail Kizir > CTO, Hohha Internet Services Ltd. > > On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach > wrote: >> It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >>> Hello, >>> >>> I've developed a new encryption algorithm, which dynamically changes >>> the key according to plaintext and practically impossible to break. >> [...] >>> I will be glad to see my algorithm included in Linux distributions. >>> Please feel free to ask if you have any questions. >> >> How resistant to side-channel attacts is or can be an implementation of >> your algorithm? Not being an expert I am a bit worried about this >> particular line >> >> XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); >> >> which if I understand it correctly makes a memory access depending on >> secret data. Because memory accesses are note constant time operations >> due to cache one might try (and succeed?) learning about secrets by >> measuring time required to encrypt or decrypt data. >> >> -- >> Łukasz Stelmach >> Samsung R Institute Poland >> Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
It was <2015-11-19 czw 13:31>, when Ismail Kizir wrote: > On Thu, Nov 19, 2015 at 2:12 PM, Łukasz Stelmach> wrote: >> It was <2015-11-18 śro 06:25>, when Ismail Kizir wrote: >>> Hello, >>> >>> I've developed a new encryption algorithm, which dynamically changes >>> the key according to plaintext and practically impossible to break. >> [...] >>> I will be glad to see my algorithm included in Linux distributions. >>> Please feel free to ask if you have any questions. >> >> How resistant to side-channel attacts is or can be an implementation of >> your algorithm? Not being an expert I am a bit worried about this >> particular line >> >> XORVal ^= *(Salt + (LastVal&(SALT_SIZE-1))); >> >> which if I understand it correctly makes a memory access depending on >> secret data. Because memory accesses are note constant time operations >> due to cache one might try (and succeed?) learning about secrets by >> measuring time required to encrypt or decrypt data. > > I am not an expert and never claimed it. And I accept it's vulnerable > to side channel attacks like the one you mentioned. With this > occasion, I want to emphasize one point: I don't claim that the my > algorithm is perfect. But, take a look at this: > > But, I am sure, this "dynamic key model" is the right way to follow > for the encyption. The issue I am attempting to point out is that even if mathematically an algoritm is perfectly unbreakable (there is no easier way to recover plaintext than a brute force attack) and its implementations are/can be fast (in terms of clock cycles per encrypted byte) it may be of no practical use because of possible side-channel attacks (the more pracrical an attack the less usefull an algorithm/implementation). Sometimes side-channel vulnerabilities can be fixed in software but they need to be well understood. IMHO if you want to "sell" your algorithm you need analyse its possible side-channel weaknesses too. Moreover, if you'd like your algorithm to become a part of Linux kernel I recomend you prepare a patch plugging it properly into crypto/ directory. Kind regards, -- Łukasz Stelmach Samsung R Institute Poland Samsung Electronics signature.asc Description: PGP signature
Re: A new, fast and "unbreakable" encryption algorithm
I am not a cyrptoanalyst, not a mathematicien. But, I wanted to enumerate some facts about "The Hohha Dynamic XOR Encryption" algorithm I mentioned earlier. My algorithm is "fundamentally different" from classical encryption methods, because, it dynamically "encrypts" the key itself "during a single transaction"! "My Salt value" is a randomly choosen 4 bytes for every "transaction". My "salt" is neither salt, nor IV nor "salt in hashing", nor "nonce" in cryptology, but a combination of all them. Because: The first jump position, depends on the salt value. Changing the initial position of the encryption gives a "completely different output"! This is a precaution against, chosen ciphertext attacks. Not finished! I XOR all bytes of salt value with 8Bit CRC, which give me a "completely different output" for a small change in key, as I am using those salt values for every byte to be encrypted. This is a precaution against "related key attacks" Changing the "salt value"(or call it nonce value if you prefer) of the algorithm is not just a multiplication of possibilities by 255^4; but it also "completely" changes the result. Because, it "completely" changes the jump path! The algorithm is safe against: Cryptoanalysis like : Index of coincidence, Kasiski, Vigenere Cypher. Because, there is no "pattern". For example the most frequent letter "A", of Turkish alphabet will be encrpyted as different values each time. Most importantly; during a single transaction, the plaintext is encrypted with the key, meanwhile, the key itself is encrypted with the plaintext. This avoids "chosen ciphertext" attack, "ciphertext only attack" or differential cryptoanalysis. Even if salting is not used, the algorithm guarantees us that it is impossible to find out the key even if we have the cyphertext and plaintext. Because, "there will be a lack of information". Let's take the trivial example: We do at least 2 jumps. So, we XOR the plaintext byte with at least 2 numbers. In this case, even if we have the plaintext and the cyphertext, we may just obtain the XOR result of 2 unknown values. Regards Ismail Kizir On Wed, Nov 18, 2015 at 6:33 PM, Harald Arnesen wrote: > Ismail Kizir [2015-11-18 06:25]: > >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. I >> also opened to public with MIT dual License. > > "There are two kinds of cryptography in this world: cryptography that > will stop your kid sister from reading your files, and cryptography that > will stop major governments from reading your files." > - Bruce Scheier, Applied Cryptography > -- > Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hello Harald, I know that a lot of people thinks that there is a "new amateur in town claiming having invented an unbreakable encryption" :) That's why, I am trying to explain all my logic, publicly to professionals. It's not rocket science. You will "just understand" when you read: Until today, we were looking from the "wrong side" I guess. We were all thinking that we must have a "fixed" key which must never change! Why? I begun to ask that question: "Why the key must be fixed?" and changed the paradigm. And I decided to dynamically update the key in encyption and decryption process. The essential logic of the algorithm is using the key as a "jump table" which is dynamically updated with every "jump" we make. To understand better how it functions, suppose that we don't have a complex function. Given the key body length(L) is a power of 2, and M is an integer to tell us where we are in the "key body": We just take the byte at position M of the key body, we XOR that byte with the byte to be encrypted(X). We increase the byte at position M and "jump to" (M+X)%L So, every time we encrypt a byte, we also change the key. It's a bit more complicated than this. But essentially this is the base logic. In real function, we do more complex operations with more variables like the salt(or nonce) value, the last byte we encrypted, the key checksum(against related key attacks) etc. Briefly, to decypher a ciphertext, a cracker needs to find out the key, and, to find out the key, cracker needs to find out the plaintext, because the key is dynamically updated according the plaintext during encryption process: Impossible! I just want Linux uses a "strong encryption algorithm" to prevent States, besides inalphabet kids, from reading your files :) I believe this algorithm is the future of the encryption. Source code: http://ismail-kizir.blogspot.com/2015/11/hohha-dynamic-xor-algorithm-source-code.html Regards On Wed, Nov 18, 2015 at 6:33 PM, Harald Arnesen wrote: > Ismail Kizir [2015-11-18 06:25]: > >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. I >> also opened to public with MIT dual License. > > "There are two kinds of cryptography in this world: cryptography that > will stop your kid sister from reading your files, and cryptography that > will stop major governments from reading your files." > - Bruce Scheier, Applied Cryptography > -- > Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir [2015-11-18 06:25]: > Hello, > > I've developed a new encryption algorithm, which dynamically changes > the key according to plaintext and practically impossible to break. I > also opened to public with MIT dual License. "There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files." - Bruce Scheier, Applied Cryptography -- Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Ismail Kizir [2015-11-18 06:25]: > Hello, > > I've developed a new encryption algorithm, which dynamically changes > the key according to plaintext and practically impossible to break. I > also opened to public with MIT dual License. "There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files." - Bruce Scheier, Applied Cryptography -- Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
Hello Harald, I know that a lot of people thinks that there is a "new amateur in town claiming having invented an unbreakable encryption" :) That's why, I am trying to explain all my logic, publicly to professionals. It's not rocket science. You will "just understand" when you read: Until today, we were looking from the "wrong side" I guess. We were all thinking that we must have a "fixed" key which must never change! Why? I begun to ask that question: "Why the key must be fixed?" and changed the paradigm. And I decided to dynamically update the key in encyption and decryption process. The essential logic of the algorithm is using the key as a "jump table" which is dynamically updated with every "jump" we make. To understand better how it functions, suppose that we don't have a complex function. Given the key body length(L) is a power of 2, and M is an integer to tell us where we are in the "key body": We just take the byte at position M of the key body, we XOR that byte with the byte to be encrypted(X). We increase the byte at position M and "jump to" (M+X)%L So, every time we encrypt a byte, we also change the key. It's a bit more complicated than this. But essentially this is the base logic. In real function, we do more complex operations with more variables like the salt(or nonce) value, the last byte we encrypted, the key checksum(against related key attacks) etc. Briefly, to decypher a ciphertext, a cracker needs to find out the key, and, to find out the key, cracker needs to find out the plaintext, because the key is dynamically updated according the plaintext during encryption process: Impossible! I just want Linux uses a "strong encryption algorithm" to prevent States, besides inalphabet kids, from reading your files :) I believe this algorithm is the future of the encryption. Source code: http://ismail-kizir.blogspot.com/2015/11/hohha-dynamic-xor-algorithm-source-code.html Regards On Wed, Nov 18, 2015 at 6:33 PM, Harald Arnesenwrote: > Ismail Kizir [2015-11-18 06:25]: > >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. I >> also opened to public with MIT dual License. > > "There are two kinds of cryptography in this world: cryptography that > will stop your kid sister from reading your files, and cryptography that > will stop major governments from reading your files." > - Bruce Scheier, Applied Cryptography > -- > Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A new, fast and "unbreakable" encryption algorithm
I am not a cyrptoanalyst, not a mathematicien. But, I wanted to enumerate some facts about "The Hohha Dynamic XOR Encryption" algorithm I mentioned earlier. My algorithm is "fundamentally different" from classical encryption methods, because, it dynamically "encrypts" the key itself "during a single transaction"! "My Salt value" is a randomly choosen 4 bytes for every "transaction". My "salt" is neither salt, nor IV nor "salt in hashing", nor "nonce" in cryptology, but a combination of all them. Because: The first jump position, depends on the salt value. Changing the initial position of the encryption gives a "completely different output"! This is a precaution against, chosen ciphertext attacks. Not finished! I XOR all bytes of salt value with 8Bit CRC, which give me a "completely different output" for a small change in key, as I am using those salt values for every byte to be encrypted. This is a precaution against "related key attacks" Changing the "salt value"(or call it nonce value if you prefer) of the algorithm is not just a multiplication of possibilities by 255^4; but it also "completely" changes the result. Because, it "completely" changes the jump path! The algorithm is safe against: Cryptoanalysis like : Index of coincidence, Kasiski, Vigenere Cypher. Because, there is no "pattern". For example the most frequent letter "A", of Turkish alphabet will be encrpyted as different values each time. Most importantly; during a single transaction, the plaintext is encrypted with the key, meanwhile, the key itself is encrypted with the plaintext. This avoids "chosen ciphertext" attack, "ciphertext only attack" or differential cryptoanalysis. Even if salting is not used, the algorithm guarantees us that it is impossible to find out the key even if we have the cyphertext and plaintext. Because, "there will be a lack of information". Let's take the trivial example: We do at least 2 jumps. So, we XOR the plaintext byte with at least 2 numbers. In this case, even if we have the plaintext and the cyphertext, we may just obtain the XOR result of 2 unknown values. Regards Ismail Kizir On Wed, Nov 18, 2015 at 6:33 PM, Harald Arnesenwrote: > Ismail Kizir [2015-11-18 06:25]: > >> Hello, >> >> I've developed a new encryption algorithm, which dynamically changes >> the key according to plaintext and practically impossible to break. I >> also opened to public with MIT dual License. > > "There are two kinds of cryptography in this world: cryptography that > will stop your kid sister from reading your files, and cryptography that > will stop major governments from reading your files." > - Bruce Scheier, Applied Cryptography > -- > Hilsen Harald -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A new, fast and "unbreakable" encryption algorithm
Hello, I've developed a new encryption algorithm, which dynamically changes the key according to plaintext and practically impossible to break. I also opened to public with MIT dual License. It is also quite fast; ~80% faster than the fastest mode of AES without cpu instruction set support. I will present a paper on a Turkish National Inet-tr 2015 Symposium on 3 December: It is a very simple and yet efficient logic. Anyone who looks at the self documented(in English) C code at http://ismail-kizir.blogspot.com/2015/11/hohha-dynamic-xor-algorithm-source-code.html may understand why and how it is unbreakable. I simply use the key as a jump table and, with every encrypted byte, I change the jump table(the key) as a result of 3-4 parameters including the last plaintext byte itself. Briefly, I encypt the plaintext with the key and also dynamically encrypt the key with the plaintext. The code is self documented in English. On Linux simply gcc HohhaDynamicXOR.c -O2 -Wall ./a.out will make integrity checks and print benchmarks. It is production ready. Other algorithm results are the output of the "openssl speed" command. If I am right; you will not be disappointed to include "Hohha Dynamic XOR Encryption Algorithm" on Linux Kernel. I will be glad to see my algorithm included in Linux distributions. Please feel free to ask if you have any questions. Regards Ismail Kizir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A new, fast and "unbreakable" encryption algorithm
Hello, I've developed a new encryption algorithm, which dynamically changes the key according to plaintext and practically impossible to break. I also opened to public with MIT dual License. It is also quite fast; ~80% faster than the fastest mode of AES without cpu instruction set support. I will present a paper on a Turkish National Inet-tr 2015 Symposium on 3 December: It is a very simple and yet efficient logic. Anyone who looks at the self documented(in English) C code at http://ismail-kizir.blogspot.com/2015/11/hohha-dynamic-xor-algorithm-source-code.html may understand why and how it is unbreakable. I simply use the key as a jump table and, with every encrypted byte, I change the jump table(the key) as a result of 3-4 parameters including the last plaintext byte itself. Briefly, I encypt the plaintext with the key and also dynamically encrypt the key with the plaintext. The code is self documented in English. On Linux simply gcc HohhaDynamicXOR.c -O2 -Wall ./a.out will make integrity checks and print benchmarks. It is production ready. Other algorithm results are the output of the "openssl speed" command. If I am right; you will not be disappointed to include "Hohha Dynamic XOR Encryption Algorithm" on Linux Kernel. I will be glad to see my algorithm included in Linux distributions. Please feel free to ask if you have any questions. Regards Ismail Kizir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/