Let's crack Sloot algorithm - infinite "compression"

[WhatIsIt]

something i thought of yesterday, not a solution, just a thought.

something like criss cross

Suppose for example that you have a table of 1 digit numbers 10 x 10. Once the random generator fills the table with first set of 100 numbers, you can now create 40 unique 10 digit sequences from these 100 just by reading first line from left to right then right to left, same for other 9 lines, then same vertically for all 10 columns, then you can add at least 30 diagonal lines containing ~10 digits on average

so we have aproximatelly 700 digit unique sequence and any sequence longer than 4 digits that cooresponds to source file within those 10 digit chunks can be addressed with just 4 digit coordinates, start and stop cell.

for example coordinates 5055 can address a 5 or 6 digit sequence

with multiple iterations sequence of coordinates would be generated that should be shorter than source string.

but it probably would not be, what are the chances 5 or more digit sequences from the source string would appear among 70 ~10 digit random numbers strings

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

just an idea. not such a good idea

he used a 70Mb library for each type of data. We do not know if that library contained just index of random numbers, or complex logic or both.

It is good idea actually.

If the table is big enough to cover most of possible number combinations, could work.

This way you can write even big numbers with just coordinates.


You are not far away from his idea.


In his 70Mb he probably had some kind of similar table for creating strings or sequences of numbers,

which are larger than pointers, vectors itself (coordinates in your case).

[WhatIsIt]

something i thought of yesterday, not a solution, just a thought.

something like criss cross

Suppose for example that you have a table of 1 digit numbers 10 x 10. Once the random generator fills the table with first set of 100 numbers, you can now create 40 unique 10 digit sequences from these 100 just by reading first line from left to right then right to left, same for other 9 lines, then same vertically for all 10 columns, then you can add at least 30 diagonal lines containing ~10 digits on average

so we have aproximatelly 700 digit unique sequence and any sequence longer than 4 digits that cooresponds to source file within those 10 digit chunks can be addressed with just 4 digit coordinates, start and stop cell.

for example coordinates 5055 can address a 5 or 6 digit sequence

with multiple iterations sequence of coordinates would be generated that should be shorter than source string.

but it probably would not be, what are the chances 5 or more digit sequences from the source string would appear among 70 ~10 digit random numbers strings

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

just an idea. not such a good idea

he used a 70Mb library for each type of data. We do not know if that library contained just index of random numbers, or complex logic or both.

And one more thing.


I know you showed example.

But in example are decimal numbers, so we need 10 symbols to cover.

What about same table with just binary 0 or 1. Lots of sequences.

Will that be simpler or more complicated?

[nix85]

It is good idea actually.

If the table is big enough to cover most of possible number combinations, could work.

This way you can write even big numbers with just coordinates.


You are not far away from his idea.


In his 70Mb he probably had some kind of similar table for creating strings or sequences of numbers,

which are larger than pointers, vectors itself (coordinates in your case).

i was just trying to be humble its a good idea, but i dont think it would work like that.

i was thinking also about big table and other data than single digit numbers, including ascii, just alphabet and the binary you mention. with binary i think it would be less efficient.

for example whole source file could be one gigantic table, and at each set of random numbers, algorithm would find all the sequences in the source table that match those in the random table and replace them with coordinates, but then u must place a spacer before and after coordinates and what is the gain then, u now got spacers in the output which cannot be removed unless u also memorized coordinates for them which cost a lot.

there is more to this, i think he used complex logic so reciever knows "what can and cannot be sent"...

or maybe library was really just index of random numbers and he found some clever way to address them apparently breaking the information entropy. but he clearly did not break it, he found a workaround.

[WhatIsIt]

also, problem with this is you must place a non-numerical separator so algorithm knows when set of random numbers changes, so output would not be pure shorter numbers, but would have these separators among them for each iteration but maybe it could memorize their location and remove them so pure number string can be further reduced

If you don't stop, separator, delimiter is not needed.

First coordinate, begin

Second coordinate, end sequence (2345)

Third coordinate, begin second sequence,

Fourth coordinate, end second sequence (12345),

But, actually you read it from memory as 234512345, as one sequence without delimiter,

just search in table for pieces which are longest to fill sequence.


You read it as continuous number, just as it is in memory.



You read memory from beginning till  the end as series of numbers merged together.

We know how long byte or integer is.


For example we have bytes

104

and

055

merge it, we know that byte is 3 places,

104055 and then search for best suited sequence to fill it from table,

I merged 2 bytes, but you can merge 100 bytes as continuous sequence and then look into table.


The whole movie is one big continuous number, sequence.

When you look memory with hex editor, there is number after number. You can look at it as one long number.


Then you don't need delimiter.

[nix85]

If you don't stop, separator, delimiter is not needed.

First coordinate, begin

Second coordinate, end sequence (2345)

Third coordinate, begin second sequence,

Fourth coordinate, end second sequence (12345),

But, actually you read it from memory as 234512345, as one sequence without delimiter,

just search in table for pieces which are longest to fill sequence.


You read it as continuous number, just as it is in memory.



You read memory from beginning till  the end as series of numbers merged together.

We know how long byte or integer is.


For example we have bytes

104

and

255

merge it, we know that byte is 3 places,

104255 and then search for best suited sequence to fill it from table,

I merged 2 bytes, but you can merge 100 bytes as continuous sequence and then look into table.


Then you don't need delimiter.

if you encode the source linearly, from beginning onward, you need a spacer, not all iterations of the 100 random numbers will yield same number of matches, some iterations will yield 10 pairs of coordinates, some none, and you must know when random numbers change.

in a case if you go about it non-linearly, turning the whole source file into a table, and for each set of 100 random numbers finding the matches across the whole source file and replacing them with coordinates ..you again need spacers (or something to replace them).


lets say after 10,000 iterations you have turned a whole source file into coordinates...

encoding algorithm could of course know which sequences have been replaced with coordinates at which iteration, but how would algorithm on decoding side know.

no way for it to know, it must know exactly at which iteration those coordinates where placed there.