Weird compression idea... Probably dumb but...

[Poet129]

Why don't we compress and encrypt and repeat, other than the time it would take to do so?

If we have in binary a file like this:

10101010101010101010101010101010

and encrypt it let's say we get something like: (I know this wouldn't happen but... for example)

00000000000000000000000000000000

that compresses to

0^32

Then take the binary representation of that and repeat.

[AbydosOne]

4 minutes ago, Poet129 said:

Why don't we compress and encrypt and repeat, other than the time it would take to do so?

If we have in binary a file like this:

10101010101010101010101010101010

and encrypt it let's say we get something like: (I know this wouldn't happen but... for example)

00000000000000000000000000000000

that compresses to

0^32

Then take the binary representation of that and repeat.

Runs of zeros or ones were some of the first things to be compressed (because it's very simple).

 

Encryption by it's very nature tends towards near-random distributions of 0/1, so it's very hard to meaningfully compress encrypted data (basically, because you can't tell what can be left out because it's hidden).

[Radium_Angel]

6 minutes ago, Poet129 said:

Why don't we compress and encrypt and repeat, other than the time it would take to do so?

If we have in binary a file like this:

10101010101010101010101010101010

and encrypt it let's say we get something like: (I know this wouldn't happen but... for example)

00000000000000000000000000000000

that compresses to

0^32

Then take the binary representation of that and repeat.

http://www.personal-view.com/talks/discussion/3918/a-new-lossless-infinite-compression-algorithm

https://www.physicsforums.com/threads/limits-to-data-compression.968197/

 

[Poet129]

15 minutes ago, Radium_Angel said:

http://www.personal-view.com/talks/discussion/3918/a-new-lossless-infinite-compression-algorithm

So what if you add to the rule they talk about that instead of just the file contents getting measured you measure the contents plus what you have to add to tell which level/key you are on.

So like before we have:

10101010101010101010101010101010

It encrypts "randomly" with encryption key 1 to:

10101000010000100101000001000000 + 00110001

Let's assume that compressing it yielded no compression:

10101000010000100101000001000000 + 00110001

As such it would skip key 1 and move to key 2... so on till it has run through all keys.

[Radium_Angel]

1 minute ago, Poet129 said:

As such it would skip key 1 and move to key 2... so on till it has run through all keys.

Because that would be incredibly slow in uncompressing...

[Poet129]

1 minute ago, Radium_Angel said:

Because that would be incredibly slow in uncompressing...

I Mentioned this:

23 minutes ago, Poet129 said:

Why don't we compress and encrypt and repeat, other than the time it would take to do so?

So would it work with a set number keys say 256?

[WereCatf]

There are so many things wrong here it's mind-boggling.

29 minutes ago, Poet129 said:

00000000000000000000000000000000

that compresses to

0^32

Zero times zero is still zero, so 0^32 = 0.

29 minutes ago, Poet129 said:

Then take the binary representation of that

You still haven't grasped the difference between binary data and text-data. Me writing "01110010110010" isn't binary data, it's a text-string. Saving e.g. the value 65 as-is in a file would consume only one byte, whereas saving it as a text-string depicting its value in binary, e.g. "1000001" would take 7 bytes -- obviously, storing values as-is is the far better choice.

[Radium_Angel]

4 minutes ago, Poet129 said:

I Mentioned this:

So would it work with a set number keys say 256?

It might, but with only 256 options, it might be easily cracked. 

[Poet129]

Just now, WereCatf said:

Zero times zero is still zero, so 0^32 = 0.

I realize this it wasn't meant to be 0^32 but instead 32 zeros...

 

1 minute ago, WereCatf said:

You still haven't grasped the difference between binary data and text-data. Me writing "01110010110010" isn't binary data, it's a text-string. Saving e.g. the value 65 in a as-is in a file would consume only one byte, whereas saving it as a text-string depicting its value in binary, e.g. "1000001" would take 7 bytes -- obviously, storing values as-is is the far better choice.

So we run it through a converter that takes that binary value and stores the ASCII or some other encoder version of that data.

[Poet129]

1 minute ago, Radium_Angel said:

It might, but with only 256 options, it might be easily cracked. 

It isn't used for encryption just compression that was the only goal.

[WereCatf]

Just now, Poet129 said:

So we run it through a converter that takes that binary value and stores the ASCII

IT ALREADY IS ASCII.

[AbydosOne]

1 minute ago, Poet129 said:

takes that binary value and stores the ASCII

[Poet129]

1 minute ago, WereCatf said:

IT ALREADY IS ASCII.

I mean if you get 01000001 as data then convert it to 65 or whatever number equivalent. And store that.

[WereCatf]

Just now, Poet129 said:

I mean if you get 01000001 as data then convert it to 65 or whatever number equivalent. And store that.

That would only work for files that contain only the text-characters "1" and "0", ie. it'd be useless for 99.999999999999999% of all the world's files.

[Poet129]

1 minute ago, WereCatf said:

That would only work for files that contain only the text-characters "1" and "0", ie. it'd be useless for 99.999999999999999% of all the world's files.

We are reading the binary representation of a file remember, not the file contents.

[AbydosOne]

3 minutes ago, Poet129 said:

I mean if you get 01000001 as data then convert it to 65 or whatever number equivalent. And store that.

01000001 -> 65 -> "65" -> 00110110 00110101

Tad bit inefficient...

[WereCatf]

3 minutes ago, Poet129 said:

We are reading the binary representation of a file remember, not the file contents.

You keep repeating this. This "binary representation" is a TEXT-STRING, converting the value 65 to text only makes it take MORE space, not less. Then, converting that text back to a binary value..just gives you the original value, ie. 65!

 

The numeric value 65 is 65, regardless of whether you represent it as 65, 01000001, 0x41, which you don't grasp.

[Poet129]

Just now, AbydosOne said:

01000001 -> 65 -> "65" -> 00110110 00110101

Tad bit inefficient...

So you make your own encoding instead of ASCII... easy. That way it only encodes numbers.

[Poet129]

Just now, WereCatf said:

You keep repeating this. This "binary representation" is a TEXT-STRING, converting the value 65 to text only makes it take MORE space, not less. Then, converting that text back to a binary value..just gives you the original value, ie. 65!

This isn't the only thing we would be doing if you look to before... we are also:

 

22 minutes ago, Poet129 said:

10101010101010101010101010101010

It encrypts "randomly" with encryption key 1 to:

10101000010000100101000001000000 + 00110001

Let's assume that compressing it yielded no compression:

10101000010000100101000001000000 + 00110001

As such it would skip key 1 and move to key 2... so on till it has run through all keys.

Doing that.

[AbydosOne]

Just now, Poet129 said:

So you make your own encoding instead of ASCII... easy. That way it only encodes numbers.

I choose to encode my binary numbers in binary (fastest conversion, least overhead).

 

01000001 -> 65 -> "65" -> 65 -> 01000001

[WereCatf]

3 minutes ago, Poet129 said:

This isn't the only thing we would be doing if you look to before... we are also:

 

Doing that.

For the love of God, no.

[Poet129]

@AbydosOne

@WereCatf

Fine, I'll be back after I get it to work I'll make a video of it working along with comparisons like lastime. Feel free to give a few file examples however my main file will be this:

AMillionRandomDigits.bin

[WereCatf]

I am SO fricking frustrated right now. How can it be so difficult to understand the difference between a text-string and a numeric value?!

 

Someone, please, send me some strong vodka and some brain-bleach!

[AbydosOne]

A little more seriously: an encoding only maps existing groups of bits (0 or 1) to mean something in a formal fashion.

 

ASCII is a mapping of 8 bits to 127 textual characters, including 10 for decimal digits. Each one of those digits will take 8 bits to encode (somewhere in the 0x50 (0x = hex) range), even if the characters "decimal/human" value can only range from 0 to 9.

 

8 minutes ago, Poet129 said:

Fine, I'll be back after I get it to work I'll make a video of it working along with comparisons like lastime. Feel free to give a few file examples however my main file will be this:

That file is 415,241 bytes long, which is less than 1 million characters (ASCII bytes), and a lot more than 1 million bits. Even using BCD (four bits per number), you're not quite there. What does the file mean?

[Poet129]

2 minutes ago, AbydosOne said:

A little more seriously: an encoding only maps existing groups of bits (0 or 1) to mean something in a formal fashion.

 

ASCII is a mapping of 8 bits to 127 textual characters, including 10 for decimal digits. Each one of those digits will take 8 bits to encode (somewhere in the 0x50 (0x = hex) range), even if the characters "decimal/human" value can only range from 0 to 9.

 

That file is 415,241 bytes long, which is less than 1 million characters, and a lot more than 1 million bits. Even using BCD (four bits per number), you're not quite there. What does the file mean?

https://marknelson.us/posts/2006/06/20/million-digit-challenge.html