A visual puzzle...

[Chris M. Thomasson]

The goal: find the green in the sea of red.

the bitmaps are 1920x1080 dimensions.

warning, javascript must be enabled to download the actual bitmap
versions of the cheat sheet that shows the green, and the whole of the
sea of red. Unfortunately, Google+ does not separate the images with a
clear form of demarcation. Click on the green image on the left to see
it, and to download it click on arrow pointing down in the upper right:

https://plus.google.com/101799841244447089430/posts/NtH5sBDpy7H

Fwiw, here are the exact same bitmaps uploaded to imgup.net,
unfortunately the site converted them into jpegs:

https://k31i.imgup.net/ct_julia_mee4e.jpg

Here is the cipher image in all red, that contains the image in green:

https://g56i.imgup.net/ct_julia_mac11.jpg


Can you please try to pretend that the cheat sheet with the green pixels
somehow did not exist, and try to find it in the sea of red image?

Please, if you can do this I would be very happy indeed! It would give a
very interesting insight on how to crack non-escaping regions ot of a
sea of static that contains said encrypted region.

The cheat sheet visually shows the secret key in green pixels.

The ciphertext shows a sea of red containing the secret key.

Can you find the green out of the red, assuming the cheat sheet ever
existed?


I can share all the code one needs in order to recreate the bitmaps for
themselves. C++ code using the following bitmap lib:

http://easybmp.sourceforge.net

;^)

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
> The goal: find the green in the sea of red.
>
> the bitmaps are 1920x1080 dimensions.

YIKES!!!! What a boneheaded mistake. The damn bitmaps are 960x540!

Wow. Sorry for that. At least the ratios are the damn same:

540/960 = 0.5625
1080/1920 = 0.5625

Jesus help me!

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

> The goal: find the green in the sea of red.
>

[...]

> I can share all the code one needs in order to recreate the bitmaps for
> themselves. C++ code using the following bitmap lib:

Fwiw, I working on pure c99 code that creates a PPM of a key, in pretty
colors and cipher colors. Here is a start of my work on it, Mandelbrot
in ASCII:

https://groups.google.com/d/topic/comp.lang.c/yES5GDSbtlc/discussion

Ada will come after this. ;^)

God willing, it should be completed in a day or two. And, very portable!

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

> The goal: find the green in the sea of red.

Fwiw, here is some pure c99 code. ** Be warned **, the code creates an
output file called ct_ffe_cipher.ppm. Can you run and open the file in a
graphics editor? It works for me with the Gimp. This non-sense with the
hardcoded file name will change to gain data in the arguments from the
command line in my next iteration of the code. Sorry about the crude
state. ;^o

Anyway, the image is rendered with so-called "pretty" colors, the cipher
version, not shown here, makes garbage static. That version will be
completed fairly soon. Anyway, here is the naive first try c99 code, try
to open the resulting file: ct_ffe_cipher.ppm it creates, assuming that
somebody besides me can compile and run it:

Read all of for further context:

https://groups.google.com/d/topic/comp.lang.c/yES5GDSbtlc/discussion

Here is the latest iteration of my PPM fractal plotter code. This is in
pretty "cheat sheet" coloring. The cipher coloring version should be
complete tonight or tomorrow.
________________________
/* Chris M. Thomasson FFE Cipher Renderer ver:0.0.0.0 (pre-alpha)
5/2/2017 - Raw Experimental
_________________________________________________*/

#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>


void
ct_iterate_pixel(
FILE* fout,
double complex z,
double complex c,
unsigned int imax
){
//printf("z = %.1f%+.1fi\n", creal(z), cimag(z));

double o = 999999999999.0;

for (unsigned int i = 0; i < imax; ++i)
{
z = z * z + c;

double dis = cabs(z);

o = (o < dis) ? o : dis;

if (cabs(z) > 256.0)
{
double sum = (i + 1) * (i + .01) * 123U;
unsigned int red = sum;
fprintf(fout, "%u %u %u ", red % 256U, 0, 0);
return;
}
}

//double sum = fabs(creal(z)) + fabs(cimag(z) + o) * 1223456U;
double sum = (o + .01) * 256;
unsigned int red = ((unsigned int)sum) % 256U;

fprintf(fout, "%u %u %u ", 0, red % 256U, 0);

return;
}


void
ct_iterate_plane(
FILE* fout,
unsigned int width,
unsigned int height,
unsigned int imax
){
assert(width > 1 && height > 1);

char const ppm_head[] =
"P3\n"
"# Chris M. Thomasson FFE Cipher Renderer ver:0.0.0.0 (pre-alpha)";

printf("fout:%p\n", (void*)fout);

fprintf(fout, "%s\n%u %u\n%u\n", ppm_head, width, height, 255);

double xstep = 4.0 / (width - 1.0);
double ystep = 4.0 / (height - 1.0);

for (unsigned int y = 0; y < height; ++y)
{
for (unsigned int x = 0; x < width; ++x)
{
double complex z = (-2.0 + x * xstep) + I * (2.0 - y * ystep);

//printf("(%u, %u):z = %.1f%+.1fi\n", x, y, creal(z),
cimag(z));

ct_iterate_pixel(fout, z, z, imax);
}

printf("processing y:%u of %u\r", y + 1, height);
}

printf("\nrender complete!\n");
}


int main(void)
{
FILE* fout = fopen("ct_ffe_cipher.ppm", "w");
assert(fout != NULL);

ct_iterate_plane(fout, 1024, 1024, 128);

fclose(fout);

printf("\n\nFin, hit <ENTER> to exit...\n");
fflush(stdout);
getchar();

return 0;
}
________________________

This should be crap free. Can you spot any shi% in here?

Thanks. BTW, try to run it, and open the file it creates
ct_ffe_cipher.ppm in the Gimp or something. Can you do it?

Imvho, this program is going to be beneficial wrt people trying to crack
the puzzle: green from red, in cipher colors, not pretty... ;^)

[Chris M. Thomasson]

^^^^^^^^^^^^^^^^^^^^^^^
[...]

I have a redundant call to cabs here in the if condition. I can just use:

if (dis > 256.0)

I just fixed it in my code, but since it does not alter the main logic
of computing the fractal, its flagged as an inefficiency wrt being a
harmless "superfluous call".

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:
> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>> The goal: find the green in the sea of red.
>
> Fwiw, here is some pure c99 code. ** Be warned **, the code creates an
> output file called ct_ffe_cipher.ppm. Can you run and open the file in a
> graphics editor? It works for me with the Gimp. This non-sense with the
> hardcoded file name will change to gain data in the arguments from the
> command line in my next iteration of the code. Sorry about the crude
> state. ;^o
>
> Anyway, the image is rendered with so-called "pretty" colors, the cipher
> version, not shown here, makes garbage static. That version will be
> completed fairly soon. Anyway, here is the naive first try c99 code, try
> to open the resulting file: ct_ffe_cipher.ppm it creates, assuming that
> somebody besides me can compile and run it:
>
> Read all of for further context:
>
> https://groups.google.com/d/topic/comp.lang.c/yES5GDSbtlc/discussion
>
> Here is the latest iteration of my PPM fractal plotter code. This is in
> pretty "cheat sheet" coloring. The cipher coloring version should be
> complete tonight or tomorrow.

> [snip]

> This should be crap free. Can you spot any shi% in here?
>
> Thanks. BTW, try to run it, and open the file it creates
> ct_ffe_cipher.ppm in the Gimp or something. Can you do it?

Compiles, no warnings from gcc in -Wall mode.

Runs, generates a text mode ppm, which opens in xv and in gimp.

[Chris M. Thomasson]

Thank you for your time Rich! Now, in further iterations of my code, I
can show people exactly how to zoom in and break symmetry. The "cheat
sheet" for the main puzzle is in a symmetric region, hint! But, even so,
its still hard for me to try and get the green from the red wrt a cipher
coloring scheme. Humm.

Once I get the cipher coloring going, we can use the c99 code to
generate unique puzzles. We all can see how some keys are much better
than others.

Love c99! :^)

Thanks again.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:
> Thank you for your time Rich! Now, in further iterations of my code,
> I can show people exactly how to zoom in and break symmetry. The
> "cheat sheet" for the main puzzle is in a symmetric region, hint!
> But, even so, its still hard for me to try and get the green from the
> red wrt a cipher coloring scheme. Humm.

There is a big difference in how you output the green vs. the red. The
red is quite bandy, the green area is much smoother. And if you
magnify the edge between the red and green areas, at least in this
color output, there looks to be a difference in "smoothness" at the
red/green boundary that might be useful to find the green area (or find
the red area). This of course assumes that code which generated an
"all red" image had the same difference in computing the red shades
that the red/green generator does.

I.e., changing this:

fprintf(fout, "%u %u %u ", 0, red % 256U, 0);

to this

fprintf(fout, "%u %u %u ", red % 256U, 0, 0);

Note, you might consider naming the variable "green" here, as it is
outputting on the green channel in your code. If I make that change
and generate an "all red" image, then magnifying that image and
comparing it to the red/green image, there is possibly an "edge" in the
transition from "harsh edge red" to "smooth edge red" that might
suggest that much of the "green" area might be findable with some kind
of image processing code that evaluated differences in color gradient
smoothness.

> Once I get the cipher coloring going, we can use the c99 code to
> generate unique puzzles. We all can see how some keys are much
> better than others.

I also wonder why you bother with this:

printf("\n\nFin, hit <ENTER> to exit...\n");
fflush(stdout);
getchar();

Why not just exit when done? Why the prompt for hitting enter, just to
exit?


Also, here's a Makefile for your C code:

ffe: ffe.c
gcc -Wall -o ffe --std=c99 -lm ffe.c

Note that the indentation before gcc must be an actual ASCII tab.

[austin...@hotmail.com]

Hi Chris ,

Proposition: You create the methodology of resolving bitmaps and all other formats into pixel maps that give the RGB ratio for each pixel and I will encrypt the entire string of colour ratios in a split second.

I am planning to do this myself sometime in the future but together we would make a great team - AOB

[Chris M. Thomasson]

On 5/2/2017 6:59 PM, Rich wrote:
> Chris M. Thomasson <inv...@invalid.invalid> wrote:
>> Thank you for your time Rich! Now, in further iterations of my code,
>> I can show people exactly how to zoom in and break symmetry. The
>> "cheat sheet" for the main puzzle is in a symmetric region, hint!
>> But, even so, its still hard for me to try and get the green from the
>> red wrt a cipher coloring scheme. Humm.
>
> There is a big difference in how you output the green vs. the red. The
> red is quite bandy, the green area is much smoother.

You are right on this. We can easily see the Mandelbrot set because the
"nature" of the coloring is very different than the red. This code
creates so-called "pretty" colors, instead of the static cipher garbage
ones. I am almost finished with the code that creates the static
renderings in c99. I will put it up on GitHub.

The red bands that you noticed are actually the equipotential lines of
the set. If one draws lines that are perpendicular to these bands, the
actual field lines would be visible. The red bands converge right down
to the actual set in green. Understanding these images in pretty colors,
can perhaps help us crack the green from the red in the cipher static
coloring.

> And if you
> magnify the edge between the red and green areas, at least in this
> color output, there looks to be a difference in "smoothness" at the
> red/green boundary that might be useful to find the green area (or find
> the red area). This of course assumes that code which generated an
> "all red" image had the same difference in computing the red shades
> that the red/green generator does.

The deep study of the border of the fractal is going to be key in
cracking this thing. I think the more we take a look at the image
rendered by the code as-is, we will be that much closer to cracking the
cipher images.

>
> I.e., changing this:
>
> fprintf(fout, "%u %u %u ", 0, red % 256U, 0);
>
> to this
>
> fprintf(fout, "%u %u %u ", red % 256U, 0, 0);
>
> Note, you might consider naming the variable "green" here, as it is
> outputting on the green channel in your code. If I make that change
> and generate an "all red" image, then magnifying that image and
> comparing it to the red/green image, there is possibly an "edge" in the
> transition from "harsh edge red" to "smooth edge red" that might
> suggest that much of the "green" area might be findable with some kind
> of image processing code that evaluated differences in color gradient
> smoothness.

Will change the color channel variable name to green. The green is
definitely able to be located in this code. The pretty colors show that
off quite nicely. Even in all red, the border is visible. My job is to
"hide that fact". The next iteration of the code try to do just that.
Its going to be using some techniques in my crappy little so-called
tutorial on FFE.

>> Once I get the cipher coloring going, we can use the c99 code to
>> generate unique puzzles. We all can see how some keys are much
>> better than others.
>
>
> I also wonder why you bother with this:
>
> printf("\n\nFin, hit <ENTER> to exit...\n");
> fflush(stdout);
> getchar();
>
> Why not just exit when done? Why the prompt for hitting enter, just to
> exit?

Actually, I have no good excuse for this. I use a lot of MSVC and for
some reason if you do not add a getchar, the command window pops up,
your code runs, and then the window gets destroyed. I cannot examine the
damn output. So, this is a habit of mine to get around that. Sorry.

> Also, here's a Makefile for your C code:
>
> ffe: ffe.c
> gcc -Wall -o ffe --std=c99 -lm ffe.c
>
> Note that the indentation before gcc must be an actual ASCII tab.
>

Thank you!

[Richard Heathfield]

On 03/05/17 23:24, Chris M. Thomasson wrote:
> On 5/2/2017 6:59 PM, Rich wrote:

<snip>

>>
>> I also wonder why you bother with this:
>>
>> printf("\n\nFin, hit <ENTER> to exit...\n");
>> fflush(stdout);
>> getchar();
>>
>> Why not just exit when done? Why the prompt for hitting enter, just to
>> exit?
>
> Actually, I have no good excuse for this. I use a lot of MSVC and for
> some reason if you do not add a getchar, the command window pops up,
> your code runs, and then the window gets destroyed. I cannot examine the
> damn output. So, this is a habit of mine to get around that. Sorry.

Run the program from the command line instead of via the IDE, and the
problem vanishes into the complex swirls of fractal mist. A simple
Alt-Tab suffices to switch between your console window and your IDE.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

> The goal: find the green in the sea of red.

[...]

Fwiw, here is a link to a new version of my renderder that outputs a
cheat sheet in actual static garbage cipher colors:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c

Fwiw, here is link to output wrt converting the generated ppm to a jpg
in Gimp:

https://t83i.imgup.net/ct_ffe_cipafc8.jpg

Now, this program is currently hard coded to axes.

xmin: -2, xmax: 2
ymin -2, ymax: 2

So it has perfect symmetry! This aspect will be user definable as part
of the secret key in further iterations of the code. However, for now,
try to exploit this to crack the green out of the red. If you want to
see all red, simply change line 61 from:

fprintf(fout, "%u %u %u ", 0, green % 256U, 0);

to:

fprintf(fout, "%u %u %u ", green % 256U, 0, 0);

This call to fprintf outputs a pixels RGB color.

Will upload a makefile. Rich, thank you for that.

Sorry for the incremental state of the updates to my code. However, I
think it can be beneficial in a sense because we can all see and run the
progress?

Thank you all. Btw, I got rid of that hyper annoying prompt that tells
people that the program is finished. ;^)

[Chris M. Thomasson]

On 5/3/2017 5:59 AM, austin...@hotmail.com wrote:
> On Tuesday, May 2, 2017 at 11:13:47 PM UTC+1, Chris M. Thomasson wrote:
>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>>> The goal: find the green in the sea of red.

[...]

> Proposition: You create the methodology of resolving bitmaps and all
> other formats into pixel maps that give the RGB ratio for each pixel and
> I will encrypt the entire string of colour ratios in a split second.

Well, we can take an existing bitmap and create a PPM. Wrt my software,
just encrypt the PPM that the program natively outputs. Its all text and
has every single pixels color RGB in range of 0...255 . Take a look at:

http://netpbm.sourceforge.net/doc/ppm.html

Your program can definitely handle that.

Now, are you saying to want me to code a universal way to convert any
image format into a PPM?

> I am planning to do this myself sometime in the future but together we
> would make a great team

The program I wrote can supply you with "endless" text ppm's for sure.
Also, when I am finished with my c99 FFE implementation adventure, an
ADA version will be provided for sure.

[Rich]

Hense the reason why I don't use an IDE, and run code directly from the
command line prompt when developing. None of these stupid things
happen when one develops in that fashion.

[Chris M. Thomasson]

Agreed. I got rid of that total non-sense here:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c

[Chris M. Thomasson]

On 5/3/2017 3:35 PM, Richard Heathfield wrote:
> On 03/05/17 23:24, Chris M. Thomasson wrote:
>> On 5/2/2017 6:59 PM, Rich wrote:
> <snip>
>>>
>>> I also wonder why you bother with this:
>>>
>>> printf("\n\nFin, hit <ENTER> to exit...\n");
>>> fflush(stdout);
>>> getchar();
>>>
>>> Why not just exit when done? Why the prompt for hitting enter, just to
>>> exit?
>>
>> Actually, I have no good excuse for this. I use a lot of MSVC and for
>> some reason if you do not add a getchar, the command window pops up,
>> your code runs, and then the window gets destroyed. I cannot examine the
>> damn output. So, this is a habit of mine to get around that. Sorry.
>
> Run the program from the command line instead of via the IDE, and the
> problem vanishes into the complex swirls of fractal mist. A simple
> Alt-Tab suffices to switch between your console window and your IDE.

Agreed. Unfortunately, I have seem to have developed some sort of
addiction to MSVC in the past couple of years. A lot of windows work.

[Richard Heathfield]

On 04/05/17 00:31, Rich wrote:

<snip>

> Hense the reason why I don't use an IDE

I do. It's called Linux. :-)

[Chris M. Thomasson]

On 5/3/2017 4:59 PM, Richard Heathfield wrote:
> On 04/05/17 00:31, Rich wrote:
>
> <snip>
>
>> Hense the reason why I don't use an IDE
>
> I do. It's called Linux. :-)

I remember using an IDE called Anjuta while on Linux. On Solaris I used
NetBeans...

http://anjuta.org

IIRC, it created makefiles. ;^)

[Richard Heathfield]

On 04/05/17 01:10, Chris M. Thomasson wrote:
> On 5/3/2017 4:59 PM, Richard Heathfield wrote:
>> On 04/05/17 00:31, Rich wrote:
>>
>> <snip>
>>
>>> Hense the reason why I don't use an IDE
>>
>> I do. It's called Linux. :-)
>
> I remember using an IDE called Anjuta while on Linux. On Solaris I used
> NetBeans...

whoosh...

>
> http://anjuta.org
>
> IIRC, it created makefiles. ;^)

I've never liked other people's auto-generated makefiles, so I wrote my
own makefile generator, which does exactly what I want it to do -
nothing more, nothing less.

[Chris M. Thomasson]

On 5/3/2017 5:29 PM, Richard Heathfield wrote:
> On 04/05/17 01:10, Chris M. Thomasson wrote:
>> On 5/3/2017 4:59 PM, Richard Heathfield wrote:
>>> On 04/05/17 00:31, Rich wrote:
>>>
>>> <snip>
>>>
>>>> Hense the reason why I don't use an IDE
>>>
>>> I do. It's called Linux. :-)
>>
>> I remember using an IDE called Anjuta while on Linux. On Solaris I used
>> NetBeans...
>
> whoosh...

I hope you did not just flush me down the proverbial toilet!

Yikes! I know how to use the command line.

>
>>
>> http://anjuta.org
>>
>> IIRC, it created makefiles. ;^)
>
> I've never liked other people's auto-generated makefiles, so I wrote my
> own makefile generator, which does exactly what I want it to do -
> nothing more, nothing less.

Typically, the makefiles generated by the IDE's are cryptic and bloated.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>> The goal: find the green in the sea of red.
> [...]
>
> Fwiw, here is a link to a new version of my renderder that outputs a
> cheat sheet in actual static garbage cipher colors:
>
> https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c
>
> Fwiw, here is link to output wrt converting the generated ppm to a jpg
> in Gimp:
>
> https://t83i.imgup.net/ct_ffe_cipafc8.jpg
>
> Now, this program is currently hard coded to axes.
>
> xmin: -2, xmax: 2
> ymin -2, ymax: 2
>
> So it has perfect symmetry! This aspect will be user definable as part
> of the secret key in further iterations of the code. However, for now,
> try to exploit this to crack the green out of the red. If you want to
> see all red, simply change line 61 from:
>
> fprintf(fout, "%u %u %u ", 0, green % 256U, 0);
>
> to:
>
> fprintf(fout, "%u %u %u ", green % 256U, 0, 0);

At the bottom of this is a base85 (also known as ascii85) encoded
gzipped file that is a diff patch against your github source. It adds
a command line parameter to toggle between red and green modes and
changes the fixed output filename to be appropriate per mode.

You should be able to decode with python's base64.a85decode or
base64.b85decode functions.

You should get a gzip file that has this sha256 hash:

b9eefbf8d1c7be1589e72067ed8875bf1de25a9a0f8a3367ccb84adf4ca0ebb7

> Sorry for the incremental state of the updates to my code. However, I
> think it can be beneficial in a sense because we can all see and run the
> progress?

Code that is undergoing development often incrementally changes, no big
deal there.

> Thank you all. Btw, I got rid of that hyper annoying prompt that tells
> people that the program is finished. ;^)

Yeah, I noticed...



+,^C1(53)u!!?bGAnEZ-Bl%>\X]41rRkPD&*e2-\;^s2W!%I!Leu:<l1o]25T@PG8`.0]HaI"l"e
c1&1)\P]*Wfr/KfOs+)qnB\KD;,WBA/("17["@Sj%aI3\"*hMm_TDKrm`D&4=?MAEt<*Mb&K8e1m
Q83m`B"uqP1k#Xuq1tSMe#tDSQa`.@>ZDK:<eh51)L8l8=,G@9!oZ8*SX.0e,(m7^bffSnp`b$DX
_k#BRl9X.m[g]k:n5:F(MrF^EH@-YoA8f-''G(=J*(l_7]s"EHj6kflPL';l.64PtYDI_19CW4A`
5NCOX(4InB#Q=^MGpK4)XE3#BSc'GXC(/UjHj"d^%#pU_I^j&m-N5m78iNYRkJnl3`gj!MlLYh1r
$R/'W9Reg:KQ%6XN6b%!ORf<8l[nBI/U+LueV%/W)oRWO<Md/1#+1CD"8"'T)&p0PHR07r\/'+nQ
D`IeCkttU379"E,b#@Q&iY36\1ecNTO'lINn#+("O@VHd"$rG!KiZs@9p,-pas!#/-RC9V_RBu_$
tWi.q_1ef)@[Sl1Y6)X%<8D/sUX2T;V6(l<HH1n=&I+JJVGh;bpBc1jH($Hc^]3CS%,$8-r!grr5
Vqh#P#K(VYJ/(Dk>!@^`K$\M&cKNe9R46oha&Tg/0XD4t4Si^BPX/_HV2(V>T\Pta8I+XbHrDFrD
ij%6t:=KD>2*NVI)[]t.h'2QfHA48nd$84-d/MR,lN3)FbZIiT`\Q5I;iWs[3a1#:aol2"qo;+\b
<O5+@2Bg?<LOuZ<c.pXa+Cn&s18H(Gb=aR:0Jk=W]3coEQ7,@glN:[S\,K9jmAMQp(s_&Zd#.?Sc
03;Q9q$4+GeBB<9rT's/'&+,$+"FqasN(("Y2]nk.jo#X=NWDTNl:arZ(c7KFHJai/'L/cpZg,gt
rs,c,b3=LioWEbH7WViEQZB&!7ZQk@&"4M&`gIbX1aMpR8&c8iVW@7c&-[Li%ri,bj'?V*&fnS9@
8k4X]naOYbtQ-E5a<Emr'Epj%(1H`6s^)/!AQRPK%,mqVmqB!"bqgO5ge<?uRK'pWg&`kNMo.k-8
[!!!

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

Which is the trouble with IDE's. You get addicted, and soon, you can't
survive without your fix.

Granted it is made infinitely worse by winblows atrocious handling of
any form of command line usage.

[Rich]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 04/05/17 00:31, Rich wrote:
>
> <snip>
>
>> Hense the reason why I don't use an IDE
>
> I do. It's called Linux. :-)

Fair point. One could consider Linux an IDE. I had not thought of it
that way, but it is nicely "integrated" and it is a "development
environment".

I was, as you likely realize, thinking atrocities such as Eclipse when
I typed out "IDE" above.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

On Linux you use a bash window and a text file editor. No need for
those awful crutches that so many rely upon.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> On 5/3/2017 5:29 PM, Richard Heathfield wrote:
>> On 04/05/17 01:10, Chris M. Thomasson wrote:
>>> http://anjuta.org
>>>
>>> IIRC, it created makefiles. ;^)

The very basic Makefile syntax is simple enough that for the simple
cases (which will handle a wide swatch of needs) Makefiles are easy
enough to hand create.

>> I've never liked other people's auto-generated makefiles, so I wrote
>> my own makefile generator, which does exactly what I want it to do -
>> nothing more, nothing less.
>
> Typically, the makefiles generated by the IDE's are cryptic and bloated.

Sadly, that is true of much 'auto-generated' code created by a generic
generator vs. one's own hand tuned generator or hand written code.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> On 5/3/2017 5:59 AM, austin...@hotmail.com wrote:
>> On Tuesday, May 2, 2017 at 11:13:47 PM UTC+1, Chris M. Thomasson wrote:
>>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>>>> The goal: find the green in the sea of red.
> [...]
>> Proposition: You create the methodology of resolving bitmaps and all
>> other formats into pixel maps that give the RGB ratio for each pixel and
>> I will encrypt the entire string of colour ratios in a split second.
>
> Well, we can take an existing bitmap and create a PPM. Wrt my software,
> just encrypt the PPM that the program natively outputs. Its all text and
> has every single pixels color RGB in range of 0...255 . Take a look at:
>
> http://netpbm.sourceforge.net/doc/ppm.html
>
> Your program can definitely handle that.

There are no characters that his program can't handle, yes.

However, one of your images is 8,985,652 characters long. That is
89.86 times larger than his hard coded limit of 100,000 characters.

It is also long enough that his keystream will repeat itself about 31.8
times if he were to learn how to get past his 100,000 character hard
coded limit.

So I predict that if you put an image on github, and post the url to
the "raw" version here for him, he will dream up some fantasy where he
is not going to encrypt it for you due to workload or some other BS.

[Chris M. Thomasson]

On 5/3/2017 6:49 PM, Rich wrote:
> Chris M. Thomasson <inv...@invalid.invalid> wrote:
>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

[...]

> At the bottom of this is a base85 (also known as ascii85) encoded
> gzipped file that is a diff patch against your github source. It adds
> a command line parameter to toggle between red and green modes and
> changes the fixed output filename to be appropriate per mode.
>
> You should be able to decode with python's base64.a85decode or
> base64.b85decode functions.
>
> You should get a gzip file that has this sha256 hash:
>
> b9eefbf8d1c7be1589e72067ed8875bf1de25a9a0f8a3367ccb84adf4ca0ebb7

I got it. Created the following stupid simple Python program, and it works:
_______________________
import base64;

f = open("encode.txt", "rb")
bytes = f.read();
f.close();

print(bytes);

decode = base64.a85decode(bytes);

print("_________________________________________");
print("decode:%s" % (decode));

f = open("decode.zip", "wb")
f.write(decode);
f.close();
_______________________

On cygwin using sha256sum I get
_______________________
$ sha256sum decode.zip
b9eefbf8d1c7be1589e72067ed8875bf1de25a9a0f8a3367ccb84adf4ca0ebb7
*decode.zip
_______________________

That perfectly matches your hash. The first two lines in the diff.file are:
_______________________
--- ffe.c.orig 2017-05-03 21:16:54.662068292 -0400
+++ ffe.c 2017-05-03 21:33:15.652425978 -0400
_______________________

Thank you Rich. I will have more time to work on this tomorrow.

>> Sorry for the incremental state of the updates to my code. However, I
>> think it can be beneficial in a sense because we can all see and run the
>> progress?
>
> Code that is undergoing development often incrementally changes, no big
> deal there.
>
>> Thank you all. Btw, I got rid of that hyper annoying prompt that tells
>> people that the program is finished. ;^)
>
> Yeah, I noticed...

;^D

[...]

[austin...@hotmail.com]

Many thanks Chris - putting this on the back burner for a few days - this hugely reduces the task of encrypting images.

Good luck one more with your farctal crypto. - Austin

[Richard Heathfield]

On 04/05/17 05:55, austin...@hotmail.com wrote:
> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
> wrote:

<snip>

>> The program I wrote can supply you with "endless" text ppm's for
>> sure. Also, when I am finished with my c99 FFE implementation
>> adventure, an ADA version will be provided for sure.
>
> Many thanks Chris - putting this on the back burner for a few days -
> this hugely reduces the task of encrypting images.

Actually, it *increases* the workload.

Consider encryption of an image in the usual way:

1) encrypt the image.

That's it. You now have an encrypted image. Decryption? Easy:

1) decrypt the image.

That's it. You now have the original image again.

Now consider encryption of an image in the VeeCrypt way:

1) convert the image to a text format, using either Chris's program or
the GIMP or ImageMagick (`identify -list format` will give you a few
ideas on possible formats);

2) make a careful note of all characters not in the range 32-126 and
their exact positions in the converted file and then, just to be sure,
you'd better delete them;

3) if the resulting file is too big for VeeCrypt, split it into chunks;

4) encrypt the file (or files), praying that the encryption process
doesn't crash;

You now have an encrypted image. Decryption? Hard:

1) decrypt the file or files, giving you the textual data but without
any characters such as tabs and newlines, and praying that the process
doesn't crash;

2) if you had multiple files, stitch them all back together;

3) re-insert the tabs and newlines in exactly the right places;

4) convert the image back to the original format, using either Chris's
program or the GIMP or ImageMagick.

That's it. You *might* now have the original image again.


No, Austin. It doesn't save /any/ work. It's a huge waste of time.

Let's just pretend that our threat model is so ludicrously low (e.g.
Bruce Schneier's "kid sister" model) that we would be prepared to
entertain the idea of using a home-brew cipher - but let's also
recognise that our friends have limited patience.

Scenario:

Alice wants to buy a painting for a friend, Carol, as a birthday gift,
but she's not sure whether Carol would like it, and she wishes to
consult Carol's techno-savvy husband, Bob, so that he can give Alice an
informed opinion on whether Carol would like the gift. (Carol is, in a
sense, Eve, but any eavesdropping would be entirely accidental - this is
a VERY low threat model!).

Since Bob and Carol live on another continent, it's not practical to
invite them to tea. So Alice wishes to email the photograph (2325500
bytes). It must, therefore, be encrypted (to reduce the risk that Carol
will see the photograph accidentally and have her birthday surprise
spoiled).

What must Alice and Bob do to complete this task?

1. Agree on a cryptosystem and install it locally.

2. Agree on a key.

3. (Alice) C = E(P)

4. (Alice) Email C to Bob.

5. (Bob) P = D(C)


Alice and Bob consider two cryptosystems, CDX-3 (a fine example of an
insecure home-brew cipher) and your own VeeCrypt.

Step | CDX-3 | VeeCrypt
-----+---------------------------+-----------------------------
1 | store the two C files | wait for AOB to craft
| locally, type make, type | a mutually synchronised
| sudo make install | database (lead time: weeks);
| | install an Ada compiler and
| | IDE onto the system; install
| | VeeCrypt; learn how to use
| | the IDE
| |
| Maybe 5 minutes tops (but | weeks and weeks, might never
| more likely 30 seconds) | get it
-----+---------------------------+-----------------------------
2 | Think of an 8-letter word | select cipher variant,
| | select scrambling parameters,
| | communicate these to Bob
| |
| 2 seconds | several minutes
-----+---------------------------+-----------------------------
3 | encrypt the file | convert to a text format;
| | split into multiple files
| | of 100KB max size (after
| | conversion to text, this took
| | 95 files!);
| | store the position of every
| | single tab and newline in
| | every file;
| | encrypt every file
| |
| 0.652 seconds (I timed it)| several hours
-----+---------------------------+-----------------------------
4 | 2MB file, so one email | some email systems will reject
| | anything over 5MB, so we're
| | looking at two emails
| |
-----+---------------------------+-----------------------------
5 | decrypt the file | decrypt each of the 95 files;
| | restore every tab and newline;
| | re-join all the text files into
| | one;
| | convert back to image format
| |
| 0.664 seconds (I timed it)| several hours
-----+---------------------------+-----------------------------


What is the total time investment for Alice and Bob?

CDX: some time between one minute and ten minutes - twenty including
coffee break.

VeeCrypt: several weeks of waiting, and several hours of pains-taking,
error-prone, detailed editing.

If those were the only choices, which do you think any /sane/ person
would choose?

CDX is crap. It really is. It sucks. Nobody in their right mind would
use it to protect any serious secret. It does have the redeeming feature
that it's proving to be quite resistant to such cryptanalysis as it is
receiving - that is, it's an interesting puzzle.

Nevertheless, CDX is crap, and it sucks.

BUT it's more secure, faster, and much more convenient to use than VeeCrypt.

Austin, you need to get your cipher up to /at least/ CDX standard before
you even /think/ about telling anyone else about it, because right now
they have no incentive whatsoever to even /look/ at your cipher. It
isn't even much of a puzzle!

[Rich]

austin...@hotmail.com wrote:
> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson wrote:
>> On 5/3/2017 5:59 AM, austin...@hotmail.com wrote:
>> Well, we can take an existing bitmap and create a PPM. Wrt my software,
>> just encrypt the PPM that the program natively outputs. Its all text and
>> has every single pixels color RGB in range of 0...255 . Take a look at:
>>
>> http://netpbm.sourceforge.net/doc/ppm.html
>>
>> Your program can definitely handle that.
>>

>> ...

>>
>> The program I wrote can supply you with "endless" text ppm's for sure.
>> Also, when I am finished with my c99 FFE implementation adventure, an
>> ADA version will be provided for sure.
>
> Many thanks Chris - putting this on the back burner for a few days -
> this hugely reduces the task of encrypting images.

Not for you. The size of these ASCII encoded images is about 80x the
maximum size you seem to set for your programming code. And as you
seem incapable of learning how to encrypt any arbitrary size it means
that encrypting images will continue to be well outside of your reach.

[Keegan Major]

Richard Heathfield <r...@cpax.org.uk> wrote:
> On 04/05/17 05:55, austin...@hotmail.com wrote:
>> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
>> wrote:
>
> <snip>
>
>>> The program I wrote can supply you with "endless" text ppm's for
>>> sure. Also, when I am finished with my c99 FFE implementation
>>> adventure, an ADA version will be provided for sure.
>>
>> Many thanks Chris - putting this on the back burner for a few days -
>> this hugely reduces the task of encrypting images.
>
> Actually, it *increases* the workload.
>

> Alice and Bob consider two cryptosystems, CDX-3 (a fine example of an
> insecure home-brew cipher) and your own VeeCrypt.
>

> <snip>

>
> What is the total time investment for Alice and Bob?
>
> CDX: some time between one minute and ten minutes - twenty including
> coffee break.
>
> VeeCrypt: several weeks of waiting, and several hours of pains-taking,
> error-prone, detailed editing.
>
> If those were the only choices, which do you think any /sane/ person
> would choose?

Based upon the excellent comparison provided in the prior article, if the
only two options were CDX and VeeCrypt, I for one would *never* choose to
use VeeCrypt. That is just too much work and effort for an activity that
should be simple and almost transparent.

> Austin, you need to get your cipher up to /at least/ CDX standard before
> you even /think/ about telling anyone else about it, because right now
> they have no incentive whatsoever to even /look/ at your cipher. It isn't
> even much of a puzzle!

Hear hear!! Austin, you need to create something that is, at a minimum, at
least as easy to use as CDX's description in the prior article before you
even consider informing the world you have created anything.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:
> On 5/3/2017 6:49 PM, Rich wrote:
>> Chris M. Thomasson <inv...@invalid.invalid> wrote:
>>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
> [...]
>> At the bottom of this is a base85 (also known as ascii85) encoded
>> gzipped file that is a diff patch against your github source. It adds
>> a command line parameter to toggle between red and green modes and
>> changes the fixed output filename to be appropriate per mode.
>>
>> You should be able to decode with python's base64.a85decode or
>> base64.b85decode functions.
>>
>> You should get a gzip file that has this sha256 hash:
>>
>> b9eefbf8d1c7be1589e72067ed8875bf1de25a9a0f8a3367ccb84adf4ca0ebb7
>

> On cygwin using sha256sum I get
> _______________________
> $ sha256sum decode.zip
> b9eefbf8d1c7be1589e72067ed8875bf1de25a9a0f8a3367ccb84adf4ca0ebb7
> *decode.zip
> _______________________

That means you were able to independently verify that the bytes you
received are the same set of bytes that left my computer here.

A feat that Austin O'Byrne has yet to show himself capable of
performing in any way.

FWIW I picked the base85/ascii85 encoding this time because I
discovered that python had a decoder built in already (and I know you
use python) and because it has an expansion ratio of four bytes in,
five bytes out.

> _______________________
> --- ffe.c.orig 2017-05-03 21:16:54.662068292 -0400
> +++ ffe.c 2017-05-03 21:33:15.652425978 -0400
> _______________________
>
> Thank you Rich. I will have more time to work on this tomorrow.

Yep. And if you still have the same copy of ffe.c that I edited, you
can use "patch -p1 < decode" to apply the patch to ffe.c automatically.

[Chris M. Thomasson]

On 5/3/2017 6:57 PM, Rich wrote:
> Chris M. Thomasson <inv...@invalid.invalid> wrote:
>> On 5/3/2017 5:29 PM, Richard Heathfield wrote:
>>> On 04/05/17 01:10, Chris M. Thomasson wrote:
>>>> http://anjuta.org
>>>>
>>>> IIRC, it created makefiles. ;^)
>
> The very basic Makefile syntax is simple enough that for the simple
> cases (which will handle a wide swatch of needs) Makefiles are easy
> enough to hand create.

Oh yeah. I kind of remember an accidental use of spaces instead of tabs
in a makefile I created and wondered why I had a problem for around 15
minutes! Wow. I managed to forget that I used spaces. The tab is all
important.

[Chris M. Thomasson]

On 5/4/2017 2:59 AM, Richard Heathfield wrote:
> On 04/05/17 05:55, austin...@hotmail.com wrote:
>> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
>> wrote:

[...]

Can you please email me your CDX? I need to learn from it.

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

> The goal: find the green in the sea of red.
[...]

Fwiw, a list of all the const numbers in my program:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/ffe.c

did I miss one?
__________________________________
3.14592653
1.61803
3049213.103
1.314
999999999999.0
65536.0
120303U
256U *** mod into bytes
0
4.0
1 and/or 1.0
-2.0
2.0
1024
128
__________________________________

All, except the mod 256 into byte range can be part of the secret key.
The next iteration of the code will have Rich's addition, along with a
secret key text file that can be passed into the program via command
line. Still drafting this out wrt the c99 code.

In the mean time, try experimenting with tweaking the numbers and the
images they render, might help in cracking the green out of the red.
Also, for Austin, a smaller rendering can be created by changing the
dimensions. Its hard coded at 1024x1024 now in the main function.

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>> The goal: find the green in the sea of red.
> [...]
>
> Fwiw, a list of all the const numbers in my program:
>

> 3.14592653

This one looks an awful lot like pi.

If it is pi, then consider including math.h and using the M_PI constant
instead.

[Chris M. Thomasson]

Yes. I just typed most of them in randomly wrt quickly creating the
code. The -2, 2 with 4 as a radius for x and y axes are on purpose. I
wanted to make this initial example produce perfectly symmetrical images
of the Mandelbrot set. Fwiw, the following video just might help
somebody crack the green:

https://youtu.be/9gk_8mQuerg
(The dark side of the Mandelbrot set)

;^)

[Chris M. Thomasson]

Also, take a deep look at:

https://youtu.be/NGMRB4O922I
(The Mandelbrot Set - Numberphile)

Could that possibly be Eve in the flesh? ;^o

[FromTheRafters]

Rich explained on 5/4/2017 :

It is not pi. That would make me suspicious if I were suitably
paranoid.

[Chris M. Thomasson]

Sorry for all of the YouTube links, but be sure to see this one as well:

https://youtu.be/oCkQ7WK7vuY

It focuses on Julia sets more than the Mandelbrot set.

[Rich]

Good point, it is not PI, at least not exactly PI to 8 decimal places.

Which makes this one a good example Chris. A cryptographer,
recognizing that you have an "almost pi" constant, will wonder if you
choose the slightly too big number (too big by 0.00433388) because it
confers some kind of hidden backdoor into your algorithm that you know
about, but no one else knows about.

This is why we tried (and failed) to get you to explain **why** you
pick things and **why** you do things last year when we were trying to
get you to write up a description of your scheme. For someone pairnoid
about hidden things in algorithms, any not adequately explained item
for the reason why some choice was made is an opening to suspect a
backdoor or some other nefarious thing.

[wizzofozz]

On 5-5-2017 1:51, Rich wrote:
> FromTheRafters <err...@nomail.afraid.org> wrote:
>> Rich explained on 5/4/2017 :
>>

>> It is not pi. That would make me suspicious if I were suitably
>> paranoid.
>
> Good point, it is not PI, at least not exactly PI to 8 decimal places.
>
> Which makes this one a good example Chris. A cryptographer,
> recognizing that you have an "almost pi" constant, will wonder if you
> choose the slightly too big number (too big by 0.00433388) because it
> confers some kind of hidden backdoor into your algorithm that you know
> about, but no one else knows about.
>

IIRC, Chris said last year that he "randomly" choose some numbers (and
also somewhere in this thread). There is now way for him to prove that
he didn't choose them for some specific purpose.
I think the only way to make sure that the constants are not "up his
sleeve" is to let them be choosen by you and FromTheRafters.
But how do you prove that Chris is not secretly collaborating with you
two guys and this is all a clever diversion(?)?

Ozz

[Robert Wessel]

On Fri, 5 May 2017 10:38:44 +0200, wizzofozz <oscxxx...@gmail.com>
wrote:

If the number does not have to be secret, just have all the interested
parties generate random numbers *they're* happy with, in the desired
range of 0..N, publish all of them (simultaneously!*), then add them
together mod N and use that.


*That's non-trivial, and crucial. You can't let one party adjust the
final sum by knowing the other inputs first. But doing that is not
hard. For example, each party could take their number, concatenate a
dash and 1000 random letters, and then initially publish the SHA-256
of that. The next day, after it's verified that everyone has
published their hashes, everyone publishes their numbers plus random
strings. If you want go old school, everyone generates their number,
seals it in an envelope, and then everyone meets someplace. After the
envelopes are all collected, they're opened while everyone watches.

[Richard Heathfield]

Yes, I can, but it will have to wait until version 4, which I am now
motivated to write because I've uncovered some structural problems with
CDX-3. I will try to get to it some time next week (but no promises).

CDX-4 will be easier to use (and easier to email!) than CDX-3. It should
also work very slightly better.

[FromTheRafters]

wizzofozz formulated on Friday :

It might have been a typo, but there is the possibility that this
number was pretending to be pi so as to confer that the number is not
'secretly' constructed for nefarious reasons. Not a secret number per
se but a number with a secret. Using the decimal expansion of pi to
some number of places is better than using a number that only looks
like pi to the casual observer.

[Chris M. Thomasson]

On 5/5/2017 4:37 AM, FromTheRafters wrote:
> wizzofozz formulated on Friday :
>> On 5-5-2017 1:51, Rich wrote:
>>> FromTheRafters <err...@nomail.afraid.org> wrote:
>>>> Rich explained on 5/4/2017 :
>>>>
>>>> It is not pi. That would make me suspicious if I were suitably
>>>> paranoid.
>>>
>>> Good point, it is not PI, at least not exactly PI to 8 decimal places.
>>>
>>> Which makes this one a good example Chris. A cryptographer,
>>> recognizing that you have an "almost pi" constant, will wonder if you
>>> choose the slightly too big number (too big by 0.00433388) because it
>>> confers some kind of hidden backdoor into your algorithm that you know
>>> about, but no one else knows about.
>>>
>>
>> IIRC, Chris said last year that he "randomly" choose some numbers (and
>> also somewhere in this thread). There is now way for him to prove that
>> he didn't choose them for some specific purpose.
>> I think the only way to make sure that the constants are not "up his
>> sleeve" is to let them be choosen by you and FromTheRafters.
>> But how do you prove that Chris is not secretly collaborating with you
>> two guys and this is all a clever diversion(?)?

> It might have been a typo, but there is the possibility that this number
> was pretending to be pi so as to confer that the number is not
> 'secretly' constructed for nefarious reasons.

It was a total typo wrt quickly typing in some digits of PI from memory,
I am not trying to create a back door. In fact, I want somebody to
_exploit_ the symmetrical axes that plot the Mandelbrot in order to
crack it out of the sea of red. The symmetry used in the axes:
___________________
xmin: -2
xmax: 2
ymin: -2
ymax: 2
___________________

are totally on purpose to create an example of a "bad key" in the
renderings. If you visually take a look at the real line, e.g. imaginary
axis 0, in the example generated image, it is a point of symmetry. Look
at the pixels just above and below the real line. They create
interesting and intricate patterns in the positive imaginary and
negative imaginary axis, that are mirrors of one another. Imvho, the
example code visually shows a bad key. I thought that it might make it
easier to crack the green out of the red.

The goal was to give a symmetric key on purpose to help others crack it.
So far, even with all of the mirroring wrt the bad key, I cannot crack
it myself! I need help.

> Not a secret number per se
> but a number with a secret. Using the decimal expansion of pi to some
> number of places is better than using a number that only looks like pi
> to the casual observer.

Sorry about that typo!

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> Sorry about that typo!

Fine, but did you fix the typo? Or better yet, include math.h and use
the M_PI macro?

[Chris M. Thomasson]

Not yet. Sorry about my sluggish pace wrt developing this c99 impl. I
think that starting small, and building up piece by piece for everyone
to see would be okay? Also, wrt creating the text file keys, I am
thinking of creating another program ffe_skey.c. This programs sole
purpose would be to allow a user to create a secret key, and even run
some tests on it to tell the user if the key is "kosher", its it
symmetrical, does it pass some basic randomness tests? It can create a
secret key file that can be passed as input to ffe.c to plot and encrypt
something with it. In fact, I am thinking of changing ffe.c to
ffe_plot.c. Humm.

This fresh c99 impl is a work in progress, and the visual and highly
portable nature of the PPM is just wonderful!

[Chris M. Thomasson]

On 5/5/2017 2:39 AM, Richard Heathfield wrote:
> On 04/05/17 21:19, Chris M. Thomasson wrote:
>> On 5/4/2017 2:59 AM, Richard Heathfield wrote:
>>> On 04/05/17 05:55, austin...@hotmail.com wrote:
>>>> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
>>>> wrote:
>> [...]
>>
>> Can you please email me your CDX? I need to learn from it.
>
> Yes, I can, but it will have to wait until version 4, which I am now
> motivated to write because I've uncovered some structural problems with
> CDX-3. I will try to get to it some time next week (but no promises).

Perfect. Just try to remember to send it to me after you are finished.

:^)

> CDX-4 will be easier to use (and easier to email!) than CDX-3. It should
> also work very slightly better.

Nice!

[Chris M. Thomasson]

On 5/5/2017 1:38 AM, wizzofozz wrote:
> On 5-5-2017 1:51, Rich wrote:
>> FromTheRafters <err...@nomail.afraid.org> wrote:
>>> Rich explained on 5/4/2017 :
>>>
>>> It is not pi. That would make me suspicious if I were suitably
>>> paranoid.
>>
>> Good point, it is not PI, at least not exactly PI to 8 decimal places.
>>
>> Which makes this one a good example Chris. A cryptographer,
>> recognizing that you have an "almost pi" constant, will wonder if you
>> choose the slightly too big number (too big by 0.00433388) because it
>> confers some kind of hidden backdoor into your algorithm that you know
>> about, but no one else knows about.
>>
>
> IIRC, Chris said last year that he "randomly" choose some numbers (and
> also somewhere in this thread). There is now way for him to prove that
> he didn't choose them for some specific purpose.

There is no way for me to prove that I did not choose these numbers with
some sort of horrible side venture. However, if I make all the constants
part of the secret key, and clearly document the purpose and ranges of
each one, well, it should be okay?

> I think the only way to make sure that the constants are not "up his
> sleeve" is to let them be choosen by you and FromTheRafters.

I think so, and concur with your statement.

> But how do you prove that Chris is not secretly collaborating with you
> two guys and this is all a clever diversion(?)?

:^o I can assure you all that this is not the case. I am collaborating
in public, in view of all!

Fwiw, this embryonic c99 version is the raw core with a bad key on
purpose, Julia sets as keys aside for a moment, Mandelbrot in a
symmetric region seems fine for this early stage. So, if anybody can
find an exploit, please share it with me: Please! I am begging you.
Crack the green out of the sea of red.

[Chris M. Thomasson]

On 5/3/2017 6:55 PM, Rich wrote:
> Chris M. Thomasson <inv...@invalid.invalid> wrote:

>> On 5/3/2017 4:59 PM, Richard Heathfield wrote:
>>> On 04/05/17 00:31, Rich wrote:
>>>
>>> <snip>
>>>
>>>> Hense the reason why I don't use an IDE
>>>
>>> I do. It's called Linux. :-)
>>
>> I remember using an IDE called Anjuta while on Linux. On Solaris I used
>> NetBeans...

>>
>> http://anjuta.org
>>
>> IIRC, it created makefiles. ;^)
>

> On Linux you use a bash window and a text file editor. No need for
> those awful crutches that so many rely upon.

But, sometimes, they are so convenient. ;^)

Ahhh! That my addiction talking: Damn it!

Although, the debugger in MSVC has always been so nice. Even in
multi-threaded environments.

Another addiction? Yikes!

[Chris M. Thomasson]

Fwiw, my fractal PPM generating program, apart from the way I am
creating the image file wrt the calls to fprintf inside the per-pixel
function, is embarrassingly parallel wrt fact that each pixel can be
computed in isolation. I need to examine the avalanche effect wrt
decrypting. CDX helps me with that. Thank you for creating it Richard.

:^)

[FromTheRafters]

Chris M. Thomasson formulated the question :

Complex Conjugate?

> Look at the pixels just
> above and below the real line. They create interesting and intricate patterns
> in the positive imaginary and negative imaginary axis, that are mirrors of
> one another. Imvho, the example code visually shows a bad key. I thought that
> it might make it easier to crack the green out of the red.

Using a model of vision on the computer rather than an actual visual
inspection seems a better idea. A colorblind person might not see the
pattern even in the red and green version.

Julia Sets seem to have 180 degree rotational symmetry, or close to it,
and might give a hint as to where they lie.

>
> The goal was to give a symmetric key on purpose to help others crack it. So
> far, even with all of the mirroring wrt the bad key, I cannot crack it
> myself! I need help.
>
>
>> Not a secret number per se
>> but a number with a secret. Using the decimal expansion of pi to some
>> number of places is better than using a number that only looks like pi
>> to the casual observer.
>
> Sorry about that typo!

It was merely an observation on my part, not a big deal at all. For
some reason I have memorized Pi to 25 decimal places.

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
> The goal: find the green in the sea of red.
[...]

Fwiw, just to show that I am making real "progress", here is a c99
program that creates a "default" secret key text file that a user can edit:
______________________________
/* Chris M. Thomasson FFE Key Generator ver:0.0.0.0 (pre-alpha)
5/5/2017 - Raw Experimental
_________________________________________________*/

#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>
#include <float.h>


#define CT_QUOTEX(v)#v
#define CT_QUOTE(v)CT_QUOTEX(v)


#define CT_FFE_SKEY_AXES_N 3U
#define CT_FFE_SKEY_JSET_N 3U
#define CT_FFE_SKEY_MODE_MSET 0x1U
#define CT_FFE_SKEY_MODE_JSET 0x2U

#define CT_FFE_SKEY_DOUBLE "%." CT_QUOTE(DBL_DIG) "lf"


struct ct_ffe_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};


struct ct_ffe_skey
{
struct ct_ffe_axes axes[CT_FFE_SKEY_AXES_N];
double complex julia[CT_FFE_SKEY_JSET_N];

double escape;
double scale;
double power;

unsigned int imax;
unsigned int render_mode;
unsigned int color_in;
unsigned int color_out;
unsigned int plane_pad;

double raise_on_zero;
double raise_mul;
double raise_adj;

// will add an HMAC key in future versions.
};


struct ct_ffe_skey
ct_ffe_skey_default(void)
{
struct ct_ffe_skey const default_skey = {
{
{ -2.0, 2.0, -2.0, 2.0 },
{ -2.0, 2.0, -2.0, 2.0 },
{ -2.0, 2.0, -2.0, 2.0 }
},

{
0.0 + 0.0 * I,
0.0 + 0.0 * I,
0.0 + 0.0 * I
},

65526.0,
1.0,
2.0,

128,
CT_FFE_SKEY_MODE_MSET,
120303U,
120303U,
0,

3.141592653,
1.314,
1.61803
};

return default_skey;
}


void
ct_ffe_skey_complex_store(
FILE* fout,
double complex z
){
int status = fprintf(fout,
"(" CT_FFE_SKEY_DOUBLE ", "
CT_FFE_SKEY_DOUBLE ")\n",
creal(z), cimag(z)
);

assert(status > 0);
}


void
ct_ffe_skey_axes_store(
FILE* fout,
struct ct_ffe_axes const* axes
){
int status = fprintf(fout,
"(" CT_FFE_SKEY_DOUBLE ", "
CT_FFE_SKEY_DOUBLE ", "
CT_FFE_SKEY_DOUBLE ", "
CT_FFE_SKEY_DOUBLE ")\n",
axes->xmin, axes->xmax,
axes->ymin, axes->ymax
);

assert(status > 0);
}


void
ct_ffe_skey_store(
FILE* fout,
struct ct_ffe_skey const* skey
){
for (unsigned int i = 0; i < CT_FFE_SKEY_AXES_N; ++i)
{
int status = fprintf(fout, "axes:");
assert(status > 0);
ct_ffe_skey_axes_store(fout, &skey->axes[i]);
}

for (unsigned int i = 0; i < CT_FFE_SKEY_JSET_N; ++i)
{
int status = fprintf(fout, "julia:");
assert(status > 0);
ct_ffe_skey_complex_store(fout, skey->julia[i]);
}

int status = fprintf(fout,
"escape:(" CT_FFE_SKEY_DOUBLE ")\n"
"scale:(" CT_FFE_SKEY_DOUBLE ")\n"
"power:(" CT_FFE_SKEY_DOUBLE ")\n"
"imax:(%u)\n"
"render_mode:(%u)\n"
"color_in:(%u)\n"
"color_out:(%u)\n"
"plane_pad:(%u)\n"
"raise_on_zero:(" CT_FFE_SKEY_DOUBLE ")\n"
"raise_mul:(" CT_FFE_SKEY_DOUBLE ")\n"
"raise_adj:(" CT_FFE_SKEY_DOUBLE ")\n",
skey->escape,
skey->scale,
skey->power,
skey->imax,
skey->render_mode,
skey->color_in,
skey->color_out,
skey->plane_pad,
skey->raise_on_zero,
skey->raise_mul,
skey->raise_adj
);

assert(status > 0);
}


void
ct_ffe_skey_axes_load(
FILE* fin,
struct ct_ffe_axes* axes
){
int status = fscanf(fin,
"axes:(%lf, %lf, %lf, %lf)\n",
&axes->xmin, &axes->xmax,
&axes->ymin, &axes->ymax
);

assert(status == 4);
}


void
ct_ffe_skey_julia_load(
FILE* fin,
double complex* julia
){
double real = 0.0;
double imag = 0.0;

int status = fscanf(fin,
"julia:(%lf, %lf)\n",
&real, &imag
);

assert(status == 2);

*julia = real + imag * I;
}


int
ct_ffe_skey_load(
FILE* fin,
struct ct_ffe_skey* skey
){
for (unsigned int i = 0; i < CT_FFE_SKEY_AXES_N; ++i)
{
ct_ffe_skey_axes_load(fin, &skey->axes[i]);
}

for (unsigned int i = 0; i < CT_FFE_SKEY_JSET_N; ++i)
{
ct_ffe_skey_julia_load(fin, &skey->julia[i]);
}

int status = fscanf(fin,
"escape:(%lf)\n"
"scale:(%lf)\n"
"power:(%lf)\n"
"imax:(%u)\n"
"render_mode:(%u)\n"
"color_in:(%u)\n"
"color_out:(%u)\n"
"plane_pad:(%u)\n"
"raise_on_zero:(%lf)\n"
"raise_mul:(%lf)\n"
"raise_adj:(%lf)",
&skey->escape,
&skey->scale,
&skey->power,
&skey->imax,
&skey->render_mode,
&skey->color_in,
&skey->color_out,
&skey->plane_pad,
&skey->raise_on_zero,
&skey->raise_mul,
&skey->raise_adj
);

assert(status == 11);

return 1;
}


int main(int argc, char *argv[])
{
for (int i = 0; i < argc; ++i)
{
printf("[%d]:%s\n", i, argv[i]);
}

{
struct ct_ffe_skey skey = ct_ffe_skey_default();
FILE* skeyf = fopen("my_skey.txt", "w");
assert(skeyf != NULL);
ct_ffe_skey_store(skeyf, &skey);
fclose(skeyf);
}

{
struct ct_ffe_skey skey;
FILE* skeyf = fopen("my_skey.txt", "r");
assert(skeyf != NULL);
ct_ffe_skey_load(skeyf, &skey);
fclose(skeyf);

ct_ffe_skey_store(stdout, &skey);
}

return 0;
}
______________________________


I am working on this. The secret key file generated "my_skey.txt" is:
______________________________
axes:(-2.000000000000000, 2.000000000000000, -2.000000000000000,
2.000000000000000)
axes:(-2.000000000000000, 2.000000000000000, -2.000000000000000,
2.000000000000000)
axes:(-2.000000000000000, 2.000000000000000, -2.000000000000000,
2.000000000000000)
julia:(0.000000000000000, 0.000000000000000)
julia:(0.000000000000000, 0.000000000000000)
julia:(0.000000000000000, 0.000000000000000)
escape:(65526.000000000000000)
scale:(1.000000000000000)
power:(2.000000000000000)
imax:(128)
render_mode:(1)
color_in:(120303)
color_out:(120303)
plane_pad:(0)
raise_on_zero:(3.141592653000000)
raise_mul:(1.314000000000000)
raise_adj:(1.618030000000000)
______________________________


Still working. This project that I am coding incrementally for everybody
to see, will be completed. I am thinking instead of a default "static"
secret key, well, I can try to create "random" secret keys here.

Coding along. Nothing to see here... Move along.

;^)

[Chris M. Thomasson]

Yes. Take the Mandelbrot set, and any point you can think of that is in
the set. The conjugate of that point is also in the set. Now, Julias are
of a different "variety" wrt any Julia that does not have its imaginary
part set to zero. The Julias on the real line have the conjugate
guarantee. These type of Julias are guaranteed to have the conjugate of
a point inside the set to also be in the set. The rotational symmetry
can ruin this property wrt non-zero imag. However, the Msets are
guaranteed to have this.

>> Look at the pixels just above and below the real line. They create
>> interesting and intricate patterns in the positive imaginary and
>> negative imaginary axis, that are mirrors of one another. Imvho, the
>> example code visually shows a bad key. I thought that it might make it
>> easier to crack the green out of the red.
>
> Using a model of vision on the computer rather than an actual visual
> inspection seems a better idea. A colorblind person might not see the
> pattern even in the red and green version.

Eve should train an AI to recognize fractal patterns? Humm...

> Julia Sets seem to have 180 degree rotational symmetry, or close to it,
> and might give a hint as to where they lie.

The actual Julia sets that are in the Mandelbrot set would be akin to
finding the green out of the sea of red puzzle. When those Julias are on
the real line, well that is a shi% load of bad keys!

>> The goal was to give a symmetric key on purpose to help others crack
>> it. So far, even with all of the mirroring wrt the bad key, I cannot
>> crack it myself! I need help.
>>
>>
>>> Not a secret number per se
>>> but a number with a secret. Using the decimal expansion of pi to some
>>> number of places is better than using a number that only looks like pi
>>> to the casual observer.
>>
>> Sorry about that typo!
>
> It was merely an observation on my part, not a big deal at all. For some
> reason I have memorized Pi to 25 decimal places.

Thank you for taking a look in the first place! Thanks.

:^)

[Chris M. Thomasson]

On 5/6/2017 12:56 PM, Chris M. Thomasson wrote:
> On 5/5/2017 6:13 PM, FromTheRafters wrote:
>> Chris M. Thomasson formulated the question :
>>> On 5/5/2017 4:37 AM, FromTheRafters wrote:
>>>> wizzofozz formulated on Friday :
>>>>> On 5-5-2017 1:51, Rich wrote:
>>>>>> FromTheRafters <err...@nomail.afraid.org> wrote:

[...]

> The actual Julia sets that are in the Mandelbrot set would be akin to
> finding the green out of the sea of red puzzle. When those Julias are on
> the real line, well that is a shi% load of bad keys!

[...]

Fwiw, take a look at the hybrid Julia's I have been creating for this
possible cipher:

https://plus.google.com/101799841244447089430/posts/NtH5sBDpy7H

This rendering does not have the conjugate property.

[Chris M. Thomasson]

On 5/6/2017 12:02 PM, Chris M. Thomasson wrote:
> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>> The goal: find the green in the sea of red.
> [...]
>
> Fwiw, just to show that I am making real "progress", here is a c99
> program that creates a "default" secret key text file that a user can edit:

[...]

I have a strange feeling from past experience that if we move the
location to a part of the Mandelbrot set that does not have the real
line within it, the generated random numbers should have no point of
repetition. Other similar locations would have their own unique numbers
and no cycles. Basically, each location can possibly be a sort of
"one-time-pad".

[FromTheRafters]

Chris M. Thomasson has brought this to us :

I thought that you might like this, and it sort of relates to the
topic.

https://www.youtube.com/watch?v=mg4bp7G0D3s

[Chris M. Thomasson]

Love it. I like the fast pace as well. This is a main reason why I want
somebody to be able to crack the green out of the red. Lets say the
green was a Julia set. Well, if Eve can gain it, then she would have a
visual of the secret key. This would be very nice and extremely
interesting to me. Fwiw, I am almost completed with a PRNG using c99. So
far, all of its outputs are getting some pretty good numbers in ent:

http://www.fourmilab.ch/random

Fwiw, here is ent results from one of my most recent tests of a
2048x2048 Mandelbrot at location:

(-1.75 + 1.06 * I) with a radius of .5:
______________________________
ent ct_ffe_cipher.bin
Entropy = 7.999957 bits per byte.

Optimum compression would reduce the size
of this 4194304 byte file by 0 percent.

Chi square distribution for 4194304 samples is 252.79, and randomly
would exceed this value 52.73 percent of the times.

Arithmetic mean value of data bytes is 127.5017 (127.5 = random).
Monte Carlo value for Pi is 3.141846792 (error 0.01 percent).
Serial correlation coefficient is -0.000195 (totally uncorrelated = 0.0).
______________________________

Afacit, this is not that bad at all! Notice that the location and radius
are well outside the Mset. There actually is no green, or non-escaping
parts if you will. Also, its well off axis and has no symmetry.

The pure portable c99 code will be ready today or sometime tomorrow.

This code produces two files. A PPM and a pure binary file that contains
the colors. We can visualize the PPM, and run the corresponding binary
file through as many randomness tests one can possibly think of. I
happen to like ent, but blast away.

Thank you. :^)

[Chris M. Thomasson]

We can take this location and radius as a secret key, or seed to the PRNG.

[Chris M. Thomasson]

On 5/7/2017 5:02 PM, FromTheRafters wrote:

Fwiw, take a look at an older vid I created on the tube:

https://youtu.be/ffEXxcUNeOM

;^)

[Chris M. Thomasson]

Since the vid had so sound, perhaps watch it with this song:

https://youtu.be/A4J7CwF0JTU

;^)

[Chris M. Thomasson]

On 5/7/2017 10:56 PM, Chris M. Thomasson wrote:
> On 5/7/2017 10:54 PM, Chris M. Thomasson wrote:
>> On 5/7/2017 5:02 PM, FromTheRafters wrote:
>>> Chris M. Thomasson has brought this to us :
>>>> On 5/6/2017 12:02 PM, Chris M. Thomasson wrote:
>>>>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

[...]

>> Fwiw, take a look at an older vid I created on the tube:
>>
>> https://youtu.be/ffEXxcUNeOM
>
> Since the vid had so sound, perhaps watch it with this song:
>
> https://youtu.be/A4J7CwF0JTU

Ahhh, I meant this one:

https://youtu.be/TnZrWWUFl8I

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:

> The goal: find the green in the sea of red.
[...]

Fwiw, here is a first stab at a little fractal prng. It does not have
Rich's command line addition, that is going on there. I have to work on
it some more and upload it to github. Makefile will be there as well.
Anyway, here if the c99 code that outputs two files:

ct_ffe_cpher.ppm - a PPM image
ct_ffe_cipher.bin - a binary of all the colors

run the bin file through as many randomness tests you can think of. I am
using this one for now:

http://www.fourmilab.ch/random
___________________________
/* Chris M. Thomasson FFE Cipher PRNG Renderer ver:0.0.0.0 (pre-alpha)
5/8/2017 - Raw Experimental

_________________________________________________*/

#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>

struct ct_axes

{
double xmin;
double xmax;
double ymin;
double ymax;
};

struct ct_axes
ct_axes_get(
double complex center,
double radius
){
assert(radius > 0.0);
double len = radius / 2.0;

struct ct_axes axes = {
creal(center) - len,
creal(center) + len,
cimag(center) - len,
cimag(center) + len,
};

return axes;
}


unsigned int
ct_raise(double n)
{
double c = fabs(n);
if (c == 0.0) c = 3.141592653;
double z = c;
double mutate = 1.61803;
while (z < 3049213.103)
{
z = z * mutate + c;
mutate = mutate * 1.314;
}
return z;
}


unsigned int
ct_iterate_pixel(
FILE* fout_ppm,
FILE* fout_bin,
double complex z,
double complex c,
unsigned int iseed,
unsigned int imax
){
double o = 999999999999.0;

for (unsigned int i = 0; i < imax; ++i)
{
z = z * z + c;

double dis = cabs(z);

o = (o < dis) ? o : dis;

if (cabs(z) > 65536.0)
{
double sum = fabs(creal(z)) + fabs(cimag(z)) + iseed;
unsigned int red = sum * 120303U;
unsigned int mutator = red % 256U;

fprintf(fout_ppm, "%u %u %u ", mutator, 0, 0);
fputc(mutator, fout_bin);

//fprintf(stdout, "%u\n", red % 256U);
return mutator;
}
}

double oraised = ct_raise(fabs(creal(z)) + iseed);
double sum = fabs(creal(z)) + fabs(cimag(z));
unsigned int green = (ct_raise(sum * iseed) + oraised);
unsigned int mutator = green % 256U;

fprintf(fout_ppm, "%u %u %u ", 0, mutator, 0);
fputc(mutator, fout_bin);

return mutator;
}


void
ct_iterate_plane(
FILE* fout,
FILE* fout_bin,
unsigned int iseed,
struct ct_axes const* iseed_axes,
unsigned int width,
unsigned int height,
unsigned int imax
){
assert(width > 1 && height > 1);

char const ppm_head[] =
"P3\n"
"# Chris M. Thomasson FFE Cipher Renderer ver:0.0.0.0 (pre-alpha)";

printf("fout:%p\n", (void*)fout);

fprintf(fout, "%s\n%u %u\n%u\n", ppm_head, width, height, 255);

double axes_width = iseed_axes->xmax - iseed_axes->xmin;
double axes_height = iseed_axes->ymax - iseed_axes->ymin;

double xstep = axes_width / (width - 1.0);
double ystep = axes_height / (height - 1.0);

for (unsigned int y = 0; y < height; ++y)
{
for (unsigned int x = 0; x < width; ++x)
{
double complex z = (iseed_axes->xmin + x * xstep) +
(iseed_axes->ymax - y * ystep) * I;

// simply destroys the parallel nature!
iseed = ct_iterate_pixel(fout, fout_bin, z, z, iseed, imax);
}

printf("processing y:%u of %u\r", y + 1, height);
}

printf("\nrender complete!\n");
}


// READ ALL!
int main(void)
{
FILE* fout = fopen("ct_ffe_cipher.ppm", "w");
assert(fout != NULL);

FILE* fout_bin = fopen("ct_ffe_cipher.bin", "wb");
if (! fout_bin) { fclose(fout); assert(fout_bin != NULL); }

// Our seed, off axis and far away from the Mset...
double complex center = -1.75 + 1.06 * I;
unsigned int iseed = 7;
struct ct_axes iseed_axes = ct_axes_get(center, .5);

// Iterate the plane
ct_iterate_plane(fout, fout_bin, iseed, &iseed_axes, 2048, 2048, 256);

fclose(fout_bin);
fclose(fout);

printf("\noutput: ct_ffe_cipher.ppm\n");
printf("output: ct_ffe_cipher.bin\n");

return 0;
}
___________________________

[Richard Heathfield]

On 04/05/17 21:19, Chris M. Thomasson wrote:
> On 5/4/2017 2:59 AM, Richard Heathfield wrote:
>> On 04/05/17 05:55, austin...@hotmail.com wrote:

>>> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
>>> wrote:
> [...]
>

> Can you please email me your CDX? I need to learn from it.

I tried to email CDX4 to you, but my postmaster complained:

<inv...@invalid.invalid>: Host or domain name not found. Name service
error for name=invalid.invalid type=A: Host not found

I suggest you just grab the source from sci.crypt - I posted it here today.

[Chris M. Thomasson]

On 5/9/2017 9:41 AM, Richard Heathfield wrote:
> On 04/05/17 21:19, Chris M. Thomasson wrote:
>> On 5/4/2017 2:59 AM, Richard Heathfield wrote:
>>> On 04/05/17 05:55, austin...@hotmail.com wrote:
>>>> On Thursday, May 4, 2017 at 12:33:45 AM UTC+1, Chris M. Thomasson
>>>> wrote:
>> [...]
>>
>> Can you please email me your CDX? I need to learn from it.
>
> I tried to email CDX4 to you, but my postmaster complained:
>
> <inv...@invalid.invalid>: Host or domain name not found. Name service
> error for name=invalid.invalid type=A: Host not found

Fwiw, my email address is:

chrisxX.XXm.x...@xgmail.XXcom

remove all the x's capital and lowercase. I think I remember you sending
me a program that created random text to test encryption a while back.
Something to create plaintext.

> I suggest you just grab the source from sci.crypt - I posted it here today.

Will do.

[Chris M. Thomasson]

On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
> The goal: find the green in the sea of red.
>

> the bitmaps are 1920x1080 dimensions.
>
> warning, javascript must be enabled to download the actual bitmap
> versions of the cheat sheet that shows the green, and the whole of the
> sea of red. Unfortunately, Google+ does not separate the images with a
> clear form of demarcation. Click on the green image on the left to see
> it, and to download it click on arrow pointing down in the upper right:
[...]

I thank Rich for giving me the advise to stop work on my fractal ciphers
until I learn some more essentials from existing cipher research.

Also, thank you for running my code in this thread: I really appreciate it!

[Rich]

Chris M. Thomasson <inv...@invalid.invalid> wrote:

> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>> The goal: find the green in the sea of red.
>>
>> the bitmaps are 1920x1080 dimensions.
>>
>> warning, javascript must be enabled to download the actual bitmap
>> versions of the cheat sheet that shows the green, and the whole of the
>> sea of red. Unfortunately, Google+ does not separate the images with a
>> clear form of demarcation. Click on the green image on the left to see
>> it, and to download it click on arrow pointing down in the upper right:
> [...]
>
> I thank Rich for giving me the advise to stop work on my fractal ciphers
> until I learn some more essentials from existing cipher research.

Well, I don't recall advising you exactly to "stop work". Rather more
of "here is some additional material that might illuminate some details
for you". As in, more study material.

> Also, thank you for running my code in this thread: I really
> appreciate it!

You are welcome.

[Chris M. Thomasson]

Indeed Sir!

>> Also, thank you for running my code in this thread: I really
>> appreciate it!
>
> You are welcome.

Love it.

[Chris M. Thomasson]

On 5/4/2017 3:52 PM, Chris M. Thomasson wrote:

> On 5/4/2017 3:15 PM, Rich wrote:
>> Chris M. Thomasson <inv...@invalid.invalid> wrote:
>>> On 5/1/2017 3:15 PM, Chris M. Thomasson wrote:
>>>> The goal: find the green in the sea of red.

>>> [...]
>>>
>>> Fwiw, a list of all the const numbers in my program:
>>>
>>> 3.14592653
>>
>> This one looks an awful lot like pi.
>>
>> If it is pi, then consider including math.h and using the M_PI constant
>> instead.
>>
>
> Yes. I just typed most of them in randomly wrt quickly creating the
> code. The -2, 2 with 4 as a radius

Ummmm.. Actually these axes make 2 as a radius. 4 would be the damn
diameter! Sorry for this moronic typo.


> for x and y axes are on purpose. I
> wanted to make this initial example produce perfectly symmetrical images
> of the Mandelbrot set. Fwiw, the following video just might help
> somebody crack the green:
>
> https://youtu.be/9gk_8mQuerg
> (The dark side of the Mandelbrot set)
>
> ;^)