Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1283430 > unrolled thread

Re: A new, fast and "unbreakable" encryption algorithm

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A new, fast and "unbreakable" encryption algorithm Pavel Machek <pavel@ucw.cz> - 2015-12-03 23:40 +0100
    Re: A new, fast and "unbreakable" encryption algorithm Ismail Kizir <ikizir@gmail.com> - 2015-12-03 23:40 +0100
      Re: A new, fast and "unbreakable" encryption algorithm Clemens Ladisch <clemens@ladisch.de> - 2015-12-04 08:40 +0100
        Re: A new, fast and "unbreakable" encryption algorithm Ismail Kizir <ikizir@gmail.com> - 2015-12-04 10:50 +0100
          Re: A new, fast and "unbreakable" encryption algorithm Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-12-04 16:40 +0100

#1283430 — 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1283432

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 <pavel@ucw.cz> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283609

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283679

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 <clemens@ladisch.de> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283950

[Multipart message — attachments visible in raw view] — view raw

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 <clemens@ladisch.de> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web