Compression Idea #4

I've had a multitude of ideas, but recently i've decided to put one to the test.

I know yet again i drift from encryption, but this may be worth it.

I've considered the idea, that you take data, turn it into a puzzle with some redundancy, and then remove all the data you can, and compress the remainder that you can rebuild with. With this in mind i'm talking of something similar to Sudoku, although it may be more than 9x9, it may be more like 25x25 or something, too large for humans (shy of very very intelligent and bored people) doing. The exact method of this is uncertain as of yet. But i'll give you some information what i got so far.

1) I've successfully created a virtual sudoku environment, which works since it looks and feels like soduko, but can increase, but due to testing and building purposes can't go beyond the 9x9 yet.

2) I've programmed only one method (Called method1), which does the simplest of calculations and adds on the more obvious solutions, using this alone can solve puzzled rated easy, and maybe intermediate. I haven't fully tested, but the results were so astounding for a first run with no debugging i was surprised.

There are more methods to add, i think in the range of 4-5 more. When successfully able to do any puzzle on the go in seconds, the algorithm is ready for the next stages. Which i will outline now.

1) Build solver algorithm
2) Build converter from/to sudoku
3) Build number remover, which selectively removes numbers as many as it can, till it can do no more. (Expert level hopefully)
4) Experiment with compression until proper method is made that will hopefully compress the data down enough to compensate for the data, and make the whole venture worth it.

This is all going in hopes that the puzzle compressed is smaller then the original data was to build the puzzle in the first place. But with only one method, results for a solver (even if compression fails) will be promising enough to complete the project.

Era

OTP (One Time Pad) Improved!

I've done some major improvement on the program, and have a working windows GUI using AutoHotKeys. I may go away from this eventually, but i see no reason just yet.

A little history. Originally, the OTP was a simple RNG you could have multiple streams with and working. However it only returned 3Billion ints, and you could only seed it once.

New version, still in testing stages but has no problems so far, you can seed it as many ints as it's blocksize will let, and of course, the returnable INT's before it repeats or starts over is as this list shows.

Note, i am not sure if Decabyte is right, but it's the term i'm using.

k 2^10 (1024)
Mb 2^20 (1,048,576)
Gb 2^30 (1,073,741,824)
Tb 2^40 (1,099,511,627,776)
Pb 2^50 (1,125,899,906,842,624)

1 - 32 (256 bytes)
2 - 32,768 (32k)
3 - 12,582,912 (49,512k)
4 - 4,294,967,296 (16,384Mb)
5 - 1,374,389,534,720 (5,120 - Gigabytes)
6 - 422,212,465,065,984 (1,572,864 -Gigabytes)
7 - 126,100,789,566,373,888 (458,752 -Terabytes)
8 - 36,893,488,147,419,103,232 (134,217,728 -TeraBytes)
9 - 10,625,324,586,456,701,730,816 (38,654,705,664 -TeraBytes)
10 - 3,022,314,549,036,572,936,765,440 (10,995,116,277,760 -TeraBytes)
11 - 851,083,777,008,698,938,993,147,904 (3,023,656,976,384 -Petabytes)
12 - 237,684,487,542,793,012,780,631,851,008 (70,368,744,177,664 -Petabytes)
13 - 65,917,831,211,867,928,877,828,566,679,552 (234,187,180,623,265,792 -Petabytes)

These are figured characteristics, usually the returns are using 2xored returns, so it's half the values, but still more than enough for any normal message, probably enough to use on your drive to randomize it before you put a encrypted FS on it.

I will have more later.

Era