Fun/Funny Fractal Encryption...

[Chris M. Thomasson]

FWIW, here is the first pre-alpha version of a, IMHO, fun/funny
little toy program I wrote when I had to think about one-time
pad like encryption. I thought it might be fun to encrypt
plaintext with fractals such that a formula, and several
other settings, would be used as a key. So, the number of
characters in a given text would be used to create a grid
that is used to generate a fractal. I am using escape time
Julia set for now. The escape counts can be used to build
the key for a one-time pad. Here is a sample program that
can encrypt/decrypt strings. Take a look at the `main'
function. The string to be encrypted, the original string so
to speak, is in the `omsg' variable. The encrypted string is
stored in `emsg', and the final decrypted string is stored
in `dmsg'. `dmsg' should be equal to `omsg'. I will explain
this further when I get some more time. Anyway, here is the
code:


http://pastebin.com/Rjw3U7WK
___________________________________________________


/* Mandelbrot Set ASCII by Chris M. Thomasson :^)
___________________________________________________________________*/


#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>


#define CT_MIN(mp_0, mp_1) (((mp_0) < (mp_1)) ? (mp_0) : (mp_1))
#define CT_SQ(mp_n) ((mp_n) * (mp_n))


#define CT_MBROT_ABET_PUNC \
" ,./\\;'[]-=<>?:""{}_+`~"

#define CT_MBROT_ABET_NUM_SHIFT \
"!@#$%^&*()"

#define CT_MBROT_ABET_NUM \
"0123456789"

#define CT_MBROT_ABET_UPPER \
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"

#define CT_MBROT_ABET_LOWER \
"abcdefghijklmnopqrstuvwxyz"


#define CT_MBROT_ABET \
CT_MBROT_ABET_UPPER \
CT_MBROT_ABET_LOWER \
CT_MBROT_ABET_NUM \
CT_MBROT_ABET_NUM_SHIFT \
CT_MBROT_ABET_PUNC

#define CT_MBROT_ABET_MOD (sizeof(CT_MBROT_ABET) - 1U)

#define CT_MBROT_ABET_LOOKUP(mp_char) \
((strchr(CT_MBROT_ABET, (mp_char))) - CT_MBROT_ABET)


struct ct_mbrotcp_pixel
{
double x;
double y;
};


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


struct ct_mbrotvp_plane
{
unsigned int width;
unsigned int height;
};




unsigned int
ct_mbrotpixel(
struct ct_mbrotcp_pixel const* pixel_c,
unsigned int const imax
){
unsigned int i = 0;
unsigned int ret = 0;

struct ct_mbrotcp_pixel pixel_z = *pixel_c;

struct ct_mbrotcp_pixel pixel_z_sq = {
CT_SQ(pixel_z.x), CT_SQ(pixel_z.y)
};

struct ct_mbrotcp_pixel pixel_cj = { -0.7, 0.0 };

double cmin = 9999999999999.0;

for (i = 0; i < imax; ++i)
{
pixel_z.y = pixel_z.x * pixel_z.y * 2.0 + pixel_cj.y;
pixel_z.x = pixel_z_sq.x - pixel_z_sq.y + pixel_cj.x;

pixel_z_sq.x = CT_SQ(pixel_z.x);
pixel_z_sq.y = CT_SQ(pixel_z.y);

cmin = CT_MIN(cmin, CT_SQ(pixel_z_sq.x) + CT_SQ(pixel_z_sq.y));

if (pixel_z_sq.x + pixel_z_sq.y > 2357)
{
ret = (unsigned int)(113747 * fabs(cos(i * cmin * 573)));

putchar(CT_MBROT_ABET[ret % CT_MBROT_ABET_MOD]);

return ret;
}
}

{
unsigned int mc = 0;

ret = (unsigned int)(234777 * fabs(sin(i * cmin * 3233)));
mc = ret % CT_MBROT_ABET_MOD;

putchar(CT_MBROT_ABET[mc]);

/* uncomment to display points that escape as "blanks" */
/* putchar(' '); */
}

return ret;
}


void
ct_mbrotplane(
struct ct_mbrotcp_plane const* cp_plane,
struct ct_mbrotvp_plane const* vp_plane,
unsigned int const imax,
unsigned int* icounts
){
unsigned int vpyi = 0;

struct ct_mbrotcp_pixel cp_pixel = { 0.0, 0.0 };

double const cp_width = cp_plane->xmax - cp_plane->xmin;
double const cp_height = cp_plane->ymax - cp_plane->ymin;

double const xstep = cp_width / vp_plane->width;
double const ystep = cp_height / vp_plane->height;

for (vpyi = 0; vpyi < vp_plane->height; ++vpyi)
{
unsigned int vpxi = 0;

cp_pixel.y = cp_plane->ymax - vpyi * ystep;

for (vpxi = 0; vpxi < vp_plane->width; ++vpxi)
{
cp_pixel.x = cp_plane->xmin + vpxi * xstep;

unsigned int icount = ct_mbrotpixel(&cp_pixel, imax);

if (icounts)
{
unsigned int i = (vpyi * vp_plane->width) + vpxi;

icounts[i] = icount;
}
}

putchar('\n');
}
}







/* Funny Fractal Encryption
___________________________________________________________________*/

#define CT_FFE_ABET_NUM CT_MBROT_ABET_PUNC
#define CT_FFE_ABET_UPPER CT_MBROT_ABET_UPPER
#define CT_FFE_ABET_LOWER CT_MBROT_ABET_LOWER
#define CT_FFE_ABET CT_MBROT_ABET
#define CT_FFE_ABET_MOD CT_MBROT_ABET_MOD
#define CT_FFE_ABET_LOOKUP CT_MBROT_ABET_LOOKUP



struct ct_ffe
{
struct ct_mbrotcp_plane cp_plane;
struct ct_mbrotvp_plane vp_plane;
unsigned int* icounts;
};



int
ct_ffe_create(
struct ct_ffe* const self
){
unsigned int n = self->vp_plane.width * self->vp_plane.height;

self->icounts = calloc(n, sizeof(*self->icounts));

if (self->icounts)
{
return 1;
}

return 0;
}


void
ct_ffe_destroy(
struct ct_ffe* const self
){
free(self->icounts);
}


void
ct_ffe_encrypt_prepare(
struct ct_ffe* const self,
unsigned int const imax
){
ct_mbrotplane(&self->cp_plane, &self->vp_plane, imax, self->icounts);
}


int
ct_ffe_encrypt(
struct ct_ffe* const self,
char const* omsg,
unsigned int omsg_size,
char* emsg,
unsigned int emsg_size
){
unsigned int i = 0;

if (emsg_size < omsg_size)
{
return 0;
}

for (i = 0; i < omsg_size; ++i)
{
unsigned int icount = self->icounts[i] % CT_FFE_ABET_MOD;
unsigned int cx = CT_FFE_ABET_LOOKUP(omsg[i]);
unsigned int ec = (cx + icount) % CT_FFE_ABET_MOD;

emsg[i] = CT_FFE_ABET[ec];
}

return 1;
}


int
ct_ffe_decrypt(
struct ct_ffe* const self,
char const* emsg,
unsigned int emsg_size,
char* dmsg,
unsigned int dmsg_size
){
unsigned int i = 0;

if (dmsg_size < emsg_size)
{
return 0;
}

for (i = 0; i < emsg_size; ++i)
{
unsigned int icount = self->icounts[i] % CT_FFE_ABET_MOD;
unsigned int cx = CT_FFE_ABET_LOOKUP(emsg[i]);

int ec = cx - icount;

if (ec < 0)
{
ec = cx + CT_FFE_ABET_MOD;
ec = abs(icount - ec);
}

dmsg[i] = CT_FFE_ABET[ec];
}

return 1;
}







/* Sample FFE Usage Program
___________________________________________________________________*/
int
main(void)
{
char omsg[] = "/Fun\\ <with> [Fractals]! (tm) `Hello'";
char emsg[sizeof(omsg)] = { '\0' };
char dmsg[sizeof(omsg)] = { '\0' };

unsigned int n = sizeof(omsg) - 1;
unsigned int dim = (((unsigned int)sqrt(n)) + 1);
unsigned int dim_scale = 3;
unsigned int gwidth = dim * dim_scale;
unsigned int gheight = gwidth;


struct ct_ffe fe = {
{ -1.1, 1.0, -1.0, 1.413 },
{ gwidth, gheight },
NULL
};

if (ct_ffe_create(&fe))
{
printf(
"CT_FFE_ABET_MOD = %u\r\n"
"________________________________\r\n"
"Fractal Pad: z^2 + c (Julia Set)\r\n"
"Grid Dims: %u x %u\r\n"
"--------------------------------\r\n",
(unsigned int)CT_FFE_ABET_MOD,
gwidth,
gheight
);

ct_ffe_encrypt_prepare(&fe, CT_FFE_ABET_MOD * dim_scale);

printf("________________________________\r\n");

if (ct_ffe_encrypt(&fe, omsg, n, emsg, n))
{
if (ct_ffe_decrypt(&fe, emsg, n, dmsg, n))
{
printf("\r\noriginal = %s\r\n\r\n", omsg);
printf("encrypted = %s\r\n\r\n", emsg);
printf("decrypted = %s\r\n", dmsg);
}
}

ct_ffe_destroy(&fe);
}

return 0;
}
___________________________________________________


Now to think about all of the floating point issues...

;^)

[Richard Heathfield]

On 08/07/15 01:08, Chris M. Thomasson wrote:
> FWIW, here is the first pre-alpha version of a, IMHO, fun/funny
> little toy program I wrote when I had to think about one-time
> pad like encryption. I thought it might be fun to encrypt
> plaintext with fractals such that a formula, and several
> other settings, would be used as a key. So, the number of
> characters in a given text would be used to create a grid
> that is used to generate a fractal. I am using escape time
> Julia set for now. The escape counts can be used to build
> the key for a one-time pad.

No, they can't. The key for a one-time pad must be generated using a
truly random process. Chaos is not the same as randomness. For further
details, ask in sci.crypt.

--
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]

> "Richard Heathfield" wrote in message news:mnhppt$n9t$1...@dont-email.me...

> > On 08/07/15 01:08, Chris M. Thomasson wrote:

[...]

> > The escape counts can be used to build
> > the key for a one-time pad.

> No, they can't. The key for a one-time pad must be generated using a truly
> random process. Chaos is not the same as randomness. For further details,
> ask in sci.crypt.

Right. I just thought it would be fun to use fractals to build a pseudo key
for
a one-time pad. Sorry I did not specify this. I have to go now. Hope you
don't
think that this is just a plain stupid project? For some reason, I get a
kick out
of it.

lol.

;^)

[Robert Wessel]

You've created a stream cipher. Which is fine (although I have
considerable doubts about the actual security of this one). OTPs have
some special properties, which lead to their provable security, but
this fails most of them. Which is not a problem - no stream (or for
that matter block) cipher is provably secure either. But it's *not*
an OTP.

Part of the problem is that many people see OTPs, and that they offer
provable security, and see that the major problem with them is key
generation, and come up with some mechanical way to generate the keys.
This, of course, entirely invalidates the proof of security, but that
point is usually missed by those folks, who then call what they have
an OTP, implying a (wholly unjustified) level of security.

OTOH, that mechanical generation of a key stream is the basis of a
stream cipher.

The field is unfortunately chock full of kooks who don't understand
that (and refuse to learn), so there's more than a bit of a knee-jerk
reaction to anyone who misuses the term.

[Chris M. Thomasson]

> "Robert Wessel" wrote in message
> news:bk5ppahds6st5l08o...@4ax.com...

>> On 08/07/15 01:08, Chris M. Thomasson wrote:
[...]
>> The escape counts can be used to build
>> the key for a one-time pad.

[...]

>> For some reason, I get a
>> kick out of it.

> You've created a stream cipher. Which is fine (although I have
> considerable doubts about the actual security of this one).

[...]

I know this is a false OTP. I hope I do not come across as a
100% KOOK!

;^o

There is a problem with an aspect of security. The location
of the fractal is in a rather poor location for the code as-is.
There is a symmetrical effect as I am going down the real
line of the complex plane. Now, if I go up the imaginary line
a bit, well, there are places where the symmetry of the real
line is not able to be observed. Therefore the FAKE keys are
not going to "show" an obvious symmetry as well.

This is not the only problem with security.

However, I think it would be kind of a PITA to figure out what
fractal formula encrypted a cyphertext. Also, at what zoom, and
location on the plane?

Humm...

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message
> news:mnhpm5$fh9$1...@speranza.aioe.org...

> FWIW, here is the first pre-alpha version of a, IMHO, fun/funny little
> toy program I wrote when I had to think about one-time pad like
> encryption. I thought it might be fun to encrypt plaintext with fractals
> such that a formula, and several other settings, would be used as a key.

One can alter the hard coded Julia set in the code from:

struct ct_mbrotcp_pixel pixel_cj = { -0.7, 0.0 };

To any z^2 Julia. Well, at least to the limits of a double!

;^)


How to:

do a search on the code for the following text:

"struct ct_mbrotcp_pixel pixel_cj"

You should get a single hit. This is where you can specify the
coordinates for a power of two Julia set.

Going down the real line is a BAD CHOICE!

;^O

The symmetry down the real axis is a problem for this particular formula.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mniejr$idl$1...@speranza.aioe.org...
[...]

> Going down the real line is a BAD CHOICE!
;^O
> The symmetry down the real axis is a problem for this particular formula.

Here is output for the code as-is along with the coordinates of the Julia
set:

struct ct_mbrotcp_pixel pixel_cj = { -0.7, 0.0 };

________________________________

Fractal Pad: z^2 + c (Julia Set)

Grid Dims: 21 x 21
--------------------------------
R$JKDyuGbMl&lMbGuyDKJ
e7Q4}&2&2o@9@o2&2&}4Q
vWF2@IpE3?=6=?3EpI@2F
'Zd)8_\X8($)$(8X\_8)d
>Ng7%H/*gcFYFcg*/H%7g
rVw/Q+ %fno5onf% +Q/w
=81IFtEDO8gOg8ODEtFI1
Rf( AtT_ybASAby_TtA (
zZ.73G*?gQNSNQg?*G37.
vmC=wXg~`+<t<+`~gXw=C
w%c$$?x{pM!c!Mp{x?$$c
O}[l~P/]:Kn=nK:]/P~l[
$UTTQyQ8@P'n'P@8QyQTT
A2z-<%fDQ!gxg!QDf%<-z
Z&d2UkD[KG9:9GK[DkU2d
KT!^IKwqj0 K 0jqwKI^!
B{jOY eQ~x)6)x~Qe YOj
xYHt+f*6JB 7 BJ6*f+tH
.QC2qbkiJdP;PdJikbq2C
Y*9Z%hv*uA^s^Au*vh%Z9
w~#JkI(Ogt:3:tgO(IkJ#
________________________________


Notice the symmetry staring you in the face!


For instance, the string:

AtT_ybASAby_TtA

That seems odd to me.


Well, here is the pseudo/fake key at a location in the
complex plane has a non-zero imaginary part.



struct ct_mbrotcp_pixel pixel_cj = { -0.7, 0.3 };
________________________________

Fractal Pad: z^2 + c (Julia Set)

Grid Dims: 21 x 21
--------------------------------
]<F8-cd+k&`Q]JWS%Y<Tr
E2JQPh&\LJ5NAdV2i8gYK
~V(Pyn]{EpiLBJC]`pn*7
_[1..Gh5I<d(Ps8,z,8+]
'npUj_ie*^ zNcpBHy{Q>
mq [CMM__c\HV('<pjx!'
}c(E*Kf`yzQn=?73KKT$m
%dA^x@VTnTRH-h<0#(gt#
eqN.fF{U+Hw/Ke)/y7vAq
98l}I^veBH8P?;XPoV-W)
%H L7D&]H7V^e -eH-M7$
n#>D~nK4}IiZxHO'1PkSK
fmj-,K#yq&>TY#YXFJ/-5
S}dw:7y85)Bb)-1u. fE7
a&6j/H&!ppnDU F`%KHO\
mH-Je4Hp?eey8u(f>%z3o
O7^=Z}u?}HrRFo-`#owU-
+,]P)}9z5tj8*/PStyH-4
VRB4=-=(/:'HVR}u<s:F(
Kag$Ki=x2,cL~>{S{5=]q
:dRWbgkx[)J6i^%<jTNed
________________________________



Ahhh... That looks MUCH better for the symmetry seems to be broken!


;^D

[Malcolm McLean]

On Wednesday, July 8, 2015 at 1:20:09 AM UTC+1, Chris M. Thomasson wrote:
>
> Right. I just thought it would be fun to use fractals to build a
> pseudo key for a one-time pad. Sorry I did not specify this. I have
> to go now. Hope you don't think that this is just a plain stupid project?
>
> For some reason, I get a kick out of it.
>

Depends what you want to do.
We formed a cryptography club at school. It lasted about a term, and
was rather fun. It's great to work out amateur systems and see
if anyone can beat them.

But if you need it for serious encryption of financially-sensitive
data, where you might be facing a professional criminal, you need
to use professional quality systems.

As a caution, when I was at Oxford a friend encrypted his PIN
using some code based on Greek letters. Some criminal, who must
have been another member of college, found his wallet and bit of
paper, broke the code, and ran away with about a thousand pounds.

[Robert Wessel]

On Tue, 7 Jul 2015 22:43:15 -0700, "Chris M. Thomasson"
<nos...@nospam.nospam> wrote:

>> "Robert Wessel" wrote in message
>> news:bk5ppahds6st5l08o...@4ax.com...
>
>>> On 08/07/15 01:08, Chris M. Thomasson wrote:
>[...]
>>> The escape counts can be used to build
>>> the key for a one-time pad.
>[...]
>>> For some reason, I get a
>>> kick out of it.
>
>> You've created a stream cipher. Which is fine (although I have
>> considerable doubts about the actual security of this one).
>
>[...]
>
>I know this is a false OTP. I hope I do not come across as a
>100% KOOK!

The actual name for a "false OTP" is "stream cipher".

[James Kuyper]

On 07/08/2015 01:43 AM, Chris M. Thomasson wrote:
...

> However, I think it would be kind of a PITA to figure out what
> fractal formula encrypted a cyphertext. Also, at what zoom, and
> location on the plane?

Keep in mind that the only thing that matters, as far as decryption is
concerned, is that there is a pattern to your key. The pattern itself
can be deduced from a sufficiently large encrypted sample, using
entirely different methods from the one you used to generate the pattern.
--
James Kuyper

[Richard Heathfield]

The idea that the adversary has to play by your rules is a very common
misconception, especially in cryptography but also in other fields. I
was once bored enough to watch one of those traffic cop videos where the
police forced a vehicle off the motorway onto a sliproad, where they had
set up a road block at the other end.

In the UK, the hard shoulder is not a carriageway as such, you're not
allowed to drive on it except in an emergency, and in fact it is
supposed to be left clear precisely for such emergency use, and
therefore the police didn't block the hard shoulder. So when the villain
arrived at the road block, he simply drove around it and headed off into
the distance.

It is commonplace for cryptonewbies to come up with a cipher that they
think is unbreakable because the sheer computing power needed to
brute-force the cipher is unthinkably enormous. I would recommend to
such people that they read up on Charles Babbage, Friedrich Kasiski,
Marian Rejewski, Alan Turing, etc etc.

[Chris M. Thomasson]

> "James Kuyper" wrote in message news:mnj1t4$77o$1...@dont-email.me...

> > On 07/08/2015 01:43 AM, Chris M. Thomasson wrote:
...
> > However, I think it would be kind of a PITA to figure out what
> > fractal formula encrypted a cyphertext. Also, at what zoom, and
> > location on the plane?

> Keep in mind that the only thing that matters, as far as decryption is
> concerned, is that there is a pattern to your key.

Absolutely correct. For some reason, I still think that it
might be kind of difficult to find the actual formula that
created the key in the first place. IMVHO, finding the key
would be the easy part!

Once you have worked, used computing power, to find the key,
well, why not try to find the formula that created the key
for fun?

lol. ;^)

> The pattern itself can be deduced from a sufficiently large encrypted
> sample, using entirely different methods from the one you used to
> generate the pattern.

Do you happen to know of any pattern matching software that
can work with plaintext? I would love to see how the key can
be cracked out of a fractal pattern in a location that has
no “obvious symmetry”. Now, I have to admit that sounds more
interesting than creating the toy/funny encryption program
itself. Once the key is obtained/cracked out of a given
cyphertext, I would REALLY love to see how to find either the
original formula, or another one that produces the same
results!

Wow.


BTW, I am thinking about posting this over in scr.crypt just
to see if somebody can crack out a key, or fractal pad if you
will. I just do not want to come across as a total kook moron!

Sorry.

;^o

[James Kuyper]

On 07/08/2015 02:10 PM, Chris M. Thomasson wrote:
>> "James Kuyper" wrote in message news:mnj1t4$77o$1...@dont-email.me...

...

>> Keep in mind that the only thing that matters, as far as decryption is
>> concerned, is that there is a pattern to your key.
>
> Absolutely correct. For some reason, I still think that it
> might be kind of difficult to find the actual formula that
> created the key in the first place. IMVHO, finding the key
> would be the easy part!
>
> Once you have worked, used computing power, to find the key,
> well, why not try to find the formula that created the key
> for fun?

Because that formula is not unique. I've a strong background in math and
science, and that background tells me that there can be many different
ways of expressing the same thing. For instance, compare the Newtonian,
Hamiltonian, and Lagrangian formulations of classical mechanics. It's
possible to prove that they all produce identical results, but I
couldn't possibly have guessed that without having seen those proofs.

>> The pattern itself can be deduced from a sufficiently large encrypted
>> sample, using entirely different methods from the one you used to
>> generate the pattern.
>
> Do you happen to know of any pattern matching software that
> can work with plaintext?

It's not my specialty. What little I know of cryptography is that it
involves a lot of analysis programs that pass information on to skilled
professionals who intuit the pattern from the output of those programs.
That impression is almost certainly four or five decades out-of-date;
I'd be very surprised if the NSA doesn't have standalone programs that
can do this, at least in some cases, entirely without human intervention.

> BTW, I am thinking about posting this over in scr.crypt just
> to see if somebody can crack out a key, or fractal pad if you
> will. I just do not want to come across as a total kook moron!

That's a good idea - they know far more about this than I do. From my
understanding of the current state of the art, I wouldn't be surprised
if public domain shareware is available that could crack your code in
seconds - without producing any output that is recognizable as the
parameters or the structure of the fractal model you used to create it.

[Chris M. Thomasson]

>"James Kuyper" wrote in message news:559D7019...@verizon.net...

>>On 07/08/2015 02:10 PM, Chris M. Thomasson wrote:
>>> "James Kuyper" wrote in message news:mnj1t4$77o$1...@dont-email.me...
...
>>> Keep in mind that the only thing that matters, as far as decryption is
>>> concerned, is that there is a pattern to your key.
>>
>> Absolutely correct. For some reason, I still think that it
>> might be kind of difficult to find the actual formula that
>> created the key in the first place. IMVHO, finding the key
>> would be the easy part!
>>
>> Once you have worked, used computing power, to find the key,
>> well, why not try to find the formula that created the key
>> for fun?

>Because that formula is not unique. I've a strong background in math and
>science, and that background tells me that there can be many different
>ways of expressing the same thing.

Ahhh. Well, that sort of implies that there is more than
z = z^2 + c that can create the Mset, along with all of
its antennae. There has been much work in the field wrt
deriving an iterated function system that can reproduce
the Mset. So far, none have worked. The code I posted uses
Julia sets which do have workable inverses for different powers:

http://www.fractalforums.com/ifs-iterated-function-systems/julia-set-inverse-iteration

However, the Mset is a different story! Julias have that
nice constant point property. The Mset has a unique point
for each point of escape time iteration. Therefore the
inverse of a Mset seems like a major PITA. Yikes!

;^o



BTW, I need to ponder the rest of your post to give a proper response James.

Thanks.

:^)

[Richard Heathfield]

On 08/07/15 20:10, Chris M. Thomasson wrote:
>>"James Kuyper" wrote in message news:559D7019...@verizon.net...

>
>
>>Because that formula is not unique. I've a strong background in math and
>>science, and that background tells me that there can be many different
>>ways of expressing the same thing.
>
> Ahhh. Well, that sort of implies that there is more than
> z = z^2 + c that can create the Mset,

No, it doesn't. Your program's output may have been derived from the
Mandelbrot set, but that doesn't mean there isn't some other algorithm
that will produce the same result /without/ deriving it from the
Mandelbrot set.

Let me give you a simpler example, to illustrate the point. Alice writes
a program to generate a keystream using a highly complicated algorithm:
x[n] = f(x[n-1]) where f() is a scary function that returns a positive
integer. As a final step, she uses the given value as an exponent to 5
using her shiny new bignum package, and because she only needs a single
digit she now reduces the value modulo 10, so the value actually used
for encryption is 5^(x[n]) % 10.

Her keystream output (which she obviously didn't bother to check) is:

5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

It is not difficult to deduce the next number in the keystream without
having to know anything at all about f().

[Chris M. Thomasson]

> "Richard Heathfield" wrote in message news:mnjual$uni$1...@dont-email.me...

> > On 08/07/15 20:10, Chris M. Thomasson wrote:
> >>"James Kuyper" wrote in message news:559D7019...@verizon.net...
> >
> >
> >>Because that formula is not unique. I've a strong background in math and
> >>science, and that background tells me that there can be many different
> >>ways of expressing the same thing.
> >
> > Ahhh. Well, that sort of implies that there is more than
> > z = z^2 + c that can create the Mset,

> No, it doesn't. Your program's output may have been derived from the
> Mandelbrot set, but that doesn't mean there isn't some other algorithm
> that will produce the same result /without/ deriving it from the
> Mandelbrot set.

Okay. That makes sense to me. I would really like to see how
another algorithm can rip out a key from a given cypertext.
For instance, here are two identical 11 letter words encrypted
with the same formula, or key if you will:

=!xcp7j:3Ee

ct0^[tZT/T%

The only difference is that the second one is in a slightly
different location in the fractal. However, it still uses the
exact same formula.


Another example, using the same 11 letter word:

=!xcp7j:3Ee

=]S4>q4.Bb$`$1M>fB{]Qu

The second is the word repeated twice. Notice how the code
changes for the first occurrence of the word?

This type of behavior might make it a little more difficult to
gain a pattern from ciphertext.

> Let me give you a simpler example, to illustrate the point. Alice writes a
> program to generate a keystream using a highly complicated algorithm: x[n]
> = f(x[n-1]) where f() is a scary function that returns a positive integer.
> As a final step, she uses the given value as an exponent to 5 using her
> shiny new bignum package, and because she only needs a single digit she
> now reduces the value modulo 10, so the value actually used for encryption
> is 5^(x[n]) % 10.

> Her keystream output (which she obviously didn't bother to check) is:

> 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5

> It is not difficult to deduce the next number in the keystream without
> having to know anything at all about f().

lol! That's pretty funny.

Thanks Richard.

:^)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mnm91p$9mr$1...@speranza.aioe.org...

>> "Richard Heathfield" wrote in message news:mnjual$uni$1...@dont-email.me...

> > > On 08/07/15 20:10, Chris M. Thomasson wrote:
> > >>"James Kuyper" wrote in message news:559D7019...@verizon.net...

> > >>Because that formula is not unique. I've a strong background in math
> > >>and
> > >>science, and that background tells me that there can be many different
> > >>ways of expressing the same thing.

> > > Ahhh. Well, that sort of implies that there is more than
> > > z = z^2 + c that can create the Mset,

> > No, it doesn't. Your program's output may have been derived from the
> > Mandelbrot set, but that doesn't mean there isn't some other algorithm
> > that will produce the same result /without/ deriving it from the
> > Mandelbrot set.

> Okay. That makes sense to me. I would really like to see how
> another algorithm can rip out a key from a given cypertext.
> For instance, here are two identical 11 letter words encrypted
> with the same formula, or key if you will:

[...]

> Another example, using the same 11 letter word repeated twice:

> =!xcp7j:3Ee

> =]S4>q4.Bb$`$1M>fB{]Qu

There is a problem with regard to the cyphertext being virtually identical
when one changes a single character in the plaintext.

So, encrypting "Christopher" would give a cyphertext. Now changing the
plaintext to "christopher" would give the same cyphertext with only one
character changed! This is simply terrible.

I think there is a way around this such that changing a single character in
the plaintext would produce radical changes in the cyphertext.

Humm... Need to think.

[Richard Heathfield]

On 09/07/15 19:18, Chris M. Thomasson wrote:

<snip>

> I think there is a way around this such that changing a single character in
> the plaintext would produce radical changes in the cyphertext.
>
> Humm... Need to think.

Thinking is good. So is asking in sci.crypt about "avalanching".

[Chris M. Thomasson]

> "Richard Heathfield" wrote in message news:mnme8g$lpm$1...@dont-email.me...

> > On 09/07/15 19:18, Chris M. Thomasson wrote:
<snip>
> > I think there is a way around this such that changing a single character
> > in
> > the plaintext would produce radical changes in the cyphertext.
> >
> > Humm... Need to think.
> Thinking is good. So is asking in sci.crypt about "avalanching".

I think I just may be on the right track here Richard.

Check this crap out:

http://pastebin.com/wjAwawU3

However, there is a caveat. This new setup produces _two_ keys.
F0 is the formula itself, while F1 is a "unique?" offset into
it derived from the nature of the cleartext. IMVHO, F1 can be
sent across the wire because it is useless without the private
key F0. Therefore F0 would be private, and F1 public. Therefore
A transmission between Alice and Bob would go as follows:

0: Bob and Alice decide on a fractal formula F0 they both think
is beautiful.

1: Bob wants to send a private message M to Alice.

2: Bob gets a setting S for another fractal formula F1 derived
from F0 and encrypts M as EM with F1.

3: Bob sends EM and S across the wire to Alice.

4: Alice uses F0 and S to gain the fractal F1.

5: Alice uses F1 to decrypt EM into M.

6: Alice reads the M.

This would create a unique fractal based on the characters in
the cleartext. Well, do you think this might be good enough to
post over in sci.crypt Richard?

I am a bit nervous.

;^/


FWIW, here is a sample of the output:
________________________________________
original = Christopher
encrypted = \a\R8<d95Rl
decrypted = Christopher


original = christopher
encrypted = zg:~0\:`Mhv
decrypted = christopher


original = ChristopheR
encrypted = !'`O0dHG0P=
decrypted = ChristopheR
________________________________________


This is MUCH better than it was before.

Thank you all for the much appreciated comments, sage advice.

:^D

[Richard Heathfield]

On 09/07/15 21:49, Chris M. Thomasson wrote:

<cryptalgorithm snipped>

> This would create a unique fractal based on the characters in
> the cleartext. Well, do you think this might be good enough to
> post over in sci.crypt Richard?

I've seen a lot worse. Why not give it a go? But read the FAQ first
(*always* a good plan) - and read a few of the threads, too. By all
means post, but try not to put your foot in your mouth before you shoot
the foot. :-)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mnhpm5$fh9$1...@speranza.aioe.org... [...]

This is cross-posted with comp.lang.c. I am hoping some of them take a look
at the C
program and perhaps find some bugs for me to fix! :^)

Anyway...
____________________________________________________

I have created a pre-alpha version of a fun little toy
project I call “Funny Fractal Encryption”. It is based
on the idea of generating a stream cypher out of renderings
from fractal formulas. The initial version of the program
is using escape time fractals, Julia set in this case. The
escape iteration counts mutated with color transformation
functions and an orbit trap are then used to build a cypher
of a given location in the fractal. This cypher is then
used to encrypt the cleartext using simple modular arithmetic.
I can get a fairly decent avalanche effect of the resulting
cypertext by using the contents of the cleartext to decide
on what location to go in the Julia set. This location is
used as a public key that can be sent across the wire along
with its associated cypertext. The private key would consist
of a fractal formula, a location in the complex plane and an
iteration count. The resulting cypertext is VERY sensitive
to very small mutations in the fractal settings.

So, the overall scheme for this type of encryption would be
something like:

Bob and Alice want to send/receive encrypted messages to/from
each other.

Bob and Alice decide on a private key K0 consisting of a fractal
formula, location and iteration count that ends up rendering a
beautiful image.

Bob wants to send a message M to Alice, so he uses M to generate
a private key K1 consisting of a location. He then uses K0 and
K1 to generate a new fractal F. Bob then uses F to encrypt M as
EM.

Bob sends EM and K1 across the wire to Alice.

Alice uses the keys K0 and K1 to gain the fractal F.

Alice uses F to decrypt EM back into M.

Alice reads M.


Here is the C code for an embryonic version, pre-alpha indeed!
;^)

http://pastebin.com/fcV5YiJH
(this is the most recent version of the code)

I am VERY interested in any cyrpto analysis that can crack the
formula/key responsible for encrypting several messages with
the same public key/derived-fractal. Keep in mind that the derived
fractal, or public key should be mathematically tied to the original
private fractal.

FWIW, here is a link to the original thread I started over in
comp.lang.c:

https://groups.google.com/d/topic/comp.lang.c/vui6XP-IxRM/discussion
(this link has links to older versions of the program on pastebin)


Well, is this 100% crap, or “perhaps” not all that shi%Ty?

;^o

[Chris M. Thomasson]

> > "Chris M. Thomasson" wrote in message

> > news:mnp683$pld$1...@speranza.aioe.org...

> > "Chris M. Thomasson" wrote in message
> > news:mnhpm5$fh9$1...@speranza.aioe.org... [...]

> I am VERY interested in any cyrpto analysis that can crack the
> formula/key responsible for encrypting several messages with
> the same public key/derived-fractal. Keep in mind that the derived
> fractal, or public key should be mathematically tied to the original
> private fractal.

Yikes! I made a typo in there.

The public key is generated from the cleartext and is
tied to the ciphertext via the private key and can be
sent across the wire as is.

So, I would like to see the private key cracked out of
a series of ciphertexts and their associated public keys.

For instance, here are mutations to the phrase "Hello World"
encrypted with the program as-is. Keep in mind that you
know the private key, and the public keys. So, how you
one go about cracking another key that happens to works
for all of the following cipher texts:


public key = 0.068879
original = Hello World
encrypted = d*GCXsUFHG`
decrypted = Hello World


public key = 0.235041
original = hello World
encrypted = FF!]y@prMak
decrypted = hello World


public key = 0.224501
original = Hello Wordl
encrypted = F2MNVaqXhve
decrypted = Hello Wordl


public key = 0.059056
original = Hello World Hello
encrypted = 1zCCZlG?'%e7pAfk7
decrypted = Hello World Hello


public key = 0.107481
original = Hello World hello
encrypted = %')Ln2,(Pf>IA sq5
decrypted = Hello World hello



Is there an obvious pattern I totally missing!

;^/

[Richard Heathfield]

[Followups set to sci.crypt]

On 10/07/15 20:25, Chris M. Thomasson wrote:

<snip>

> I am VERY interested in any cyrpto analysis that can crack the
> formula/key responsible for encrypting several messages with
> the same public key/derived-fractal. Keep in mind that the derived
> fractal, or public key should be mathematically tied to the original
> private fractal.

Chris, the first step is to try to crack the algorithm yourself.

That doesn't necessarily mean recovering a plaintext from a ciphertext
(without the key). Here are some ways to illustrate that a cipher is
insecure (not all will necessarily apply to every cipher, but most will
apply to most):

1) A frequency analysis shows that the distribution of ciphertext
characters varies significantly from what you would expect from
randomly-generated data. This is a relatively easy task.
(Transposition-only ciphers are bound to fail this test, which doesn't
necessarily mean they're no use.)

2) A change of a single bit in the plaintext results in a trifling
change in the ciphertext. One would expect, in a strong cipher, that the
alteration of a single bit in the plaintext would result in roughly half
the bits of the ciphertext changing (and these changes would be
distributed apparently at random through the file).

3) The cipher falls to the usual attacks on monoalphabetic or
polyalphabetic substitution ciphers. (Look up "Kasiski" and/or "Index of
Coincidence".)

4) Given a known plaintext (i.e. you have the ciphertext and you know at
least some of the plaintext that generated it), you can recover the key.

Those might be considered the most basic attacks. You need to try these
for yourself. You will never design a first-class (or even second- or
third-class) cipher if you don't acquire some experience in breaking
ciphers. (And it's quite a diverting exercise in its own right.)

When you ask "can anyone break this?", they're much more likely to *try*
if you can say "the ciphertext is indistinguishable from random, the
avalanching is up to snuff, and I tried the foo, bar, and baz attacks,
but couldn't make any headway" - in other words, if you've eliminated
the obvious and also shown that you've made an effort.

[Chris M. Thomasson]

FWIW, here is the latest version that can encrypt any file:

http://pastebin.com/rQRXU5Mb

The command line for encryption is:

<flag> = 0 means encrypt
<flag> = 1 means decrypt

<program> <cleartext.file[in]> <ciphertext.file[out]> <flag:0> <xmin> <xmax>
<ymin> <ymax>


The command like for decryption is:

<program> <ciphertext.file[in]> <cleartext.file[out]> <flag:1> <xmin> <xmax>
<ymin> <ymax>


Running the program in encrypt mode gives a command line that
can decrypt the generated ciphertext. Here is output I get for
the same file I posted the freqency distributions for in the
ShuttlePads thread:
____________________________________________________________________
xmin = -0.50000000000
xmax = 0.50000000000
ymin = -0.50000000000
ymax = 0.50000000000
Opened the cleartext [in]! <C:\Users\Chris\Desktop\cleartext.txt>
Opened the ciphertext [out]! <C:\Users\Chris\Desktop\ciphertext.txt>
ffe_encrypt_first_pass processed: 703149 bytes

lost precision: 0.0000000000006
lost precision: 0.0000000000035
lost precision: 0.0000000000039
lost precision: 0.0000000000050
pub_xmin_scale = -0.39747846419
pub_xmax_scale = 1.22504427779
pub_ymin_scale = -0.37951654765
pub_ymax_scale = 0.67335246548

file size: 703149
fractal dims: 840 x 840

Passed at 703149 bytes!



Decrypt Command Line:

C:\Users\Chris\Desktop\ciphertext.txt
C:\Users\Chris\Desktop\cleartext.txt_dc 1
-0.39747846419 1.22504427779 -0.37951654765 0.67335246548


No Errors Reported!

Closed the ciphertext [out]! <C:\Users\Chris\Desktop\ciphertext.txt>
Closed the cleartext [in]! <C:\Users\Chris\Desktop\cleartext.txt>

Complete!


The decrypt command line is:

C:\Users\Chris\Desktop\ciphertext.txt
C:\Users\Chris\Desktop\cleartext.txt_dc 1 -0.39747846419
1.22504427779 -0.37951654765 0.67335246548


This code is in a fairly sad state. Its in flux. I need to check
sscanf for errors damn it!

But, at least you can see how this works and can make your own
analysis of the ciphertexts for any file.


Also, keep in mind that the private key is hard coded into the
program as:

{ -0.7, 0.25 }

So, every ciphertext will be based off a location into this
paticiular Julia set. I need to make the program able to allow
a user to provide their own actual formula and locations, iteration
counts, color monitors, ect... Lot of work to do!

Yikes!

;^o

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mpgmfd$q02$1...@speranza.aioe.org...

> FWIW, here is the latest version that can encrypt any file:

> http://pastebin.com/rQRXU5Mb

Ummmm.... There is a damn getchar that I forgot to remove! So, the program
completes and hits a damn getchar. Well, you need to hit a key. Anyway,
I forgot to remove this. Sorry!!!!

;^o


Here is the code just in case PasteBin does not work for some reason:

(this one has the getchar commented out)
__________________________________________________________________
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <math.h>



/*-------------------------*/
#define CT_LB "\r\n"
#define CT_PREC "%.11lf"
#define CT_PREC_EPS "%.13lf"
#define CT_EPS 0.00000000001
#define CT_MIN(mp_0, mp_1) ((mp_0) < (mp_1) ? (mp_0) : (mp_1))

struct main_args
{
int argc;
char** argv;
};





/*-------------------------*/
double
double_to_string_to_double(
double n
){
double nn = 0.0;
double ndif = 0.0;

char nbuf[UCHAR_MAX + 1] = { '\0' };

sprintf(nbuf, CT_PREC, n);

sscanf(nbuf, "%lf", &nn);

ndif = fabs(n - nn);

/* `nn' has lost precision of `n'.*/
printf("lost precision: " CT_PREC_EPS CT_LB, ndif);

return nn;
}


double
string_to_double(
char const* nbuf
){
double n = 0.0;

sscanf(nbuf, "%lf", &n);

return n;
}


unsigned int
string_to_uint(
char const* nbuf
){
unsigned int n = 0;

sscanf(nbuf, "%u", &n);

return n;
}





/*-------------------------*/
#define SQ(mp_0) ((mp_0)*(mp_0))


struct complexn
{
double x;
double y;
};


#define COMPLEXN_SINIT() { 0.0, 0.0 }


struct complexn
complexn_add(
struct complexn self,
struct complexn n
){
struct complexn p = {
self.x + n.x,
self.y + n.y
};

return p;
}


struct complexn
complexn_mul(
struct complexn self,
struct complexn n
){
struct complexn p = {
self.x * n.x - self.y * n.y,
self.x * n.y + self.y * n.x
};

return p;
}




/*--------------------------*/
unsigned long
cantor_packing(
unsigned int n0,
unsigned int n1
){
unsigned long ret = 0.5 * (n0 + n1) * (n0 + n1 + 1) + n1;

return ret;
}





/*-------------------------*/
#define FFE_MARGS_NMIN 7
#define FFE_BUF_NMAX (1024 * 756)
#define FFE_ABETN (UCHAR_MAX + 1U)


struct ffe_buf
{
unsigned char buf[FFE_BUF_NMAX];
size_t bufsz;
};


struct ffe_abet
{
unsigned int abet[UCHAR_MAX + 1];
};


struct ffe_cplane

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

unsigned int
ffe_cplane_iterate(
struct complexn c,
struct complexn j,
unsigned int imax

){
unsigned int i = 0;

unsigned int imod = 0;

double dmin = 999999999999.0;

struct complexn z = c;
c = j; /* Julia Mode */

for (i = 0; i < imax; ++i)
{

double zd = 0.0;

z = complexn_mul(z, z);
z = complexn_add(z, c);

zd = SQ(z.x) + SQ(z.y);

dmin = CT_MIN(dmin, zd);

if (zd > 4.0)
{
imod = (unsigned int)((20371 + i) *
fabs(cos(i * i * dmin * 252307))) % FFE_ABETN;

return imod;
}
}

imod = (unsigned int)(40377 *
fabs(sin(dmin * 152307))) % FFE_ABETN;

return imod;
}




size_t
ffe_buf_read(
struct ffe_buf* const self,
FILE* const file
){
self->bufsz = fread(self->buf, 1, FFE_BUF_NMAX, file);

if (self->bufsz == FFE_BUF_NMAX)
{
return self->bufsz;
}

if (! ferror(file))
{
if (feof(file))
{
return self->bufsz;
}
}

printf("fread error!" CT_LB);

return 0;
}


size_t
ffe_buf_write(
struct ffe_buf const* const self,
FILE* const file
){
size_t bufsz = fwrite(self->buf, 1, self->bufsz, file);

if (bufsz == FFE_BUF_NMAX)
{
return bufsz;
}

if (! ferror(file))
{
return bufsz;
}

printf("fwrite error!" CT_LB);

return 0;
}





/*-------------------------*/

struct ffe_encrypt
{
struct ffe_cplane cplane; /* private key: plane */
struct complexn jplane; /* private key: Julia */
struct ffe_cplane pub_cplane; /* public key: plane */

struct ffe_buf* ebuf;
unsigned int flags;
size_t uwidth;
size_t fbytes;

FILE* fctext; /* clear text file */
FILE* fcipher; /* cipher text file */
};


int
ffe_encrypt_main_args_fctext_parse(
struct ffe_encrypt* const self,
struct main_args* const margs
){
if (margs->argc == FFE_MARGS_NMIN + 1)
{
unsigned int base = 1;

/* Try to open the cleartext [in] */
self->fctext = fopen(margs->argv[base], "rb");

if (self->fctext)
{
printf("Opened the cleartext [in]! <%s>" CT_LB, margs->argv[1]);

/* Try to open the ciphertext [out] */
self->fcipher = fopen(margs->argv[base + 1], "wb");

if (self->fcipher)
{
printf("Opened the ciphertext [out]! <%s>" CT_LB,
margs->argv[base + 1]);

return 1;
}

else
{
printf("Cannot open the ciphertext [out]! <%s>" CT_LB,
margs->argv[base + 1]);
}

fclose(self->fctext); /* check for errors!?!? */
}

printf("Cannot open the cleartext [int]! <%s>" CT_LB,
margs->argv[base]);
}

return 0;
}


int
ffe_encrypt_main_args_cplane_parse(
struct ffe_encrypt* const self,
struct main_args* const margs
){
if (margs->argc == FFE_MARGS_NMIN + 1)
{
/* Parse the complex plane dimensions (2d for now) */
unsigned int const icpbase = 3;

self->flags = string_to_uint(margs->argv[icpbase + 0]);

self->cplane.xmin = string_to_double(margs->argv[icpbase + 1]);
self->cplane.xmax = string_to_double(margs->argv[icpbase + 2]);

self->cplane.ymin = string_to_double(margs->argv[icpbase + 3]);
self->cplane.ymax = string_to_double(margs->argv[icpbase + 4]);

return 1;
}

return 0;
}


int
ffe_encrypt_parse(
struct ffe_encrypt* const self,
struct main_args* const margs
){
if (ffe_encrypt_main_args_cplane_parse(self, margs))
{
printf(
"xmin = " CT_PREC CT_LB "xmax = " CT_PREC CT_LB
"ymin = " CT_PREC CT_LB "ymax = " CT_PREC CT_LB,
self->cplane.xmin, self->cplane.xmax,
self->cplane.ymin, self->cplane.ymax
);

if (ffe_encrypt_main_args_fctext_parse(self, margs))

{
return 1;
}
}

return 0;
}


void

ffe_encrypt_first_pass(
struct ffe_encrypt* const self,
struct main_args const* const margs
){
self->fbytes = 0;
double cmean_sum = 0.0;
size_t cpack_msum = 0;
size_t cxor = 0;

for (;;)
{
size_t rbytes = ffe_buf_read(self->ebuf, self->fctext);

if (rbytes != 0)
{
size_t i = 0;

for (i = 0; i < rbytes; i += 2)
{
double cavg_0 = self->ebuf->buf[i] / ((double)UCHAR_MAX);
double cavg_1 = self->ebuf->buf[i + 1] /
((double)UCHAR_MAX);

cmean_sum = cmean_sum + cavg_0 + cavg_1;

cpack_msum =
(cpack_msum + cantor_packing(
self->ebuf->buf[i], self->ebuf->buf[i + 1])) %
1073741823;

cxor = cxor ^ self->ebuf->buf[i];
cxor = cxor ^ self->ebuf->buf[i + 1];
cxor = cxor ^ cpack_msum;

cmean_sum += ((cxor) % (UCHAR_MAX)) / ((double)UCHAR_MAX);
}

printf("ffe_encrypt_first_pass processed: %lu bytes" CT_LB,
(unsigned long)rbytes);

self->fbytes = self->fbytes + rbytes;

continue;
}

break;
}

printf(CT_LB);

{
/* build new location/offset (Public Key) into (Private Key) */
double cavg = cmean_sum / ((double)self->fbytes);
double cfmod = ((cavg + (cpack_msum / cxor)) * cxor) / ((cxor +
cpack_msum) % 1237);
cfmod = fmod(cfmod, 1.0);

/* try to avoid divide-by-zero conditions */
if (! cxor) cxor = 1;
if (! cpack_msum) cpack_msum = 1;

{
/* Generate Public Key Scale */
unsigned int sum_mod = 5;
double fmod_scale = ((1.0 + sqrt(5.0)) / 2.0) / 2.0;
double pub_xmin_scale = fmod(cavg * cfmod + (cxor /
(double)cpack_msum), fmod_scale);
double pub_xmax_scale = fmod((cavg * cfmod) * cxor + (cxor /
(double)cpack_msum), fmod_scale);
double pub_ymin_scale = fmod(cavg + cfmod + (cxor /
(double)cpack_msum), fmod_scale);
double pub_ymax_scale = fmod((cavg + cfmod) * cxor + (cxor /
(double)cpack_msum), fmod_scale);

pub_xmin_scale = pub_xmin_scale / ((cxor % 7) + 3);
pub_xmax_scale = pub_xmax_scale / (((cxor + cpack_msum) % 7) +
1);
pub_ymin_scale = pub_ymin_scale / (((cxor * cpack_msum) % 7) +
1);
pub_ymax_scale = pub_ymax_scale / (((((cxor * 3 + cpack_msum) +
7)) % 7) + 1);

pub_xmin_scale = (fmod(pub_xmin_scale + (cavg / 7), fmod_scale))
+ self->cplane.xmin;
pub_xmax_scale = (fmod(pub_xmax_scale + (cavg / 7), fmod_scale))
+ self->cplane.xmax;
pub_ymin_scale = (fmod(pub_ymin_scale + (cavg / 7), fmod_scale))
+ self->cplane.ymin;
pub_ymax_scale = (fmod(pub_ymax_scale + (cavg / 7), fmod_scale))
+ self->cplane.ymax;

cavg = fmod(cavg, fmod_scale);
cfmod = fmod(cfmod, fmod_scale);
cavg = 1.0 - fmod(cavg + cfmod, fmod_scale);

cpack_msum = cpack_msum * cavg + (cpack_msum % sum_mod) + 1;
cxor = cxor + (cxor % sum_mod) + 1;


self->pub_cplane.xmin =
double_to_string_to_double(pub_xmin_scale);
self->pub_cplane.xmax =
double_to_string_to_double(pub_xmax_scale);
self->pub_cplane.ymin =
double_to_string_to_double(pub_ymin_scale);
self->pub_cplane.ymax =
double_to_string_to_double(pub_ymax_scale);


/* decrypt setting 0 */
if (self->flags == 1)
{
self->pub_cplane = self->cplane;
}


printf("pub_xmin_scale = " CT_PREC CT_LB,
self->pub_cplane.xmin);
printf("pub_xmax_scale = " CT_PREC CT_LB,
self->pub_cplane.xmax);
printf("pub_ymin_scale = " CT_PREC CT_LB,
self->pub_cplane.ymin);
printf("pub_ymax_scale = " CT_PREC CT_LB,
self->pub_cplane.ymax);
}
}
}


int
ffe_encrypt_second_pass(
struct ffe_encrypt* const self,
struct main_args const* const margs
){
double xwidth = self->pub_cplane.xmax - self->pub_cplane.xmin;
double xheight = self->pub_cplane.ymax - self->pub_cplane.ymin;

double xstep = xwidth / self->uwidth;
double ystep = xheight / self->uwidth;

struct complexn c = COMPLEXN_SINIT();

{
size_t i = 0;

rewind(self->fctext);

printf(CT_LB);

for (i = 0; i < self->fbytes;)
{
size_t rbytes = ffe_buf_read(self->ebuf, self->fctext);

if (rbytes != 0)
{
size_t ic = 0;

for (ic = 0; ic < rbytes; ++ic, ++i)
{
/* Apply the cipher */
unsigned int imod = 0;
unsigned int cmod = self->ebuf->buf[ic];

unsigned int yi = i / self->uwidth;
unsigned int xi = i - yi * self->uwidth;

c.x = self->pub_cplane.xmin + xi * xstep;
c.y = self->pub_cplane.ymin + yi * ystep;

imod = ffe_cplane_iterate(c, self->jplane, 503);



/* encrypt/decrypt */
if (self->flags == 0)
{
imod = (imod + cmod) % FFE_ABETN;
}

else
{
int ec = cmod - imod;

if (ec < 0)
{
ec = cmod + FFE_ABETN;
imod = abs(imod - ec);
}

else
{
imod = ec;
}
}

/* commit cipher char to buffer */
self->ebuf->buf[ic] = imod;

if (! (i % 1000))
{
printf("i = %lu\r", (unsigned long)i);
}
}

/* write buffer to cipher file */
{
size_t wbytes = ffe_buf_write(self->ebuf,
self->fcipher);

if (wbytes < rbytes)
{
/* need to loop until the buffer is commited! */
printf("SINGLE WRITE IS FUC%%ED!" CT_LB);
getchar();
}
}

continue;
}

break;
}

if (i == self->fbytes)
{
printf("Passed at %lu bytes!" CT_LB CT_LB, (unsigned long)i);

return 1;
}
}

return 0;
}




/*-------------------------*/
int
main(
int argc,
char* argv[]
){
struct main_args self = { argc, argv };

{
struct ffe_buf ebuf = { { '\0' } };

struct ffe_encrypt fenc = {
{ -2.0, 2.0, -2.0, 2.0, }, /* private key: plane */

/* need to put this in the cmd line damn it! */
{ -0.7, 0.25 }, /* private key: Julia */

{ 0.0, 0.0, 0.0, 0.0, }, /* public key */
&ebuf,
0,
0,
0,
NULL,
NULL
};

if (ffe_encrypt_parse(&fenc, &self))
{
ffe_encrypt_first_pass(&fenc, &self);

printf(CT_LB);
printf("file size: %lu" CT_LB, (unsigned long)fenc.fbytes);

/* gain dims of fractal pad */
fenc.uwidth = (sqrt(fenc.fbytes) + 1.681) * 1.0;

printf("fractal dims: %lu x %lu" CT_LB,
(unsigned long)fenc.uwidth,
(unsigned long)fenc.uwidth
);

if (ffe_encrypt_second_pass(&fenc, &self))
{
if (fenc.flags == 0)
{
unsigned int base = 1;

printf(CT_LB CT_LB "Decrypt Command Line:" CT_LB CT_LB);
printf("%s %s_dc 1 " CT_PREC " " CT_PREC " " CT_PREC " "
CT_PREC CT_LB CT_LB,
self.argv[base + 1],
self.argv[base],
fenc.pub_cplane.xmin,
fenc.pub_cplane.xmax,
fenc.pub_cplane.ymin,
fenc.pub_cplane.ymax);
}

printf(CT_LB "No Errors Reported!" CT_LB CT_LB);
}

/* Check for ERRORS! */
fclose(fenc.fcipher);
printf("Closed the ciphertext [out]! <%s>" CT_LB, self.argv[2]);

fclose(fenc.fctext);
printf("Closed the cleartext [in]! <%s>" CT_LB, self.argv[1]);
}

else
{
printf("failed to parse!" CT_LB);
}
}

puts(CT_LB "Complete!" CT_LB);
/* getchar(); */

return 0;
}
__________________________________________________________________

[Chris M. Thomasson]

One more thing... I am creating a single buffer on the stack the size of
`FFE_BUF_NMAX':
_________________________________________________

#define FFE_MARGS_NMIN 7
#define FFE_BUF_NMAX (1024 * 756)
#define FFE_ABETN (UCHAR_MAX + 1U)

_________________________________________________


This might be too much for your stack. So, if you get a stack overflow,
well, make
`FFE_BUF_NMAX'' smaller!


:^O

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mnp683$pld$1...@speranza.aioe.org...

> > "Chris M. Thomasson" wrote in message
> > news:mnhpm5$fh9$1...@speranza.aioe.org... [...]

> This is cross-posted with comp.lang.c. I am hoping some of them take a
> look at the C program and perhaps find some bugs for me to fix! :^)

I am going to code my cryptoalgorithm in Javascript and put it up on a
website.

Then one will not have to compile the C code in order to play around with
the toy!

;^)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mpgmfd$q02$1...@speranza.aioe.org...

> FWIW, here is the latest version that can encrypt any file:

> http://pastebin.com/rQRXU5Mb

Quick question: Has anybody tried to compile this?

If so, how did it go?

:^o

[Ben Bacarisse]

"Chris M. Thomasson" <nos...@nospam.nospam> writes:

>> "Chris M. Thomasson" wrote in message
>> news:mpgmfd$q02$1...@speranza.aioe.org...
>
>> FWIW, here is the latest version that can encrypt any file:
>
>> http://pastebin.com/rQRXU5Mb
>
> Quick question: Has anybody tried to compile this?

No, but I did just now since you asked...

> If so, how did it go?

Not bad. A lot of conversion warnings (I use -Wconversion on all new
code just to get the lie of the land) but they may well be fine.

A warning about unused parameter (margs) and one about a missing
initialiser for bufsz in struct ffe_buf. Only that last one worried me.

Running the result says

failed to parse!

Complete!

which indicates something is wrong. Do I need some hardware-specific
flags? This is gcc version 4.9.2 on an i7-3520M CPU.

You are avoiding C's complex type but using some other C99 features.
That's not wrong, but a little odd.

--
Ben.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:8737zc8...@bsb.me.uk...

>> "Chris M. Thomasson" <nos...@nospam.nospam> writes:

> >> "Chris M. Thomasson" wrote in message
> >> news:mpgmfd$q02$1...@speranza.aioe.org...
> >
> >> FWIW, here is the latest version that can encrypt any file:
> >
> >> http://pastebin.com/rQRXU5Mb
>
> > > Quick question: Has anybody tried to compile this?

> No, but I did just now since you asked...

> > If so, how did it go?

> Not bad. A lot of conversion warnings (I use -Wconversion on all new
> code just to get the lie of the land) but they may well be fine.

I think they are okay.

> A warning about unused parameter (margs) and one about a missing
> initialiser for bufsz in struct ffe_buf. Only that last one worried me.

I am not seeing those warnings. The unused parameter (margs)
almost has to be in the (ffe_encrypt_first_pass) and
(ffe_encrypt_second_pass) functions. As for the last one, well
could you please provide me with a line number? I am compiling
this with with Mingw 4.9.2 and the most recent MSVC. Unfortunately,
none of them give these warnings Ben!

Damn.

> Running the result says

> failed to parse!

> Complete!

> which indicates something is wrong. Do I need some hardware-specific
> flags? This is gcc version 4.9.2 on an i7-3520M CPU.

It will output “Complete!” regardless of how it exits, and this is
a flaw. The failed to parse error means that it did not get enough
command line arguments; it requires 7 of them. The command line syntax
for this is:

<flag> = 0 means encrypt

<flag> = 1 means decrypt



<program> <cleartext.file[in]> <ciphertext.file[out]> <flag:0>
<xmin> <xmax>
<ymin> <ymax>





The command like for decryption is:



<program> <ciphertext.file[in]> <cleartext.file[out]> <flag:1>
<xmin> <xmax>
<ymin> <ymax>




Running the program in encrypt mode gives a command line that
can decrypt the generated ciphertext.

Example for encryption:



ffe C:\plaintext.txt C:\ciphertext.dat 0 -0.5 0.5 -0.5 0.5



Does something like that work? FWIW, here is the command line
I am using in my test environment over on Windows 7:




ffe C:\Users\Chris\Desktop\ffe_dat\cleartext.txt
C:\Users\Chris\Desktop\ffe_dat\ciphertext.txt 0 -0.5 0.5 -0.5 0.5


The <xmin> <xmax> <ymin> <ymax> arguments define the 2d plane/
location in which the fractal will be processed.

> You are avoiding C's complex type but using some other C99 features.
> That's not wrong, but a little odd.

Yeah, I just could not get the standard built in complex type to
work for me for some reason.

Damn again.

;^o



Can you try creating a simple text file, called plaintext.txt,
and running the program with:

ffe <path_to_plaintext.txt> <path_to_ciphertext.dat> 0
-0.5 0.5 -0.5 0.5

something like:

ffe plaintext.txt ciphertext.dat 0 -0.5 0.5 -0.5 0.5

This will read the plaintext.txt file and create a new file
called ciphertext.dat. The program will the output a command
line that can be used to decrypt the ciphertext.dat.

Again, I am sorry for the sorry state of the crude, embryonic
version of the code!

;^o

[Ben Bacarisse]

"Chris M. Thomasson" <nos...@nospam.nospam> writes:

>> "Ben Bacarisse" wrote in message news:8737zc8...@bsb.me.uk...
>
>>> "Chris M. Thomasson" <nos...@nospam.nospam> writes:
>
>> >> "Chris M. Thomasson" wrote in message
>> >> news:mpgmfd$q02$1...@speranza.aioe.org...
>> >
>> >> FWIW, here is the latest version that can encrypt any file:
>> >
>> >> http://pastebin.com/rQRXU5Mb
>>
>> > > Quick question: Has anybody tried to compile this?
>
>> No, but I did just now since you asked...
>
>> > If so, how did it go?
>
>> Not bad. A lot of conversion warnings (I use -Wconversion on all new
>> code just to get the lie of the land) but they may well be fine.
>
> I think they are okay.
>
>
>> A warning about unused parameter (margs) and one about a missing
>> initialiser for bufsz in struct ffe_buf. Only that last one worried me.
>
> I am not seeing those warnings. The unused parameter (margs)
> almost has to be in the (ffe_encrypt_first_pass) and
> (ffe_encrypt_second_pass) functions. As for the last one, well
> could you please provide me with a line number?

Line 588. I'd add a 0 just to clear it up:

struct ffe_buf ebuf = { { '\0' }, 0 };

In fact, I might write it

struct ffe_buf ebuf = { "", 0 };

but that's hardly important.

<snip>

>> Running the result says
>
>> failed to parse!
>
>> Complete!
>
>> which indicates something is wrong. Do I need some hardware-specific
>> flags? This is gcc version 4.9.2 on an i7-3520M CPU.
>
> It will output “Complete!” regardless of how it exits, and this is
> a flaw. The failed to parse error means that it did not get enough
> command line arguments; it requires 7 of them.

<snip>

> Example for encryption:
>
> ffe C:\plaintext.txt C:\ciphertext.dat 0 -0.5 0.5 -0.5 0.5
>
> Does something like that work?

Yes. I can do an encrypt/decrypt cycle fine.

The program's a bit wordy but that's probably a Windows/Unix culture
clash.

<snip>

> Again, I am sorry for the sorry state of the crude, embryonic
> version of the code!

It's fine, but a one-line "usage" message would have enabled me to test
it right away.

--
Ben.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:87wpwn7...@bsb.me.uk...
[...]

> > "Chris M. Thomasson" <nos...@nospam.nospam> writes:

[...]

> >> "Ben Bacarisse" wrote in message news:8737zc8...@bsb.me.uk...

[...]

> >> A warning about unused parameter (margs) and one about a missing
> >> initialiser for bufsz in struct ffe_buf. Only that last one worried
> >> me.
> >
> > I am not seeing those warnings. The unused parameter (margs)
> > almost has to be in the (ffe_encrypt_first_pass) and
> > (ffe_encrypt_second_pass) functions. As for the last one, well
> > could you please provide me with a line number?

> Line 588. I'd add a 0 just to clear it up:

> struct ffe_buf ebuf = { { '\0' }, 0 };

> In fact, I might write it

> struct ffe_buf ebuf = { "", 0 };

> but that's hardly important.

Thank you for helping me spot this. Also, I am very happy that
the pre-alpha code seems to be working for you.

Thanks again Ben.

:^D

[luser droog]

Have you heard of Emscripten? You can compile to javscript.

[Rick C. Hodgin]

Chris,

I saw this video today and thought of something:

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

As the morphing takes place through raised powers, it seems to describe
something that could be aligned as a series of 2D images set like slices
of bread, creating a 3D structure by tying specific points from each
slice to the next, producing quads, which are converted to triangles.

Based on how quickly you move, you could do small sections, or larger
sections. Generate the data sets, arrange them in 3D space, and make
some videos rotating them about on different axes.

It might also be interesting to see what 3D forms are created. It
might also be interesting to see what volumetric info there is there.
Maybe it's something that can be integrated, or run a derivation on
to see if anything looks interesting on plots or graphs. Maybe the
relationship between slopes or points at various locations will give
a way to mathematically calculate all prime numbers. :-)

Thank you,
Rick C. Hodgin

[Kenny McCormack]

In article <607620a7-fcea-4690...@googlegroups.com>,

Rick C. Hodgin <rick.c...@gmail.com> wrote:
>Chris,
>
>I saw this video today and thought of something:
>
> https://www.youtube.com/watch?v=vfteiiTfE0c
>

Does God approve of "fractals"? It sounds dirty to me.

--
b w r w g y b r y b

[Rick C. Hodgin]

God approves of all things He created or ordained. It is sin that
is the issue with all things, Kenny, and it is sin that will be
judged. It's why He gave us Jesus ... to take our sin away so we
wouldn't be judged.

[Chris M. Thomasson]

On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:
> Chris,
>
> I saw this video today and thought of something:
>
> https://www.youtube.com/watch?v=vfteiiTfE0c

I am watching it right now: about 36% in and its great so far. Thank you
for the link Rick! I really do appreciate it. :^D

> As the morphing takes place through raised powers, it seems to describe
> something that could be aligned as a series of 2D images set like slices
> of bread, creating a 3D structure by tying specific points from each
> slice to the next, producing quads, which are converted to triangles.

Indeed; it works out quite nicely. Spreading out the slices and
connecting specific points with lines between two adjacent slices, can
create a very interesting 3d geometry indeed: existing in between the
slices.

Not quite this idea, however and fwiw, I have used the volume comprised
of 2d slices created from many "custom" Julia sets of mine. Well, here
is some experimental output I managed to reap:

http://siggrapharts.ning.com/photo/alien-anatomy

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17412

All of these 3d forms are created through a stack of 2d renderings. Here
is a strange insectoid face created from my experimental field based DLA
algorithm:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20574

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17491

The DLA algorithm can be run online here:

http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test

Wrt some of my most recent work, here is a highly experimental ShaderToy
program that creates 2d slices of a 3d vector field, complete with
click-and-drag ability. Do not run this on a phone, but if your on a
desktop, go here and click in the GPU animation:

https://www.shadertoy.com/view/lljyDm

> Based on how quickly you move, you could do small sections, or larger
> sections. Generate the data sets, arrange them in 3D space, and make
> some videos rotating them about on different axes.

I have to agree with this. There are so many different methods to "tap
into" the 3d volumetric space. Thanks for your interest Rick.

> It might also be interesting to see what 3D forms are created. It
> might also be interesting to see what volumetric info there is there.
> Maybe it's something that can be integrated, or run a derivation on
> to see if anything looks interesting on plots or graphs. Maybe the
> relationship between slopes or points at various locations will give
> a way to mathematically calculate all prime numbers. :-)

The "alien thing" I "reaped" from the Seahorse valley is still pretty
darn strange to me. Also, check this out:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19331

The field is deterministic, not random.

;^)

[Chris M. Thomasson]

lol! :^)

[Chris M. Thomasson]

On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:

> Chris,
>
> I saw this video today and thought of something:
>
> https://www.youtube.com/watch?v=vfteiiTfE0c

Fwiw, when you get some time go ahead and watch:

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

Imvho, its very nice.

[Chris M. Thomasson]

Well, actually, Imvvv(...)ho, God just might use fractals from time to
time. As well as origami.

[bartc]

It did look a bit naughty from 6:03

[Chris M. Thomasson]

On 10/27/2017 1:50 PM, Chris M. Thomasson wrote:
> On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:
>> Chris,
>>
>> I saw this video today and thought of something:
>>
>>      https://www.youtube.com/watch?v=vfteiiTfE0c
>
> Fwiw, when you get some time go ahead and watch:
>
> https://youtu.be/9gk_8mQuerg
> (The dark side of the Mandelbrot set)
>
> Imvho, its very nice.

Sorry for all of the posts, however, the video mentions BuddhaBrot's,
fwiw Rick, check this out:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17279

Fwiw, to make this more on topic wrt C, well, here are some simple C
programs:

https://groups.google.com/d/topic/comp.lang.c/YnEcpH-vRxw/discussion

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

;^)

[john.l...@gmail.com]

On Friday, October 27, 2017 at 11:38:22 AM UTC-7, Kenny McCormack wrote:
> In article <607620a7-fcea-4690...@googlegroups.com>,

> Rick C. Hodgin <r...n@gmail.com> wrote:
> >Chris,
> >
> >I saw this video today and thought of something:
> >
> > https://www.youtube.com/watch?v=vfteiiTfE0c
> >
>
> Does God approve of "fractals"? It sounds dirty to me.
>
> --
> b w r w g y b r y b

Unnecessary and unhelpful. Let's not encourage Rick to misbehave, on those occasions when he actually respects the newsgroup charter.

[Chris M. Thomasson]

On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:

Fwiw, I am getting ready to post a per-alpha version of my algorithm in
GLSL that can create slices of a volumetric rendering for basically any
escape time fractal. Here is an experimental 4k rendering:

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

The grid in this low iteration count of the set can be used as a base to
"connect" it to a higher iteration count structure:

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20643

The very nature of it is 3d and should look very strange. Like a bunch
of fractal twisting towers in wire frame separating each slice of a
volumetric rendering of a given fractal formula.

[Chris M. Thomasson]

On 11/13/2017 3:06 PM, Chris M. Thomasson wrote:
> On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:
>> Chris,

[...]

> Fwiw, I am getting ready to post a per-alpha version of my algorithm in
> GLSL that can create slices of a volumetric rendering for basically any
> escape time fractal. Here is an experimental 4k rendering:
>
> https://plus.google.com/101799841244447089430/posts/BVjurtCMLer
>
> The grid in this low iteration count of the set can be used as a base to
> "connect" it to a higher iteration count structure:
>
> http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20643
>
> The very nature of it is 3d and should look very strange. Like a bunch
> of fractal twisting towers in wire frame separating each slice of a
> volumetric rendering of a given fractal formula.

Here is an initial pre-alpha try in GLSL:

https://www.shadertoy.com/view/XtjcDd

Can you get it work? It seems to dance...

;^)

[Rick C. Hodgin]

It looks like a really cool modulated audio channel visualizer.

--
Rick C. Hodgin

[Chris M. Thomasson]

Thank you for taking a look at my experiment Rick. :^)

Try setting CT_N in line 13 to a 2. This creates a binary wave. Try
setting CT_N to 1. This is the "root or origin" wave. Zero seems to be
the pure void of solid light, every slice looks like a sheet of paper.
Also, be sure to click-and-drag a point around from time to time.

Fwiw, wrt the base mod coloring, check out line 164 in the ct_vpixel
function.

You should give ShaderToy a go, from time to time. The program is run on
a per-pixel basis.

It allows one to quickly model different algorithms. For instance, check
this out:

https://www.shadertoy.com/view/XtscDl
(my experimental exploding Mandelbrot set algorithm)

Read at least the first 14 lines of code to see where it came from:
______________________________
// Very nice coloring, zoom and anti-aliasing by:

// inigo quilez - iq/2013
// License Creative Commons Attribution-NonCommercial-ShareAlike 3.0
Unported License.


// See here for more information on smooth iteration count:
//
// http://iquilezles.org/www/articles/mset_smooth/mset_smooth.htm


// Exploding Pulsing Mandelbrot Set by Chris M. Thomasson
// Orbit trap color by Chris M. Thomasson
// http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20582
______________________________


Fwiw, creating my vector field experiment in C99 wrt a program that
generates PPM's can be done in a 100% portable way. In fact, I can use
my existing code:

https://groups.google.com/d/topic/comp.lang.c/YnEcpH-vRxw/discussion

https://o18i.imgup.net/ct_cipher_b95e.jpg
(result of code linked to above)

Okay, so a C99 implementation that pushes out PPM's has to be on topic
here right?

:^)

[Chris M. Thomasson]

On 11/14/2017 1:37 PM, Chris M. Thomasson wrote:
> On 11/13/2017 6:44 PM, Rick C. Hodgin wrote:
>> On Monday, November 13, 2017 at 9:28:28 PM UTC-5, Chris M. Thomasson
>> wrote:
>>> On 11/13/2017 3:06 PM, Chris M. Thomasson wrote:
>>>> On 10/27/2017 8:48 AM, Rick C. Hodgin wrote:
>>>>> Chris,
[...]

> Okay, so a C99 implementation that pushes out PPM's has to be on topic
> here right?

Some C99 code:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/RIFC/ct_bin_ppm.c

[Chris M. Thomasson]

On 11/13/2017 6:44 PM, Rick C. Hodgin wrote:

Fwiw, might be on the way to getting a 3d Mandelbrot from 2d slices.
Here is a link to an initial and crude volumetric rendering:

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

Still highly experimental and very fun to work on. Btw, thank you for
your interest Rick. :^)

[Chris M. Thomasson]

On 11/13/2017 6:44 PM, Rick C. Hodgin wrote:

Fwiw Rick, Check this one out:

https://www.shadertoy.com/view/XtjcDd

Visualizing a dynamic field of the low iteration Mandelbrot set. You can
click-and-drag a point. Also, be sure to play with line 14 in the code
and set CT_N to 1,2,3,4, ect...

;^)