Storing Cookies (See : http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm ) help us to bring you our services at overunity.com . If you use this website and our services you declare yourself okay with using cookies .More Infos here:
https://overunity.com/5553/privacy-policy/
If you do not agree with storing cookies, please LEAVE this website now. From the 25th of May 2018, every existing user has to accept the GDPR agreement at first login. If a user is unwilling to accept the GDPR, he should email us and request to erase his account. Many thanks for your understanding

User Menu

Custom Search

Author Topic: Let's crack Sloot algorithm - infinite "compression"  (Read 24935 times)

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #15 on: July 18, 2020, 12:37:58 AM »


Movie or file is series of numbers merged

123456789123456789123456789

Now you look into table and write coordinates

5
55
2
78
34
26

We know that first number is begin,
second number is end,
so you read coordinates in pairs of 2.

5, 55 = 12345
2, 78 = 678912345
34, 26 = 6789123456789

and merge sequence together again

123456789123456789123456789

and write it back into memory as it was at first place, in sequence.


So, number of coordinates are telling us how much sequence is long.

When there are no coordinates we are done, and vice versa.


No delimiter.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #16 on: July 18, 2020, 12:38:28 AM »
another detail worth mentionig is encoding side could do a lot of computation to find input variables that yield most matches for a particular file, so random is not really random but customized random.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #17 on: July 18, 2020, 12:44:13 AM »

Movie or file is series of numbers merged

123456789123456789123456789

Now you look into table and write coordinates

5
55
2
78
34
26

We know that first number is begin,
second number is end,
so you read coordinates in pairs of 2.

5, 55 = 12345
2, 78 = 678912345
34, 26 = 6789123456789

and merge sequence together again

123456789123456789123456789

and write it back into memory as it was at first place, in sequence.


So, number of coordinates are telling us how much sequence is long.

When there are no coordinates we are done, and vice versa.


No delimiter.

and how did you imagine using 1 digit coordinate, it cannot be 555, only 0555, otherwise coordinates would get mixed up.

as for spacer, again, coordinates are produced in different iterations, from different sets of random numbers, algorithm MUST know which iteration produced which coordinates, so spacer is needed

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #18 on: July 18, 2020, 12:46:51 AM »
The problem is because we think in decimal which is not suited for binary and numbers dont match.

We can write byte 255, but can not 999, because byte can not hold it.

Lets say that coordinates are max 2 numbers, 00 - 99 and you write it that way.

You have table 100 * 100,

6 coordinates are 12 numbers.

If we can write with 12 numbers 25 numbers, then the thing will work,

otherwise, hmm?


WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #19 on: July 18, 2020, 12:52:15 AM »
Yes, it must be 05, 55 and not 5, 55.

And we spend more memory, but delimiter is not needed.

Delimiter will be very hard to implement, if we dont know exact length of sequence.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #20 on: July 18, 2020, 12:55:55 AM »
u dont gain anything from going from 100 number table to 10,000 number table. everything just gets proportionally bigger, that is why i kept it at 100.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #21 on: July 18, 2020, 12:57:06 AM »
Yes, it must be 05, 55 and not 5, 55.

And we spend more memory, but delimiter is not needed.

Delimiter will be very hard to implement, if we dont know exact length of sequence.

how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #22 on: July 18, 2020, 01:00:02 AM »
I must say, you really got me into this problem!

But, it is good to talk and exercise our brains,

even if we dont find anything.

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #23 on: July 18, 2020, 01:07:18 AM »
how do you imagine decoder would know from which iteration to take which coordinates, if its not given that instruction. it needs a spacer


My thought was,



once we convert sequence into pairs of coordinates,

we read coordinates as number again and second iteration goes.

We write number of iterations into one long integer.



Can you try to explain how would you do it, just to see where I could be wrong?


Lets presume that we can write more numbers with coordinates than the number sequence really is.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #24 on: July 18, 2020, 01:17:43 AM »
this is my second time i am at it, like 10 months ago i was totally into it for few weeks, i started with idea of reducing big numbers to simpler formulas

for example 205891132095673 is equal to 2^10+3^30.

but this is a blind alley, no further reduction is possible. then i realized it can only be done with dynamic component on both sides parametrized the same way.

but this is nothing new, this april fool's joke video is about that https://www.youtube.com/watch?v=KOvoD1upTxM

not worthy going nuts over it, remember sloot was seeking for 20 years before he got it.

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #25 on: July 18, 2020, 01:21:15 AM »


You are very right,


this is not easy task, and it involves lots of brainstorming, for sure.

But is very interesting.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #26 on: July 18, 2020, 01:22:43 AM »

My thought was,



once we convert sequence into pairs of coordinates,

we read coordinates as number again and second iteration goes.

We write number of iterations into one long integer.



Can you try to explain how would you do it, just to see where I could be wrong?


Lets presume that we can write more numbers with coordinates than the number sequence really is.

its not about writing the number of iterations...like i said, look for decoder side, how will decoder know at which iteration to pick coordinates.

there is no way to avoid the spacer and this is where this idea dies.

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #27 on: July 18, 2020, 01:31:43 AM »
Damn,


It was starting to get fun!

WhatIsIt

  • Hero Member
  • *****
  • Posts: 651
    • At The End It Will Matter!
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #28 on: July 18, 2020, 01:41:42 AM »


Anyway, good topic Nix,



Regards.

nix85

  • Hero Member
  • *****
  • Posts: 1431
Re: Let's crack Sloot algorithm - infinite "compression"
« Reply #29 on: July 18, 2020, 01:46:21 AM »
yea, sooner or later someone will crack it. hopefully they'll share it, if not no prob, we got quite bandwidth these days