A paper on my Funny Fractal Encryption toy...

[Chris M. Thomasson]

Well, I am going to write a paper that is quantified into several
units comprising, so far:


plain_char = A character in the plain_text.
cipher_char = A character in the cipher_text.
udf = user defined formula.


[0][0] = Intro into Complex Numbers, along with some examples.

[0][1] = Intro into programming Fractals, along with some
examples.

[0][2] = Explain how a Fractal driven cipher just might be
interesting.



[1][0] = Intro into Coloring Algorithms, along with some examples.

[1][1] = Brief explanation how coloring algorithms can possibly
help out with a ciphers keys and cipher_text itself.

[1][2] = Explain how the public and private keys can be based on
fractal formulas and coloring algorithms.

[1][3] = Explain how even if a public key uses a different formula,
it still uses an offset location from the private key.



[2][0] = Intro into the Funny Fractal Cipher.

[2][2] = Explain how fractals and ciphers can work together.

[2][2] = Explain how a public and private key might look in a simple
example exchange between Alice and Bob using a small alphabet.

[2][2] = Explain how to mathematically tie a given plain_char with the
output of a given fractal formula.

[2][3] = Explain how to use different coloring algorithms as parts of
the public and private keys.

[2][4] = Explain how to achieve an “avalanche effect” by using a (rather
crude at the moment) iterative form of Cantor pairing and xor.

[2][5] = Explain how to use modular arithmetic to compose a cipher_char
for a given plain_char.

[2][6] = Explain how to reverse the modular arithmetic to compose a
plain_char for a given cipher_char.



[3][0] = Intro into possibly breaking the Cipher.

[3][1] = Explain some cryptoanalysis techniques and how they might be
to break it.

[3][2] = Explain a possible fractal based cryptoanalysis technique I am
thinking about.



A possible setup for the keys:


// a public key formula and a location.
struct public_key
{
char fbuf[16]; // this is a udf for a public key in a a compacted form.
double xmin; // min bound of the x-axis.
double xmax; // max bound of the y-axis.
double ymin;// min bound of the y-axis.
double ymax;// max bound of the y-axis.
};


// a private key formula and iteration count.
struct private_key
{
char fbuf[256]; // this is a udf for a private key in an expanded form.
unsigned int icount; // this is the iteration count we will use for the
udf.
double xmin; // min bound of the x-axis.
double xmax; // max bound of the y-axis.
double ymin;// min bound of the y-axis.
double ymax;// max bound of the y-axis.
};


I was thinking of a little function parser for udf's. How about something
like this for starters:

c = complex plane position
z = iterative location in the complex plane
p(p0, p1) = pow(p0, p1)
a(p0, p1) = p0 + p1

So, z^2 + c could be something like:

apz2c

which expands into:

a(p(z, 2), c)

which expands into:

z^2 + c



lol...


Anyway, what do you think?

This is a very crude outline, but still, what am I missing here?

Humm...

[Ben Bacarisse]

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

> [1][2] = Explain how the public and private keys can be based on
> fractal formulas and coloring algorithms.

<snp>

> This is a very crude outline, but still, what am I missing here?

All I want is a description of the cipher. Most of the sections you
outline above seem to be too general or very specific indeed.

But one thing stands out. Your description suggests it's a
public/private key system. Do you mean that in the conventional sense?
If so, how are the two keys related -- i.e. what is the problem that
both links the two keys and yet makes them impractical to compute from
public data?

I notice that when I run the program to encrypt a file it prints the
command line (basically a bunch of numbers) that must be used to decrypt
it. Do I have to get these numbers to the recipient? How is that
supposed to work?

--
Ben.

[wizzofozz]

On 23-8-2015 17:13, Ben Bacarisse wrote:
> "Chris M. Thomasson" <nos...@nospam.nospam> writes:
> <snip>
>

> But one thing stands out. Your description suggests it's a
> public/private key system. Do you mean that in the conventional sense?

I haven't read the entire other thread but he writes "Bob and Alice
decide on a private key K0 consisting ".

AFAIK in PKC you don't agree on a private key with the other party
because Alice and Bob have their own private keys which they don't share
with each other.
But I guess you know this.

Ozz

[Ben Bacarisse]

wizzofozz <oscxxx...@gmail.com> writes:

> On 23-8-2015 17:13, Ben Bacarisse wrote:
>> <snip>
>>
>> But one thing stands out. Your description suggests it's a
>> public/private key system. Do you mean that in the conventional sense?
>
> I haven't read the entire other thread but he writes "Bob and Alice
> decide on a private key K0 consisting ".

Sure. That's why I flagged up the text you snipped ("Explain how the

public and private keys can be based on fractal formulas and coloring

algorithms") and asked if this was conventional terminology. If it is,
it conflicts with other remarks (such as the quote you cited) and if not
it needs to be explained.

There is something asymmetric going on here because the encrypt command
is not the same as the decrypt command, but I don't think it's PKC. Yet
there is talk of public and private keys. So I'm a bit confused.

<snip>
--
Ben.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:87egiu5...@bsb.me.uk...

Hope this help a bit...


I will stay completely within the realm of the current code as-is:


Unfortunately, the private key is hard coded as a power of two
Julia set with a custom location, color monitor and orbit trap.
This fractal produces a bitmap that can be rendered, printed and
hung on a wall. The bitmap is the private key itself for a private
key is a fractal formula.

A public key is a simple offset into the private key. The numbers
you see when encrypting a file is said offset in the form of a
location. This produces a new bitmap of the same fractal as the
private key, but in a different location. The offset is generated
by the nature of the plaintext, which ends up producing a fairly
decent avalanche effect. If I used the private key only, well, then
a small change in the plain text would produce only a single change
in the ciphertext. So, a hopefully a public key will be a fairly
unique location within the private key, and end up creating a new
bitmap.

The bitmap generated by the private and public keys is used as a pad
to create a cipher by using modular arithmetic on a plaintext char
along with its associated ciphertext char.


So, I create a special public key that defines the location of a
plaintext within the private key. The public key can be sent across
the wire because it is only a simple location into the private key.
A given ciphertext. So, the public key can be sent as plaintext along
with its ciphertext. The public key is “useless” without the private
key.


A simple correspondence between Alice and Bob:

Bob and Alice decide on a private key, lets just say its the exact same
one that is hard coded into the example code.

Bob creates some plaintext, and gains a special public key. Remember that
a public key is an offset into the private one.

Bob encrypts his plaintext with the private and public keys, and sends the
public key and resulting ciphertext across the wire to Alice.

Alice then uses the private key, and the public key to decrypt the
ciphertext
back into Bobs original plaintext.


Sorry if this ends up confusing you even further Ben!

;^(


I wish I had more time for all of this.

[wizzofozz]

Well, as it happens, a few months ago I've been playing with the
mandelbrot set. Since I'm spamming this NG tonight with links to my
server anyway, I'll throw in a couple more:

mijnbrot.png
mijnbrot2.png
mijnbrot3.png
mijnbrot4.png

You can download them at 149.XXX210.1XXX61.6X4 (remove the 'X'-es, put
http:// in front and /mijnbrot4.png behind).

So, now we have established a "private key". What happens now?

<snip>

I will read the snipped part next time, but now we have some numbers to
work with (the axes are contained in the pictures).

Ozz

[wizzofozz]

On 24-8-2015 22:33, Chris M. Thomasson wrote:

>

> A simple correspondence between Alice and Bob:
>
> Bob and Alice decide on a private key, lets just say its the exact same
> one that is hard coded into the example code.
>
> Bob creates some plaintext, and gains a special public key. Remember that
> a public key is an offset into the private one.
>
> Bob encrypts his plaintext with the private and public keys, and sends the
> public key and resulting ciphertext across the wire to Alice.
>
> Alice then uses the private key, and the public key to decrypt the
> ciphertext
> back into Bobs original plaintext.
>

(Maybe others have noticed this. I didn't fully read the other threads)

I tried your cipher like this:

./ff inplain ff.ct.txt 0 -2 0 -1 0
./ff inplain2 ff.ct.txt2 0 -2 0 -1 0
./ff inplain3 ff.ct.txt3 0 -2 0 -1 0

You say the private key is hardcoded in your example code.
So what is the public key? Is it '-2 0 -1 0'?

Anyway, inplain contains many 'A'-s
inplain2 contains many 'B'-s
inplain3 contains 'OZZ'-s

Hexdumps of the resulting ciphers (partially);

00000000 d4 d4 d4 d4 d4 d4 d4 d4 34 ca 3d dc 6b 03 c4 31
|........4.=.k..1|

00000000 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 84 37 b9 63 6b 06
|...........7.ck.|

00000000 e2 ed ed ba cb bd af a7 35 ae bd ed e2 ed aa f3
|........5.......|


So; 'd4' is 'A' in inplain. 'd5' is 'B' in inplain2. 'e2 ed ed' is 'OZZ'
in inplain3. This looks like an undesirable property of your cipher
(known plaintext attack maybe or even frequency count?). Or am I missing
something?

Ozz

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mrg7ec$mvb$1...@dont-email.me...

>> On 24-8-2015 22:33, Chris M. Thomasson wrote:

[...]

> (Maybe others have noticed this. I didn't fully read the other threads)

> I tried your cipher like this:

> ./ff inplain ff.ct.txt 0 -2 0 -1 0
> ./ff inplain2 ff.ct.txt2 0 -2 0 -1 0
> ./ff inplain3 ff.ct.txt3 0 -2 0 -1 0

> You say the private key is hardcoded in your example code.
> So what is the public key? Is it '-2 0 -1 0'?

The fractal formula is hardcoded as-is, however, I forgot that I allowed
one to specify an initial location for encryption. I have been experimenting
with { (-0.5, 0.5 }, ( -0.5, 0.5 ) } so far.

> Anyway, inplain contains many 'A'-s
> inplain2 contains many 'B'-s
> inplain3 contains 'OZZ'-s

> Hexdumps of the resulting ciphers (partially);

> 00000000 d4 d4 d4 d4 d4 d4 d4 d4 34 ca 3d dc 6b 03 c4 31
> |........4.=.k..1|

> 00000000 d5 d5 d5 d5 d5 d5 d5 d5 d5 d5 84 37 b9 63 6b 06
> |...........7.ck.|

> 00000000 e2 ed ed ba cb bd af a7 35 ae bd ed e2 ed aa f3
> |........5.......|


> So; 'd4' is 'A' in inplain. 'd5' is 'B' in inplain2. 'e2 ed ed' is 'OZZ'
> in inplain3. This looks like an undesirable property of your cipher
> (known plaintext attack maybe or even frequency count?). Or am I missing
> something?

This is not good. I am going to try and reproduce your results with three
separate files of (A)'s, (B)'s and (OZZ)'s respectively.

I feel like a complete moron for not testing wider axes. Can you try
encrypting the same files using smaller locations, like -0.5 0.5 -0.5 0.5?
Please, I really appreciate all of the valuable information you can reap!


Thank you.


BTW, your handle “wizzofozz” reminds me of a possible character within the
universe of Zork.


http://www.thezorklibrary.com/history/00-encyclopedia.html

Anyway, thanks again!!!

:^D

[Ben Bacarisse]

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

> A simple correspondence between Alice and Bob:
>
> Bob and Alice decide on a private key, lets just say its the exact same
> one that is hard coded into the example code.
>
> Bob creates some plaintext, and gains a special public key. Remember that
> a public key is an offset into the private one.
>
> Bob encrypts his plaintext with the private and public keys, and sends the
> public key and resulting ciphertext across the wire to Alice.
>
> Alice then uses the private key, and the public key to decrypt the
> ciphertext
> back into Bobs original plaintext.
>
> Sorry if this ends up confusing you even further Ben!

I would suggest you change the terms. The apparently ordinary phrases
"public key" and "private key" have strong technical meanings in this
context and you are not using them in that way.

Using more usually terms: there is a shared key between Alice and Bob,
but the encryption algorithm is "salted" with some data (you call it the
special public key) in a way as yet unexplained. That is, of course,
only true if I've got your drift.

--
Ben.

[Chris M. Thomasson]

Ahh. I see here. The character count for a 75072 byte file filled
with (A)'s at the axes of { (-2, 0), (-1, 0) } spikes at char value
212:


212 10510 0.139999

This is NOT GOOD!!!


Let me try the same file of (A)'s using a smaller location
{ (-0.5, 0.5), (-0.5, 0.5) }.

Well, now I cannot find any spike and all of the frequencies are
around: 0.003796. I makes a fairly flat line.

The line wrt the dimensions you provided at { (-2, 0), (-1, 0) }
creates a MASSIVE SPIKE.

Thank you for pointing it out!

[Chris M. Thomasson]

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

> Ahh. I see here. The character count for a 75072 byte file filled with
> (A)'s at the axes of { (-2, 0), (-1, 0) } spikes at char value 212:


> 212 10510 0.139999

> This is NOT GOOD!!!

I just thought of something that has to be fairly profound wrt the nature of
the cipher itself.

It sure seems as of the frequency distibution is strongly infulenced by the
zoom level.

Wizzofoz kindly pointed out that zooming out from -0.5 0.5 -0.5 0.5 creates
very poor ciphertext
wrt the current code.

I observed the problem, and noticed that things get "almost" proportionally
better when one zooms in.

The location that Wizzofoz gave makes the Julia set fractal small and off to
the right wrt a rendering. Apparently,
You need to zoom in further in order to get better ciphertext. Well, I can
see it now. Zooming in of fractals is the
point, and this cipher is based on fractals. Well, there you go!

This tie between zoom levels and quality of ciphertext is EXTREMELY
INTERESTING TO ME!!!!

Thank you all!

this group is awesome.

[Chris M. Thomasson]

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

> Ahh. I see here. The character count for a 75072 byte file filled with
> (A)'s at the axes of { (-2, 0), (-1, 0) } spikes at char value 212:


> 212 10510 0.139999

> This is NOT GOOD!!!

FWIW, I am making heavy use of the following handy little program:

http://www.fourmilab.ch/random/

Its working great so far.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:874mjob...@bsb.me.uk...

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

[...]

> > Sorry if this ends up confusing you even further Ben!

> I would suggest you change the terms. The apparently ordinary phrases
> "public key" and "private key" have strong technical meanings in this
> context and you are not using them in that way.

Will do. thanks.

> Using more usually terms: there is a shared key between Alice and Bob,
> but the encryption algorithm is "salted" with some data (you call it the
> special public key) in a way as yet unexplained. That is, of course,
> only true if I've got your drift.

This sounds great.

BTW, the function in the code that creates the public key is
(ffe_encrypt_first_pass).

I am using cantor paring to try a get a unique number based off
the contents of the plaintext.

I have some other stuff to do now, but at least some people are
starting to learn how this thing works.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrgdbg$11m$1...@speranza.aioe.org...
[...]

> BTW, the function in the code that creates the public key is
> (ffe_encrypt_first_pass).

Ummm. I mean this creates the salt for the shared key between Bob and Alice.

;^)

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mrg7ec$mvb$1...@dont-email.me...

> > On 24-8-2015 22:33, Chris M. Thomasson wrote:

[...]

> > (Maybe others have noticed this. I didn't fully read the other threads)

> I tried your cipher like this:

> ./ff inplain ff.ct.txt 0 -2 0 -1 0
> ./ff inplain2 ff.ct.txt2 0 -2 0 -1 0
> ./ff inplain3 ff.ct.txt3 0 -2 0 -1 0

I changed the program from a Julia set to the Mandelbrot set and got much
better
results from your location.

You can comment out a single line of code in order to test this for
yourself.

Comment out Line 174 in the (ffe_cplane_iterate) function in order to make
it use the Mandelbrot set.

____________________________________________

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 */
____________________________________________

Comment out the last line.



Can you try your example files after making this change?


Thanks.

[wizzofozz]

On 25-8-2015 1:38, Chris M. Thomasson wrote:
>> "wizzofozz" wrote in message news:mrg7ec$mvb$1...@dont-email.me...
>
>>> On 24-8-2015 22:33, Chris M. Thomasson wrote:
> [...]
>

> I feel like a complete moron for not testing wider axes. Can you try
> encrypting the same files using smaller locations, like -0.5 0.5 -0.5 0.5?
> Please, I really appreciate all of the valuable information you can reap!
>

I tried it with the "smaller locations" (there must be a better term for
this. Anyone?).
The obvious relations between the different plaintexts and ciphertexts
are no longer there as far as I can tell. At least they're less obvious.

When can we expect the paper? (otherwise I'll need to figure out how
your cipher works by wading through old posts)

Ozz

[Ben Bacarisse]

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

>> "Ben Bacarisse" wrote in message news:874mjob...@bsb.me.uk...
>
>> > "Chris M. Thomasson" <nos...@nospam.nospam> writes:
> [...]
>> > Sorry if this ends up confusing you even further Ben!
>
>> I would suggest you change the terms. The apparently ordinary phrases
>> "public key" and "private key" have strong technical meanings in this
>> context and you are not using them in that way.
>
> Will do. thanks.
>
>> Using more usually terms: there is a shared key between Alice and Bob,
>> but the encryption algorithm is "salted" with some data (you call it the
>> special public key) in a way as yet unexplained. That is, of course,
>> only true if I've got your drift.
>
> This sounds great.

I had a look at the code to see if I could work it out for myself but I
got distracted because the C is rather convoluted. For example you
have, in at least two places, the pattern:

for (;;) {
x = f(...);
if (x != 0) {
<stuff>
continue;
}
break;
}

There is a common C idiom for this:

while ((x = f(...)) != 0) {
<stuff>
}

Your input routine took some checking (I've edited a newline in the
printf). Where you have:

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!\n");

return 0;
}

I think you could write:

self->bufsz = fread(self->buf, 1, FFE_BUF_NMAX, file);
if (ferror(file))
printf("fread error!\n");
return self->bufsz;

But there are two more serious things. First, you access an unset
element the input buffer. In this loop:

for (i = 0; i < rbytes; i += 2) {
/* use buf[i] and buf[i + 1]... */
}

when rbytes is odd (as it can be in the final read) you access an unset
element of the array (though it may have been set by the previous
read). You don't want to be doing this.

The second, less serious, thing is that the program seems to be a little
'fragile'. I altered a line (388) from (essentially)

x = x + y + z;

to

x += y + z;

(all are type double) and the program produced different output. That's
not entirely unexpected, but you would ideally want a program like this
to be robust against such changes. You could find it behaving
differently tomorrow if the compiler decides to treat floating point
calculations sightly differently.

I hope this helps. Sorry I got no closer to seeing how it actually
works, but I'll take another look soon.

<snip>
--
Ben.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:87twrn9...@bsb.me.uk...

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

> >> "Ben Bacarisse" wrote in message news:874mjob...@bsb.me.uk...
> >
> >> > "Chris M. Thomasson" <nos...@nospam.nospam> writes:
> > [...]
> >> > Sorry if this ends up confusing you even further Ben!
> >
> >> I would suggest you change the terms. The apparently ordinary phrases
> >> "public key" and "private key" have strong technical meanings in this
> >> context and you are not using them in that way.
> >
> > Will do. thanks.
> >
> >> Using more usually terms: there is a shared key between Alice and Bob,
> >> but the encryption algorithm is "salted" with some data (you call it
> >> the
> >> special public key) in a way as yet unexplained. That is, of course,
> >> only true if I've got your drift.
> >
> > This sounds great.

> I had a look at the code to see if I could work it out for myself but I
> got distracted because the C is rather convoluted.

Yep. I have a fairly bad problem with verbosity and rather excessive use
of vertical space when I am coding in the pre-alpha stage.

;^(

> For example you have, in at least two places, the pattern:

> for (;;) {
> x = f(...);
> if (x != 0) {
> <stuff>
> continue;
> }
> break;
> }

> There is a common C idiom for this:

> while ((x = f(...)) != 0) {
<stuff>
> }

Yup! I was using the for loop for some other stuff that I deleted for the
current posted code.

> Your input routine took some checking (I've edited a newline in the
> printf). Where you have:

[...long winded loop...]

> I think you could write:

> self->bufsz = fread(self->buf, 1, FFE_BUF_NMAX, file);
> if (ferror(file))
> printf("fread error!\n");
> return self->bufsz;

Okay. Well, I am under the impression that (fread) can return a buffer
size that is lower than (FFE_BUF_NMAX) if it hit the end of the file.
Therefore, I check for an error, then check to see if is the end of the
file. AFAICT, hitting EOF during a large read on an unknown file is not
a error per-se? Where am I going wrong here?

Damn.

> But there are two more serious things. First, you access an unset
> element the input buffer. In this loop:

> for (i = 0; i < rbytes; i += 2) {
> /* use buf[i] and buf[i + 1]... */
> }

> when rbytes is odd (as it can be in the final read) you access an unset
> element of the array (though it may have been set by the previous
> read). You don't want to be doing this.

I agree. Luckily, this is in the first pass where the “salt” is created.
So, the problem is that if (rbytes) is an odd number it will fail to take
that last character into account. If the (rbytes) is 1, well, then it will
completely ignore it altogether. I will fix this.

Humm... At least it does not overrun the damn buffer boundary! However,
it is still a problem.

;^o

> The second, less serious, thing is that the program seems to be a little
> 'fragile'. I altered a line (388) from (essentially)

> x = x + y + z;

> to

> x += y + z;

> (all are type double) and the program produced different output. That's
> not entirely unexpected, but you would ideally want a program like this
> to be robust against such changes. You could find it behaving
> differently tomorrow if the compiler decides to treat floating point
> calculations sightly differently.

Now this is odd to me. Humm... First of all, I will see if I can reproduce
the results on my end wrt line (388).


> I hope this helps.

This help me out a hell of a lot Ben.

Thanks! :^)

> Sorry I got no closer to seeing how it actually works, but I'll take
> another
>look soon.

I need to explain it MUCH better. Unfortunately, I do not have a lot of free
time to spend on my toys...

;^)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrikm5$br0$1...@speranza.aioe.org...

>> "Ben Bacarisse" wrote in message news:87twrn9...@bsb.me.uk...

[...]

>> Your input routine took some checking (I've edited a newline in the
>> printf). Where you have:

> [...long winded loop...]

OOPS! The code in (ffe_buf_read) is not a loop! However, it is still long
winded,
so to speak...

;^)

[Ben Bacarisse]

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

>> "Ben Bacarisse" wrote in message news:87twrn9...@bsb.me.uk...
<snip>

>> Your input routine took some checking (I've edited a newline in the
>> printf). Where you have:
>
> [...long winded loop...]
>
>> I think you could write:
>
>> self->bufsz = fread(self->buf, 1, FFE_BUF_NMAX, file);
>> if (ferror(file))
>> printf("fread error!\n");
>> return self->bufsz;
>
> Okay. Well, I am under the impression that (fread) can return a buffer
> size that is lower than (FFE_BUF_NMAX) if it hit the end of the file.
> Therefore, I check for an error, then check to see if is the end of the
> file. AFAICT, hitting EOF during a large read on an unknown file is not
> a error per-se? Where am I going wrong here?

Your code is not wrong. It's just a fussy way to do it.

However, I see my code is not *exactly* the same as your. To be the
same I should have written:

self->bufsz = fread(self->buf, 1, FFE_BUF_NMAX, file);
if (ferror(file)) {
printf("fread error!\n");

return 0;
}
return self->bufsz;

but what I wrote is not a problem (and could be said to be better).
Returning the short length on a read error (rather than 0) is fine and,
as you can see, simpler. The data read, even on error, are real bytes
so there is no harm in processing them.

But whether you return 0 or the byte count on error is not really the
point. The point is that you don't need three tests. The only
situation that needs to be tested for is error, and that is only because
you want to print a message and return a zero count. Your program would
work just fine if the whole function were:

return fread(self->buf, 1, FFE_BUF_NMAX, file);

<snip>

>> But there are two more serious things. First, you access an unset
>> element the input buffer. In this loop:
>
>> for (i = 0; i < rbytes; i += 2) {
>> /* use buf[i] and buf[i + 1]... */
>> }
>
>> when rbytes is odd (as it can be in the final read) you access an unset
>> element of the array (though it may have been set by the previous
>> read). You don't want to be doing this.
>
> I agree. Luckily, this is in the first pass where the “salt” is created.
> So, the problem is that if (rbytes) is an odd number it will fail to take
> that last character into account. If the (rbytes) is 1, well, then it will
> completely ignore it altogether. I will fix this.

No. If rbytes is 1 you inspect and use buf[0] and buf[1] but buf[1] was
not set by the latest file read. It may, for exmaple, be left over from
the last read so if you change the buffer size, the output will change.
The output should depend only on the input, not on the size of the
buffer used to read it!

<snip>
--
Ben.

[Chris M. Thomasson]

> "Ben Bacarisse" wrote in message news:87io839...@bsb.me.uk...

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

> >> "Ben Bacarisse" wrote in message news:87twrn9...@bsb.me.uk...

> >> when rbytes is odd (as it can be in the final read) you access an unset
> >> element of the array (though it may have been set by the previous
> >> read). You don't want to be doing this.

[...]

> > I agree. Luckily, this is in the first pass where the “salt” is created.
> > So, the problem is that if (rbytes) is an odd number it will fail to
> > take
> > that last character into account. If the (rbytes) is 1, well, then it
> > will
> > completely ignore it altogether. I will fix this.

> No. If rbytes is 1 you inspect and use buf[0] and buf[1] but buf[1] was
> not set by the latest file read. It may, for exmaple, be left over from
> the last read so if you change the buffer size, the output will change.
> The output should depend only on the input, not on the size of the
> buffer used to read it!

DOH! You are write, and I am utterly wrong!

:^o

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrj6ep$if0$1...@speranza.aioe.org...

> > "Ben Bacarisse" wrote in message news:87io839...@bsb.me.uk...

[...]

> DOH! You are write, and I am utterly wrong!

Ummmm.... That should read:

DOH! You are RIGHT, and I am utterly wrong!


This problem will be dealt with accordingly.

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mri4cc$a10$1...@dont-email.me...

> > On 25-8-2015 1:38, Chris M. Thomasson wrote:
> > I feel like a complete moron for not testing wider axes. Can you try
> > encrypting the same files using smaller locations, like -0.5 0.5 -0.5
> > 0.5?
> > Please, I really appreciate all of the valuable information you can
> > reap!

> tried it with the "smaller locations" (there must be a better term for
> this. Anyone?).

Humm... Need to think on that one.

> The obvious relations between the different plaintexts and ciphertexts
> are no longer there as far as I can tell. At least they're less obvious.

For me, they are definitely less obvious. The neat thing is that the quality
of the ciphertext seems to be directly tied to the complexity of its final
location, after zoom has been applied. So, the more beautiful and complex a
rendering is, happens to be directly tied to the quality of the cipher,
almost akin to weak and strong passwords, so to speak.

Humm...

> When can we expect the paper? (otherwise I'll need to figure out how
> your cipher works by wading through old posts)

I am starting to draft out some initial paragraphs. Unfortunately, I am
using
portions of my free time to do this. I am not getting paid, and have no
deadlines.
Your work wrt the location { (-2, 0), (-1, 0) } means that I simply have to
clearly explain this MAJOR caveat in the paper. The paper itself should be
ready before the end of this year, but I will be posting drafts, even down
to
the paragraph level to this awesome group!


BTW, I took a look at some of the renderings you created. These are nice,
and are essential to understanding my cipher. One point, I notice that you
are
coloring the points that do not escape as black. Well, try to think of other
ways to color the inside of the Mandelbrot. I am using an orbit trap, but
there are many, many other methods that will effect the quality of the
fractal
cipher.


FWIW, here is a fractal I created using inverse complex iteration:

http://fractallife247.deviantart.com/art/Heavenly-Visions-527680984


Here is one I created using my “field line” algorithm:

http://fractallife247.deviantart.com/art/Dragons-521725486


FWIW, here is a description and discussion wrt the field line algorithm I
created:

http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration


Enjoy!

;^)

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mri4cc$a10$1...@dont-email.me...

> > On 25-8-2015 1:38, Chris M. Thomasson wrote:
> > I feel like a complete moron for not testing wider axes. Can you try
> > encrypting the same files using smaller locations, like -0.5 0.5 -0.5
> > 0.5?
> > Please, I really appreciate all of the valuable information you can
> > reap!

> tried it with the "smaller locations" (there must be a better term for
> this. Anyone?).

Humm... Need to think on that one.

> The obvious relations between the different plaintexts and ciphertexts
> are no longer there as far as I can tell. At least they're less obvious.

For me, they are definitely less obvious. The neat thing is that the quality
of the ciphertext seems to be directly tied to the complexity of its final
location, after zoom has been applied. So, the more beautiful and complex a
rendering is, happens to be directly tied to the quality of the cipher,
almost
akin to weak and strong passwords, so to speak.

Humm...

> When can we expect the paper? (otherwise I'll need to figure out how
> your cipher works by wading through old posts)

[Chris M. Thomasson]

>"wizzofozz" wrote in message news:mri4cc$a10$1...@dont-email.me...

>> On 25-8-2015 1:38, Chris M. Thomasson wrote:

[...]

FWIW, I managed to get one of my renderings in second place over on:

http://siggrapharts.ning.com/photo/photo/listFeatured

The name of my image is entitled "Alien Anatomy".

I created many slices and used a volumetric render to visualize them
as a single object.

:^)

[wizzofozz]

On 26-8-2015 21:30, Chris M. Thomasson wrote:
>
>> "wizzofozz" wrote in message news:mri4cc$a10$1...@dont-email.me...
>
>> > On 25-8-2015 1:38, Chris M. Thomasson wrote:
>
> FWIW, here is a fractal I created using inverse complex iteration:
>
> http://fractallife247.deviantart.com/art/Heavenly-Visions-527680984
>

That one is awesome! It reminds me a bit of those hubble telescope
nebula images. I didn't know you could get that kind of images.

>
> Here is one I created using my “field line” algorithm:
>
> http://fractallife247.deviantart.com/art/Dragons-521725486
>

Nice one too! How long does it take to calculate?

For my little tries I used a 'classic' escape time algorithm as
described on wikipedia. Implementation of the code to decide whether a
point is in the mandelbrot set or not is about 10 lines of python code.
It took me longer to figure out how to use the python drawing library.

For a short movie (zooming in) of 10 secs 10 fps (100 images of 1MB
(1000*1000 px)) it took a few hour to calculate. IIRC the empty parts of
the images take the longest to calculate (but that's logical thinking
about it).


You're right about the black in the middle of the mandelbrot. I just
think in 'in set' and 'out set' and if 'in set' I check how many
iterations it took me to determine that (or was it the other way
around?). The black and blue looks a bit like the 'classic' mandelbrot.
I drew it after learning about the blue color set of mathplotlib.

I was thinking about that actually. Could determination whether in/out
the set be used for the cipher? From what I followed in the discussions
you were using floats. Maybe with iteration counts etc you could make it
more like 'discrete mathematics'.

>
> FWIW, here is a description and discussion wrt the field line algorithm I
> created:
>
> http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration
>

I'll check it out.

cheers
Ozz

[wizzofozz]

On 23-8-2015 5:38, Chris M. Thomasson wrote:
> Well, I am going to write a paper that is quantified into several
> units comprising, so far:
>

Maybe those fractal functions could be used for a form of diffie-hellman
key exchange. Have you thought about that?
So, Alice and Bob decide on a point P in the complex plane.
Both choose a random int a and b.
They send each other the outcome of applying the fractal func a and resp
b times on P, giving Pa and Pb.
Alice multiplies Pb with a and Bob Pa with b.
Now they have (Pb)a and (Pa)b which hopefully are the same.

Will look into this more today.

Ozz

[Ben Bacarisse]

wizzofozz <oscxxx...@gmail.com> writes:

> On 23-8-2015 5:38, Chris M. Thomasson wrote:
>> Well, I am going to write a paper that is quantified into several
>> units comprising, so far:
>
> Maybe those fractal functions could be used for a form of diffie-hellman
> key exchange. Have you thought about that?
> So, Alice and Bob decide on a point P in the complex plane.
> Both choose a random int a and b.
> They send each other the outcome of applying the fractal func a and resp
> b times on P, giving Pa and Pb.

To avoid confusion, let's use the standard notation. If the function is
f (from C to C) then f(f(f...f(P))) with n applications is written
f^n(P).

> Alice multiplies Pb with a and Bob Pa with b.
> Now they have (Pb)a and (Pa)b which hopefully are the same.

Here I get confused. I think that by "multiplies" you simply mean more
applications of f. I.e. Alice computes f^a(f^b(P)) and Bob calculates
f^b(f^a(P)). Is that it?

--
Ben.

[wizzofozz]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:

> wizzofozz <oscxxx...@gmail.com> writes:
>
>> They send each other the outcome of applying the fractal func a and resp
>> b times on P, giving Pa and Pb.
>
> To avoid confusion, let's use the standard notation. If the function is
> f (from C to C) then f(f(f...f(P))) with n applications is written
> f^n(P).

Yes, you're correct.

>
>> Alice multiplies Pb with a and Bob Pa with b.
>> Now they have (Pb)a and (Pa)b which hopefully are the same.
>
> Here I get confused. I think that by "multiplies" you simply mean more
> applications of f. I.e. Alice computes f^a(f^b(P)) and Bob calculates
> f^b(f^a(P)). Is that it?

Yes, you're correct again. I was a bit in a hurry and got sloppy.

Unfortunately I haven't spend as much time on it as I would have liked but enough to find a paper discussing fractals for Diffie-Hellmann.

Although I still haven't got much time and somebody else apparently already done it (however more complicated than I envisioned),
I think it's a fun excersise to try. If I have more, will report back.

Ozz

[Ben Bacarisse]

wizzofozz <wizz...@cuckoosnest.colo.transip.net> writes:
<snip>

> Unfortunately I haven't spend as much time on it as I would have liked
> but enough to find a paper discussing fractals for Diffie-Hellmann.

Interesting. Can you post the reference?

<snip>
--
Ben.

[wizzofozz]

Sloppy again. They discuss key exchange using fractals and claim it outperforms Diffie-Hellmann.
Anyway, here's a link to the paper:

http://paper.ijcsns.org/07_book/200702/200702B17.pdf

Ozz

[FromTheRafters]

wizzofozz formulated on Friday :

Thanks for the link.

--
...
For long you live and high you fly
But only if you ride the tide
And balanced on the biggest wave
You race towards an early grave.

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mrq3c5$ud8$1...@dont-email.me...

Thank you very much. I have not really thought about a technique wrt
securely exchanging the
shared formulas/keys.

FWIW, this is exactly what I was looking forward to: Other people trying to
make fractal encryption
better and better!

Now, I think there may be a less complicated method for fractal key
exchange. I have to go to
Carson City to run some errands, but I will get back you when I get back...

;^)

Thanks again Wizzofozz!

:^D

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrqbfo$rbt$1...@speranza.aioe.org...

> > "wizzofozz" wrote in message news:mrq3c5$ud8$1...@dont-email.me...

> >> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> > >> wizzofozz <wizz...@cuckoosnest.colo.transip.net> writes:
> > >> <snip>
> > >> Unfortunately I haven't spend as much time on it as I would have
> > >> liked
> > >> but enough to find a paper discussing fractals for Diffie-Hellmann.

> > > Interesting. Can you post the reference?


> > Sloppy again. They discuss key exchange using fractals and claim it
> > outperforms Diffie-Hellmann.
> > Anyway, here's a link to the paper:

> > http://paper.ijcsns.org/07_book/200702/200702B17.pdf

FWIW, here is a fractal I created that seems to match the one they are
using in the paper (page 304, figure 4):

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


You can only see this if the bailout condition it set very high.

The formula is: Z = C * SIN(Z)

For some reason, I cannot seem to find any mention of a bailout condition in
the paper!

Humm...

[Chris M. Thomasson]

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

>> "wizzofozz" wrote in message news:mrq3c5$ud8$1...@dont-email.me...

Here is the Julia off of the Mandelbrot from:

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

The connection between the two is simply awe inspiring, IMVHO at least.


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

Thanks again Wizzofozz for the inspiration!

:^)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrrbrs$ti$1...@speranza.aioe.org...
[...]

> Here is the Julia off of the Mandelbrot from:
> https://plus.google.com/101799841244447089430/posts/gJiFfRyWwXr
> The connection between the two is simply awe inspiring, IMVHO at least.

Forget the link above... examine the following:

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

Sorry about that non-sense!

;^/


BTW, we would love it if you perhaps thought about joining our fractal group
over on google+?

The more smart people we have, the better!

;^)

[Chris M. Thomasson]

>"wizzofozz" wrote in message news:mrl6d1$tv7$1...@dont-email.me...

>> On 26-8-2015 21:30, Chris M. Thomasson wrote:
>>
>>> "wizzofozz" wrote in message news:mri4cc$a10$1...@dont-email.me...
>>
>>> On 25-8-2015 1:38, Chris M. Thomasson wrote:
>>
>> FWIW, here is a fractal I created using inverse complex iteration:
>>
>> http://fractallife247.deviantart.com/art/Heavenly-Visions-527680984


> That one is awesome! It reminds me a bit of those hubble telescope
> nebula images. I didn't know you could get that kind of images.

Thank you so much. I really do appreciate the fact that you actually
observed it.

FWIW, the underlying method is “totally” described here:

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

>> Here is one I created using my “field line” algorithm:
>>
>> http://fractallife247.deviantart.com/art/Dragons-521725486

>Nice one too! How long does it take to calculate?

This took my piece of shi% I3 Intel crap laptop around 30 minutes to
compute!

;^/

> For my little tries I used a 'classic' escape time algorithm as
> described on wikipedia. Implementation of the code to decide whether a
> point is in the mandelbrot set or not is about 10 lines of python code.
> It took me longer to figure out how to use the python drawing library.

;^)

>For a short movie (zooming in) of 10 secs 10 fps (100 images of 1MB
(1000*1000 px)) it took a few hour to calculate. IIRC the empty parts of
>the images take the longest to calculate (but that's logical thinking
>about it).

FWIW, here is a link to my YouTube Channel:

https://www.youtube.com/channel/UC_DhsJu-AbQ6Msnxdf8z6Kg

Who knows, you might find something in there that just might be a spark
of interest to you, and me!

:^D

>You're right about the black in the middle of the mandelbrot. I just
>think in 'in set' and 'out set' and if 'in set' I check how many
>iterations it took me to determine that (or was it the other way
>around?). The black and blue looks a bit like the 'classic' mandelbrot.
>I drew it after learning about the blue color set of mathplotlib.

Try to think of 'in set' as an opportunity to color at will!

:^)

https://en.wikipedia.org/wiki/Orbit_trap

>I was thinking about that actually. Could determination whether in/out
>the set be used for the cipher? From what I followed in the discussions
>you were using floats. Maybe with iteration counts etc you could make it
>more like 'discrete mathematics'.

I am using the final iteration counts, in out out, for the cipher. An
orbit trap, so to speak.

So, I basically track how far orbits get, then color accordingly with a ton,
damn near infinite, number of algorithms for this exist wrt being inside the
set.

>> FWIW, here is a description and discussion wrt the field line algorithm I
>> created:
>>
>> http://www.fractalforums.com/new-theories-and-research/plotting-field-lines-during-iteration


>I'll check it out.

Thanks!I hope you can use it for yourself.


Okay. This group is neat, and I had a gut feeling that UseNet is not totally
dead!

;^D

[Chris M. Thomasson]

>"Chris M. Thomasson" wrote in message

>news:mrrejp$5nf$1...@speranza.aioe.org...

>>"wizzofozz" wrote in message news:mrl6d1$tv7$1...@dont-email.me...

[...]

>>> Here is one I created using my “field line” algorithm:
>>>
>>> http://fractallife247.deviantart.com/art/Dragons-521725486

>>Nice one too! How long does it take to calculate?

>This took my piece of shi% I3 Intel crap laptop around 30 minutes to
>compute!

I forgot to motion that I created this at a much bigger resolution, then
shrunk
it down in order to gain some CHEAP and DIRTY anti-aliasing.

https://www.fractalus.com/info/antialias.htm

;^/

So 30 minutes at this resolution is representing a larger rendering wrt the
original.

[kg]

Chris M. Thomasson <nos...@nospam.nospam> wrote:
> "wizzofozz" wrote in message news:mrq3c5$ud8$1...@dont-email.me...

>> http://paper.ijcsns.org/07_book/200702/200702B17.pdf
>[...]

>FWIW, this is exactly what I was looking forward to: Other people trying to
>make fractal encryption
>better and better!

I suggest you try to write out carefully what the above paper is doing.

Then you (try to) break it.

--
kg

[Chris M. Thomasson]

Here is a simple rough-rough draft of some "introductory information" for
the
paper I am working on:

______________________________________________________________
This paper presents a possible cipher scheme based on fractal geometry.
The heart of the current algorithm uses information reaped from the
creation of highly intricate renderings of a given fractal formula to
encrypt
a given plaintext. So far, the main setup focuses on two dimensions, but
can be adapted to fit higher dimensional planes.

Let's go ahead and start small here, think of a “standard” power of two
Julia set (Z^2+(-0.75;0.1)) (<refer to figure 1a>) located at a point
(C ) with a value of (-0.75, 0.1). Let us also assume is at a “standard”
escape condition (EC) of (|z| > 2) and randomly chosen iteration count
(IC) of 150. Now, take a look at figure (<refer to figure 1b>) which was
computed with a higher (IC) of 600. Notice how some of the regions colored
in black have vanished? The points that escape the (EC) are colored with a
“color monitor” (CM) according the (IC) that caused the event. This can be
considered the escape time (ET) at which a point (Z) escapes under
iteration.
All the points that do not escape (EC) are colored black. Sometimes, the
value of (IC) has a profound influence on the number of points that escape
or not. For instance, take figures 1a-b into account. Figure 1a has a lot
more voids contained within it, which means that most of its points did not
escape. However, figure 1b has hardly any voids, and is a lot more colorful.
This paper is going to explain how filling in the voids with regard to (EC)
and (IC) can be a very good aspect of the quality of any generated
ciphertext.

[...]
______________________________________________________________


Before I got further, can you help me knock some of the crap out of it?

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msd9oa$9g9$1...@speranza.aioe.org...
[...]
To continue on a bit:
______________________________________________________________
Speaking of starting small, lets go with a simple plaintext
(P) equal to “AAAAAAAAA”. Lets make a square grid around called
the viewport (VP). (P) has 9 letters (PN) so the width (W) and
height (H) of (VP) can be equal to (sqrt(PN)) which creates a 3x3 grid
in which to calculate the fractal the Julia set in figures 1a and 1b.
______________________________________________________________

[Peter Fairbrother]

On 05/09/15 00:33, Chris M. Thomasson wrote:
> Here is a simple rough-rough draft of some "introductory information"
> for the
> paper I am working on:
>
> ______________________________________________________________
> This paper presents a possible cipher scheme based on fractal geometry.
> The heart of the current algorithm uses information reaped from the
> creation of highly intricate renderings of a given fractal formula to
> encrypt
> a given plaintext. So far, the main setup focuses on two dimensions, but
> can be adapted to fit higher dimensional planes.

> Before I got further, can you help me knock some of the crap out of it?

no, but I'll give some pointers. I have not read anything about your
cipher/scheme.


> This paper presents

We present [traditional - "this paper" probably isn't wrong, but ..]

> a possible cipher

a cipher [if it's only a possibility, it isn't worth a paper - do
the work and make it real]

> scheme

?? [is it a cipher or a cipher scheme?]

> based on fractal geometry.

based on fractal geometry.


[is the cipher useful, interesting, secure? why is it worth reading any
more? ]

> The heart of the current

The [heart is superfluous and emo]

> algorithm uses information reaped from

algorithm uses information from [reaped is superfluous and inexact]

> the creation of highly intricate renderings of

[no no no!]

> a given

??shared public?? ??keyed?? [given would imply eg a shared public
fractal, like a shared DH prime. If the fractal is keyed and individual
to each message, say so]

> fractal formula

fractal [why formula?]

> to encrypt a given plaintext.

to encrypt. [obviously you are encrypting a plaintext. I very much
doubt you are only ever encrypting a given plaintext]

> So far, the main setup focuses on two dimensions

We focus on two dimensions [so far is superfluous, the main setup is
superfluous and inexact]

> , but can be adapted to fit higher dimensional planes.

but the method can be adapted to use higher dimension fractals. [no
comma, to fit is inexact and superfluous (sound familiar?), and a plane
is by definition 2D.



so, first rewrite::

We present a cipher (?scheme?) based on fractal geometry. The algorithm
uses information from a (?shared public keyed?) fractal to encrypt. We
focus on two dimensions but the method can be adapted to use higher
dimension fractals.



Now the second sentence is superfluous, in the sense that it doesn't
tell the reader anything new, What information is used?? Why do you use
that information? How does it make a good/interesting/useful cipher?

Is it used just because it is intricate? Just because it's intricate
doesn't mean it's secure, but maybe

"The algorithm uses highly intricate information from a (?shared
public?) fractal to encrypt."

First paragraph should also contain something re [is the cipher useful,
interesting, secure? why is it worth reading any more? ].


-- Peter Fairbrother

[Chris M. Thomasson]

> "Peter Fairbrother" wrote in message news:mshh9f$g4n$1...@dont-email.me...

> > On 05/09/15 00:33, Chris M. Thomasson wrote:
> > Here is a simple rough-rough draft of some "introductory information"
> > for the
> > paper I am working on:
> >
> > ______________________________________________________________

[...]

> > Before I got further, can you help me knock some of the crap out of it?

> no, but I'll give some pointers. I have not read anything about your
> cipher/scheme.

[...]

> ??shared public?? ??keyed?? [given would imply eg a shared public
> fractal, like a shared DH prime. If the fractal is keyed and individual
> to each message, say so]

>> fractal formula

> fractal [why formula?]

Now that I think about it, it is superfluous. However, you are
correct about a fractal being keyed and individual to each message.



[...]

> so, first rewrite::

> We present a cipher (?scheme?) based on fractal geometry. The algorithm
> uses information from a (?shared public keyed?) fractal to encrypt. We
> focus on two dimensions but the method can be adapted to use higher
> dimension fractals.

<intro>

- We present a cipher based on fractal geometry.

- A fractal is keyed and individual to each message.

- Alice and Bob decide on a private fractal F.

- A unique location L is generated for each message M.

- M is encrypted as E using F and L.

- E and L are sent across the wire.

- F and L are used to decrypt.

- We focus on two dimensions but the method can be adapted

to use higher dimension fractals.

- F cannot be derived from L.

[Chris M. Thomasson]

> "Peter Fairbrother" wrote in message news:mshh9f$g4n$1...@dont-email.me...

> > On 05/09/15 00:33, Chris M. Thomasson wrote:
> > Here is a simple rough-rough draft of some "introductory information"
> > for the
> > paper I am working on:
> >
> > ______________________________________________________________

[...]

> > Before I got further, can you help me knock some of the crap out of it?

> no, but I'll give some pointers. I have not read anything about your
> cipher/scheme.

[...]

> ??shared public?? ??keyed?? [given would imply eg a shared public
> fractal, like a shared DH prime. If the fractal is keyed and individual
> to each message, say so]

>> fractal formula

> fractal [why formula?]

Now that I think about it, it is superfluous. However, you are

correct about a fractal being keyed and individual to each message.



[...]

> so, first rewrite::

> We present a cipher (?scheme?) based on fractal geometry. The algorithm
> uses information from a (?shared public keyed?) fractal to encrypt. We
> focus on two dimensions but the method can be adapted to use higher
> dimension fractals.

<intro>

- We present a cipher based on fractal geometry.

- A fractal is keyed and individual to each message.

- Alice and Bob decide on a private fractal F.

- A unique location L is generated for each message M.

- M is encrypted as E using F and L.

- E and L are sent across the wire.

- F and L are used to decrypt.

- We focus on two dimensions but the method can be adapted

to use higher dimension fractals.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mrbf8q$ic3$1...@speranza.aioe.org...

> Well, I am going to write a paper that is quantified into several
> units comprising, so far:

FWIW, I am experimenting with a way of using multiple Julia points during
iteration and am averaging damn near pi wrt Monte Carlo estimation on the
ciphertext. I am getting average of 0.09 error of pi.


Here are some renderings wrt multiple Julia:
__________________________________________
https://plus.google.com/101799841244447089430/posts/Aj91qZRf6DU

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

https://plus.google.com/101799841244447089430/posts/ck3YaX1zhqu
__________________________________________

This means the shared secret key between Alice and Bob can be based on
multiple Julia points.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msnkov$bio$1...@speranza.aioe.org...

> FWIW, I am experimenting with a way of using multiple Julia points during
> iteration and am averaging damn near pi wrt Monte Carlo estimation on the
> ciphertext. I am getting average of 0.09 error of pi.

I forgot to mention that the average error is comparing a bunch of different
plaintext sizes.
I notice that smaller plaintexts can produce "bad results" for pi
estimation, even though the char
distribution is relatively flat...

[Chris M. Thomasson]

Example stats, a given location in a given shared secret fractal:


for a 54060 byte file of all "a":

Monte Carlo value for Pi is 3.133851276 (error 0.25 percent).



for a 12330 byte file of all "a":

Monte Carlo value for Pi is 3.126034063 (error 0.50 percent).


for a 3072 byte file of all "a":

Monte Carlo value for Pi is 3.059701493 (error 2.61 percent).



I can improve these errors by altering the color monitor that
is responsible for coloring the fractal.

[Jakob Bohm]

On 08/09/2015 23:54, Chris M. Thomasson wrote:
> Example stats, a given location in a given shared secret fractal:
>
>
> for a 54060 byte file of all "a":
>
> Monte Carlo value for Pi is 3.133851276 (error 0.25 percent).
>
>
>
> for a 12330 byte file of all "a":
>
> Monte Carlo value for Pi is 3.126034063 (error 0.50 percent).
>
>
> for a 3072 byte file of all "a":
>
> Monte Carlo value for Pi is 3.059701493 (error 2.61 percent).
>
>

I presume that statistical test requires a certain number of input bits
to be meaningful at all.

>
> I can improve these errors by altering the color monitor that is
> responsible for coloring the fractal.

If you can do so, I presume this means the randomness of your output is
not as good as one would expect for encrypted bits (which should look
like 1 Shannon/bit to anyone not knowing the key, even if they know
everything else).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[wizzofozz]

On 5-9-2015 1:33, Chris M. Thomasson wrote:
> Here is a simple rough-rough draft of some "introductory information"
> for the
> paper I am working on:
>

<snip short intro on fractals>

>
> Before I got further, can you help me knock some of the crap out of it?
>

I think people who would want to help you are still waiting on how this
exactly is used in your algorithm. The references to figures 1a and 1b
etc are not so helpful since they're missing ;-)
In the followup post to this one (the one with the 3*3 grid), you start
an example and then suddenly stop. So readers have not much to knock on
except your previously released source code.

Cheers,
Ozz

[Chris M. Thomasson]

> "Jakob Bohm" wrote in message
> news:J-adnV9-MfUGw3LI...@giganews.com...

> > On 08/09/2015 23:54, Chris M. Thomasson wrote:
> > Example stats, a given location in a given shared secret fractal:

[...]

> I presume that statistical test requires a certain number of input bits
> to be meaningful at all.

Agreed.

> > I can improve these errors by altering the color monitor that is
> > responsible for coloring the fractal.


> If you can do so, I presume this means the randomness of your output is
> not as good as one would expect for encrypted bits (which should look
> like 1 Shannon/bit to anyone not knowing the key, even if they know
> everything else).

This has me a bit worried. The interesting thing is that some fractals
produce better ciphertext than others. Basically akin to weak and strong
passwords.

[Chris M. Thomasson]

> "Jakob Bohm" wrote in message
> news:J-adnV9-MfUGw3LI...@giganews.com...

> > On 08/09/2015 23:54, Chris M. Thomasson wrote:
> > Example stats, a given location in a given shared secret fractal:

[...]

> If you can do so, I presume this means the randomness of your output is
> not as good as one would expect for encrypted bits (which should look
> like 1 Shannon/bit to anyone not knowing the key, even if they know
> everything else).

I coded up a system where small orbits are made around a public
location/axes.

Several ciphertexts are computed in parallel, and the best location wins. So
far, this radically
decreases errors and get me damn near pi rt Monte Carlo estimation.

It kind of seems like there is a "sweet spot" location for plaintext in a
given fractal.

[Chris M. Thomasson]

> "Jakob Bohm" wrote in message
> news:J-adnV9-MfUGw3LI...@giganews.com...

> > On 08/09/2015 23:54, Chris M. Thomasson wrote:
> > Example stats, a given location in a given shared secret fractal:

[...]

> I presume that statistical test requires a certain number of input bits
> to be meaningful at all.

So far, there seems to be multiple locations in almost any fractal I can
think of that reap much
better scores from small plaintext.

These locations/axes seem to be "clustered around each other" in spiral-like
parametric formations.

Humm...

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msnn57$fdc$1...@dont-email.me...

> > On 5-9-2015 1:33, Chris M. Thomasson wrote:
> > Here is a simple rough-rough draft of some "introductory information"
> > for the
> > paper I am working on:
> >

> <snip short intro on fractals>


> > Before I got further, can you help me knock some of the crap out of it?

> I think people who would want to help you are still waiting on how this
> exactly is used in your algorithm. The references to figures 1a and 1b
> etc are not so helpful since they're missing ;-)

I have a little pdf with the figures that is going to be accessible very
soon.

> In the followup post to this one (the one with the 3*3 grid), you start
> an example and then suddenly stop. So readers have not much to knock on
> except your previously released source code.

Okay, I had a feeling that starting small with a 3x3 grid would be helpful.

I will post some more later on today.

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msnn57$fdc$1...@dont-email.me...

>>On 5-9-2015 1:33, Chris M. Thomasson wrote:
>> Here is a simple rough-rough draft of some "introductory information"
>> for the
>> paper I am working on:

[...]

FWIW, here is a link to the pdf that contains renderings of the figures:

https://drive.google.com/file/d/0BxAdjzJ5idDQRThtR1FXQ2tBbEk/view

Can you view it at all? I think I got the settings on Google Drive correct
for sharing...

This is actually coming along fairly well. The problem is that I keep
discovering interesting
new stuff to add to it!

;^o

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msq9vg$akd$1...@speranza.aioe.org...

[...]
> FWIW, here is a link to the pdf that contains renderings of the figures:

> https://drive.google.com/file/d/0BxAdjzJ5idDQRThtR1FXQ2tBbEk/view

OOPS! the figures contained in the paper are not colored solid black wrt
points that do not escape.

Sorry about that total non-sense!

;^o

Well, at least to my eyes, they still make a fairly decent contrast where
points that escape versus the ones
that do not can be visualized and differentiated.

Any thoughts?

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msnn57$fdc$1...@dont-email.me...

> > On 5-9-2015 1:33, Chris M. Thomasson wrote:
> > Here is a simple rough-rough draft of some "introductory information"
> > for the
> > paper I am working on:

[…]

> In the followup post to this one (the one with the 3*3 grid), you start
> an example and then suddenly stop.

FWIW, here is some more info I added to the subject:

_____________________________________________________________________

Speaking of starting small, lets go with a simple plaintext (P) equal to

“AAAAAAAAA”. Lets make a square grid around (P) called the viewport (VP).
(P) has 9 letters (PN) so the width (W) and height (H) can be equal to

(sqrt(PN)) which creates a 3x3 grid in which to calculate the fractal the

Julia set in figures 1a and 1b. This means that the current setup needs to
compute (PN) before in can encrypt (P). If you have any better ideas I would
love to hear them. Anyway, lets now define some axes (CP) that define the
region in the complex plane in which to calculate (F) projected on (VP).
Assume (CP) is at ((-0.5, 0.5), (-0.5, 0.5)) for now, where the real and
imaginary minimum and maximum values are (-0.5, 0.5) respectively. The width
and height of (CP) is one.

Okay, we know the length of the given plaintext (PN) is equal to nine. We
know the dimensions of the viewport (VP), and that of the complex plane
(CP).
Well, we have enough information to build this particular incarnation of the
cipher.

Lets go ahead and iterate over (VP) point by point, while translating each
of
the components of the (3x3) grid over to (CP) along the way. For starters,
take the upper left hand pixel (0, 0) in (VP) that happens to directly
correspond to the upper left corner of (CP) at (-0.5, 0.5). Now, run this
though
a “standard” Mandelbrot iteration (IC) times for every pixel in (VP). How do
the values of (Z) end up interacting with the escape condition (EC) during
iteration?

As was stated point (0, 0) in the plaintext (P) is equal to a point (-0.5,
0.5)
in the complex plane (CP). Here is a one-to-one map of all nine characters
of
the (P) to their corresponding 2d points in (VP) along with their points in
(CP):
-----------------------------------------------
[0] = (0, 0) = (-0.5, -0.5)
[1] = (1, 0) = (0, -0.5)
[2] = (2, 0) = (0.5, -0.5)
[3] = (0, 1) = (-0.5, 0)
[4] = (1, 1) = (0, 0)
[5] = (2, 1) = (0.5, 0)
[6] = (0, 2) = (-0.5, 0.5)
[7] = (1, 2) = (0, 0.5)
[8] = (2, 2) = (0.5, 0.5)
-----------------------------------------------

Now, we have some actual numbers in the realm of (CP) to go ahead and work
with.
So, let us iterate each of the points using the fractal (F).
_____________________________________________________________________


I am trying to walk the reader through the most basic functionality of my
cipher
in a clear step-by-step manner such that the info can be reproduced in any
language.

So far, I think I just might be on the right track here.

Any thoughts?

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msqhl2$ohg$1...@speranza.aioe.org...

[...]

> -----------------------------------------------
> [0] = (0, 0) = (-0.5, -0.5)
> [1] = (1, 0) = (0, -0.5)
> [2] = (2, 0) = (0.5, -0.5)
> [3] = (0, 1) = (-0.5, 0)
> [4] = (1, 1) = (0, 0)
> [5] = (2, 1) = (0.5, 0)
> [6] = (0, 2) = (-0.5, 0.5)
> [7] = (1, 2) = (0, 0.5)
> [8] = (2, 2) = (0.5, 0.5)
> -----------------------------------------------

[...]

I got the damn y-axis exactly backwards here Wizzofozz:

I want positive y to be above the real line damn it!

Anyway, here is a correction of the data:
________________________________
[0] = (0, 0) = (-0.5,0.5)
[1] = (1, 0) = (0,0.5)
[2] = (2, 0) = (0.5,0.5)

[3] = (0, 1) = (-0.5,0)
[4] = (1, 1) = (0,0)
[5] = (2, 1) = (0.5,0)

[6] = (0, 2) = (-0.5,-0.5)
[7] = (1, 2) = (0,-0.5)
[8] = (2, 2) = (0.5,-0.5)
________________________________


I am sorry for all of the posts. However, they should not pollute the group
too bad because
I am trying not to create new threads for each idea and/or correction...

:^o

[wizzofozz]

On 10-9-2015 2:15, Chris M. Thomasson wrote:
>> "Chris M. Thomasson" wrote in message
>> news:msqhl2$ohg$1...@speranza.aioe.org...
>
> [...]
>

> Anyway, here is a correction of the data:
> ________________________________
> [0] = (0, 0) = (-0.5,0.5)

...

> [8] = (2, 2) = (0.5,-0.5)
> ________________________________
>

I'm with you so far...

>
> I am sorry for all of the posts. However, they should not pollute the
> group too bad because
> I am trying not to create new threads for each idea and/or correction...

Why not first finish the paper, then? (I personally have no problems
with the many posts, btw).
Maybe here's another idea (but more of an implementation detail I
guess); Can't you make the fractal function part of the key by
allocating a few keybits to the exponents of the variables in the
mandelbrot functions and the constants? Wouldn't that eliminate the need
for Alice and Bob 'agreeing' on a specific fractal (Alice implicitly
dictates the fractal when choosing a key)? That might also eliminate the
public/private-key terminology/confusion.

Ozz

[Richard Heathfield]

On 10/09/2015 11:55, wizzofozz wrote:
> On 10-9-2015 2:15, Chris M. Thomasson wrote:

<snip>

>> I am trying not to create new threads for each idea and/or correction...
>
> Why not first finish the paper, then?

Er, quite so. The purpose of the paper is to describe the algorithm.
This facilitates meaningful discussion. I think Chris is trying to have
the meaningful discussion first, and /then/ he'll describe the
algorithm. It doesn't work like that.

When Chris's paper is finished, I'll read it. Then (if it's a good
paper) I'll know what the algorithm is, and maybe I'll feel equal to the
task of discussing it. Until then, I just keep skimming over this stuff,
waiting for him to announce that he's finished the paper.

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

> "wizzofozz" wrote in message news:msrng5$pj7$1...@dont-email.me...

> > On 10-9-2015 2:15, Chris M. Thomasson wrote:

[...]

> Why not first finish the paper, then? (I personally have no problems
> with the many posts, btw).

Okay.


> Maybe here's another idea [...]

I was thinking about something similar. Thank you. I need to run some
errands,
but I will get back to typing!

:^)

BTW, Here is some more information I just sketched out that should allow a
programmer to create
encryption up to the point of using orbit traps:

-----------------------------------------------------------------

________________________________
[0] = (0, 0) = (-0.5,0.5)

[1] = (1, 0) = (0,0.5)
[2] = (2, 0) = (0.5,0.5)
[3] = (0, 1) = (-0.5,0)
[4] = (1, 1) = (0,0)
[5] = (2, 1) = (0.5,0)
[6] = (0, 2) = (-0.5,-0.5)
[7] = (1, 2) = (0,-0.5)

[8] = (2, 2) = (0.5,-0.5)
________________________________

Now, we have some actual numbers in the realm of (CP) to go ahead and
work with. So, let us iterate each of the points using the fractal (F)

(Z^2+(-0.75;0.1)) with the iteration count (IC) of 150. Here is the
output I am getting:

__________________________________________________________
[0] = (0, 0) = (-0.5,0.5) = (1.06181,-2.33484) = 6
[1] = (1, 0) = (0,0.5) = (-0.836704,2.59763) = 67
[2] = (2, 0) = (0.5,0.5) = (-0.513945,-2.02816) = 4
[3] = (0, 1) = (-0.5,0) = (-0.599895,0.135125) = 150
[4] = (1, 1) = (0,0) = (-0.747115,2.5992) = 33
[5] = (2, 1) = (0.5,0) = (-0.599895,0.135125) = 150
[6] = (0, 2) = (-0.5,-0.5) = (-0.513945,-2.02816) = 4
[7] = (1, 2) = (0,-0.5) = (-0.836704,2.59763) = 67
[8] = (2, 2) = (0.5,-0.5) = (1.06181,-2.33484) = 6
__________________________________________________________


This information can be used for encryption. The resulting ciphertext
with regard to all bytes being equal in (P) is very nice simply because
it reveals the underlying nature of the cipher itself. I can see an
obvious pattern here. This is due to the fact that (CP) is dead center
on the plane. Most escape time fractals have symmetry in the center.
The pattern above mimics this symmetry where the center of (CP) is at
byte/char [4] in the plaintext (P) at point (0,0) in (CP) with an (ET)
of 33.

Let us take a simple one-to-one mapping of escape times (ET) to bytes
in a plaintext using simple modular arithmetic to create a cipher. Also,
assume (AN) is the total number values a byte can hold. This would be
equal to (UCHAR_MAX + 1) in the realm of C/C++. Encryption on the bytes
in (P) would be:
__________________________________________________________
[0] = ((PB + ET) % AN) = ((65 + 6) % 256) = 71
[1] = ((PB + ET) % AN) = ((65 + 67) % 256) = 132
[2] = ((PB + ET) % AN) = ((65 + 4) % 256) = 69
[3] = ((PB + ET) % AN) = ((65 + 150) % 256) = 215
[4] = ((PB + ET) % AN) = ((65 + 33) % 256) = 98
[5] = ((PB + ET) % AN) = ((65 + 150) % 256) = 215
[6] = ((PB + ET) % AN) = ((65 + 4) % 256) = 69
[7] = ((PB + ET) % AN) = ((65 + 67) % 256) = 132
[8] = ((PB + ET) % AN) = ((65 + 6) % 256) = 71
__________________________________________________________


Okay, lets get rid of that nasty pattern by changing (CP) to
((-0.69,-0.19), (-0.27,0.23)) that happens to be off center. Here is
the iteration data:
__________________________________________________________
[0] = (0, 0) = (-0.69,0.23) = (-0.641686,2.32388) = 48
[1] = (1, 0) = (-0.44,0.23) = (-1.37804,2.20152) = 132
[2] = (2, 0) = (-0.19,0.23) = (-2.28137,1.40558) = 93
[3] = (0, 1) = (-0.69,-0.02) = (1.96029,1.29762) = 138
[4] = (1, 1) = (-0.44,-0.02) = (-0.7216,0.119794) = 150
[5] = (2, 1) = (-0.19,-0.02) = (0.48347,2.04063) = 34
[6] = (0, 2) = (-0.69,-0.27) = (2.18565,1.06893) = 37
[7] = (1, 2) = (-0.44,-0.27) = (-1.33963,1.83807) = 9
[8] = (2, 2) = (-0.19,-0.27) = (1.56953,-1.64208) = 34
__________________________________________________________


Therefore, the new cipher is as follows:
__________________________________________________________
[0] = ((PB + ET) % AN) = ((65 + 48) % 256) = 113
[1] = ((PB + ET) % AN) = ((65 + 132) % 256) = 197
[2] = ((PB + ET) % AN) = ((65 + 93) % 256) = 158
[3] = ((PB + ET) % AN) = ((65 + 138) % 256) = 203
[4] = ((PB + ET) % AN) = ((65 + 150) % 256) = 215
[5] = ((PB + ET) % AN) = ((65 + 34) % 256) = 99
[6] = ((PB + ET) % AN) = ((65 + 37) % 256) = 102
[7] = ((PB + ET) % AN) = ((65 + 9) % 256) = 74
[8] = ((PB + ET) % AN) = ((65 + 34) % 256) = 99
__________________________________________________________


Okay, the obvious pattern has vanished to my eyes. However, can we do
better than using escape times alone? Yes we can. For instance, let us
take a simple orbit trap into account:

https://en.wikipedia.org/wiki/Orbit_trap

[to be continued...]
-----------------------------------------------------------------



Can you still follow any of this?

Thanks again.

[Chris M. Thomasson]

> "Richard Heathfield" wrote in message
> news:mBdIx.237886$491....@fx15.am4...

> > On 10/09/2015 11:55, wizzofozz wrote:
> > > On 10-9-2015 2:15, Chris M. Thomasson wrote:

<snip>

> >> I am trying not to create new threads for each idea and/or
> >> correction...
>
> > Why not first finish the paper, then?

> Er, quite so. The purpose of the paper is to describe the algorithm. This
> facilitates meaningful discussion. I think Chris is trying to have the
> meaningful discussion first, and /then/ he'll describe the algorithm. It
> doesn't work like that.

> ;^( Sorry. I am wondering if you ran the little crap program I wrote?

FWIW, Ben Bacarisse was kind enough to find some time, to find some crap to
clean up in the code:

http://pastebin.com/rQRXU5Mb

A terrible buffer issue:

https://groups.google.com/d/msg/sci.crypt/KH1A8KeWlvw/Wwk5bY8eRYEJ

Another thing he pointed out was that the code was overly verbose and a bit
odd which makes it sort of a PITA to read. I am paraphrasing of course, but
I thank him for the help. Also, I thank you for conversing with me when I
first posted this. Your suggestion about the avalanche effect led me to make
individual axes in the complex plane based on the contents of a plaintext. A
small change in the plaintext makes radical changes in the ciphertext. I am
about to get to that subject in the embryonic stage of the paper.

> When Chris's paper is finished, I'll read it.

That is all I ask, thanks. Also, if you do not like it, please tell me all
about the bad experience for I will learn from it for sure.

:^)

> Then (if it's a good paper) I'll know what the algorithm is, and maybe
> I'll feel equal to the task of discussing it. Until then, I just keep
> skimming over this stuff, waiting for him to announce that he's finished
> the paper.

That is totally fair enough. I apologize for making you have to skim over
the
fairly chaotic material I have been posting here.

Take care Richard.


Oh yeah, one more thing... I am wondering if the paper is good enough, if
you
might try to break it apart like ShuttlePads?

;^)

[Chris M. Thomasson]

> Chris M. Thomasson" wrote in message

> news:mstid8$7b8$1...@speranza.aioe.org...

> > "Richard Heathfield" wrote in message
> > news:mBdIx.237886$491....@fx15.am4...

[...]

> > Er, quite so. The purpose of the paper is to describe the algorithm.
> > This facilitates meaningful discussion. I think Chris is trying to have
> > the meaningful discussion first, and /then/ he'll describe the
> > algorithm. It doesn't work like that.


> > ;^( Sorry. I am wondering if you ran the little crap program I wrote?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oh crap... That is a nasty quoting error! Richard did not write the line
marked above, and the same one below. I did:

[Richard Heathfield]

On 11/09/2015 04:39, Chris M. Thomasson wrote:
>> "Richard Heathfield" wrote in message
>> news:mBdIx.237886$491....@fx15.am4...

<snip>

>> I think Chris is trying to have the
>> meaningful discussion first, and /then/ he'll describe the algorithm. It
>> doesn't work like that.
>
> ;^( Sorry. I am wondering if you ran the little crap program I wrote?

As you may have learned from the AOB threads, getting into
implementation details is utterly pointless until the algorithm is
clear. So I'm waiting for the specification, i.e. a clear, unambiguous,
language-neutral description of the algorithm. You were planning to
write a paper on this, but as far as I can gather it has not yet been
finished.

<snip>

> Oh yeah, one more thing... I am wondering if the paper is good enough, if
> you
> might try to break it apart like ShuttlePads?

I don't claim to be able to break "it", but I would be perfectly willing
to try, once I know what "it" is. I won't know what "it" is, at least
not in sufficient detail, until you provide a clear, unambiguous,
language-neutral description of the algorithm. You were planning to
write a paper on this, but as far as I can gather it has not yet been
finished.

[wizzofozz]

On 11-9-2015 1:31, Chris M. Thomasson wrote:
> Now, we have some actual numbers in the realm of (CP) to go ahead and
> work with. So, let us iterate each of the points using the fractal (F)
> (Z^2+(-0.75;0.1)) with the iteration count (IC) of 150. Here is the
> output I am getting:
>
> __________________________________________________________
> [0] = (0, 0) = (-0.5,0.5) = (1.06181,-2.33484) = 6
> [1] = (1, 0) = (0,0.5) = (-0.836704,2.59763) = 67
> [2] = (2, 0) = (0.5,0.5) = (-0.513945,-2.02816) = 4
> [3] = (0, 1) = (-0.5,0) = (-0.599895,0.135125) = 150
> [4] = (1, 1) = (0,0) = (-0.747115,2.5992) = 33
> [5] = (2, 1) = (0.5,0) = (-0.599895,0.135125) = 150
> [6] = (0, 2) = (-0.5,-0.5) = (-0.513945,-2.02816) = 4
> [7] = (1, 2) = (0,-0.5) = (-0.836704,2.59763) = 67
> [8] = (2, 2) = (0.5,-0.5) = (1.06181,-2.33484) = 6
> __________________________________________________________
>

So, choosing IC too low will give you a caesar shift cipher. Here, you
see it partially happen at 150.

> on the plane. Most escape time fractals have symmetry in the center.

And at many other places as well, don't they? Is that a problem?

> [1] = ((PB + ET) % AN) = ((65 + 67) % 256) = 132

.
.
.
Ok clear

> Okay, lets get rid of that nasty pattern by changing (CP) to
> ((-0.69,-0.19), (-0.27,0.23)) that happens to be off center. Here is
> the iteration data:

<snip> ok

>
> Therefore, the new cipher is as follows:
> __________________________________________________________

nitpick; "ciphertext"

> [0] = ((PB + ET) % AN) = ((65 + 48) % 256) = 113
> [1] = ((PB + ET) % AN) = ((65 + 132) % 256) = 197
> [2] = ((PB + ET) % AN) = ((65 + 93) % 256) = 158
> [3] = ((PB + ET) % AN) = ((65 + 138) % 256) = 203
> [4] = ((PB + ET) % AN) = ((65 + 150) % 256) = 215
> [5] = ((PB + ET) % AN) = ((65 + 34) % 256) = 99
> [6] = ((PB + ET) % AN) = ((65 + 37) % 256) = 102
> [7] = ((PB + ET) % AN) = ((65 + 9) % 256) = 74
> [8] = ((PB + ET) % AN) = ((65 + 34) % 256) = 99
> __________________________________________________________
>

The potential problem of choosing IC too low doesn't go away by changing
the center.

>
> Okay, the obvious pattern has vanished to my eyes. However, can we do
> better than using escape times alone? Yes we can.

Define "better" ;-)

> https://en.wikipedia.org/wiki/Orbit_trap
>

I would expect these to cause trouble, but we'll see what you come up
with :-)

>
> Can you still follow any of this?
>

Yes, it's clear what you are trying to do.

Btw, FYI, your google docs paper can be accessed and read just fine.

Ozz

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msu52b$76j$1...@dont-email.me...

> > On 11-9-2015 1:31, Chris M. Thomasson wrote:

[...]

> So, choosing IC too low will give you a caesar shift cipher. Here, you
> see it partially happen at 150.

Right. Fractals aside for a moment, this all boils down to a stream cipher
using substitution for the actual mutation of (P).

(IC) should be greater than the total number of values a byte can hold (AN).

> > on the plane. Most escape time fractals have symmetry in the center.

> And at many other places as well, don't they? Is that a problem?

It certainly can be! Imagine if Alice and Bob generated a long stream of
messages with (CP)'s that happen to go off center, but right into the
“black hole's” of a spiral that might produces a fairly clear pattern for
smaller (PN). Eve just might be able to use a shi% load of parametric spiral
formations in the ciphertext to find a pattern generated from the (CP) of a
plaintext (P) that can go into (off center symmetry via spirals) mode.
Clever
color monitors can help here, along with orbit traps and the resulting (Z)'s
of points iterated within a given (IC). A hyper crude example... Notice the
duplicate escape times of 34 have different complex results?
_______________________________________________________

[5] = (2, 1) = (-0.19,-0.02) = (0.48347,2.04063) = 34

[6] = (0, 2) = (-0.69,-0.27) = (2.18565,1.06893) = 37

[7] = (1, 2) = (-0.44,-0.27) = (-1.33963,1.83807) = 9

[8] = (2, 2) = (-0.19,-0.27) = (1.56953,-1.64208) = 34
_______________________________________________________

This simple aspect can be used to dynamically try to remove duplicate
(ET)'s.

> > [1] = ((PB + ET) % AN) = ((65 + 67) % 256) = 132

> Ok clear

> > Okay, lets get rid of that nasty pattern by changing (CP) to
> > ((-0.69,-0.19), (-0.27,0.23)) that happens to be off center. Here is
> > the iteration data:

> <snip> ok

> The potential problem of choosing IC too low doesn't go away by changing
> the center.

Correct. If a plaintext goes too deep, and the IC is not adequate to gain
details, well, this is going to be bad for the ciphertext should be of poor
quality. I was going to address this in the paper. Its nice to know you
understand what I am trying to do here.

> > Okay, the obvious pattern has vanished to my eyes. However, can we do
> > better than using escape times alone? Yes we can.

> Define "better" ;-)

> > https://en.wikipedia.org/wiki/Orbit_trap

> I would expect these to cause trouble, but we'll see what you come up
> with :-)

I will explain is more detail how a combination of orbit traps, (ET)'s,
end results of (Z)'s, color monitors can help with ciphertext, and how
they can dynamically detect attractors, hopefully centers of spirals, and
attempt to avoid them. Think of an autopilot that can zoom into the fractal
and avoid centers of spirals along the way... Does that make any sense to
you? An autopilot that can perhaps make a poor choice between Alice and Bob
much, much better?

> > Can you still follow any of this?


> Yes, it's clear what you are trying to do.

Thank God! I am making some actual progress here, thank you for being
interesting in fractals.

> Btw, FYI, your google docs paper can be accessed and read just fine.

:^D

[wizzofozz]

On 11-9-2015 21:57, Chris M. Thomasson wrote:
>> "wizzofozz" wrote in message news:msu52b$76j$1...@dont-email.me...
>
>> > On 11-9-2015 1:31, Chris M. Thomasson wrote:
> [...]
>
>> So, choosing IC too low will give you a caesar shift cipher. Here, you
>> see it partially happen at 150.
>
> Right. Fractals aside for a moment, this all boils down to a stream cipher
> using substitution for the actual mutation of (P).
>
> (IC) should be greater than the total number of values a byte can hold
> (AN).
>

I'm not sure if we're talking about the same here. Let's say IC=300
which is bigger than AN (=256, I assume).
Now, if the "plaintext gridpoints" don't manage to escape in 300
iterations, you will add 300 to every plaintext char (mod 256), which
will just shift everything the same amount. Maybe changes are slim that
this would actually happen, but just saying ...

Ozz

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msvdad$4bh$1...@dont-email.me...

> > On 11-9-2015 21:57, Chris M. Thomasson wrote:

[...]

> > (IC) should be greater than the total number of values a byte can hold
> > (AN).

> I'm not sure if we're talking about the same here. Let's say IC=300
> which is bigger than AN (=256, I assume).
> Now, if the "plaintext gridpoints" don't manage to escape in 300
> iterations, you will add 300 to every plaintext char (mod 256), which
> will just shift everything the same amount. Maybe changes are slim that
> this would actually happen, but just saying ...

It can happen, which means it has to be clearly mentioned in the paper.

The a very simple way "around it" is to use orbit traps to color points that
do not escape.

The example code uses a simplistic method. It helps out a poor choice of
(CP) by coloring
inside points and using it in the cipher.

There seems to be many points of entropy to exploit in a fractal.

Humm...

[wizzofozz]

On 11-9-2015 21:57, Chris M. Thomasson wrote:

>> "wizzofozz" wrote in message news:msu52b$76j$1...@dont-email.me...
>
>> > On 11-9-2015 1:31, Chris M. Thomasson wrote:
> [...]
>

> attempt to avoid them. Think of an autopilot that can zoom into the fractal
> and avoid centers of spirals along the way... Does that make any sense to
> you? An autopilot that can perhaps make a poor choice between Alice and Bob
> much, much better?
>

The autopilot must make some random choices I guess, otherwise it will
always steer to the same region to make Alice's and Bob's choices
better. So you'll need a good random generator. But this is what you
were trying to achieve in the first place with this cipher.
Does that make sense? I understand that initial choices of A and B could
steer the autopilot somewhere else, but it might also 'optimize' a great
number of bad choices to one 'good' one, and thus make it predictable.

>> > Can you still follow any of this?
>
>
>> Yes, it's clear what you are trying to do.
>
> Thank God! I am making some actual progress here, thank you for being
> interesting in fractals.

I'll rephrase that to 'Up till the previous post it is clear what you're
trying to do' ;-)

cheers
Ozz

[Chris M. Thomasson]

>>>On 11-9-2015 21:57, Chris M. Thomasson wrote:
>> "wizzofozz" wrote in message news:msu52b$76j$1...@dont-email.me...

[...]

>> Now, if the "plaintext gridpoints" don't manage to escape in 300
>> iterations, you will add 300 to every plaintext char (mod 256), which
>> will just shift everything the same amount. Maybe changes are slim that
>> this would actually happen, but just saying ...

A simple example of how an orbit trap, iteration count and the end value
of Z can help out with coloring points that do not escape at (IC)
iterations:


<pseudo-code>
__________________________________________________
ET iterate(Z, C, IC)
{
double O = 999999999999.0;

for (i = 1; i < IC + 1; ++i)
{
Z = Z^2 + C;
O = MIN(O, |Z|);

if (|Z| > EC)
{
// Z escaped, use O, i and Z to build a color...
return i;
}
}

// Z did not manage to escape, use O and Z to build a color...
return [...];
}
__________________________________________________

The value of O can be converted into an (ET) value.

This allows points that do not manage to escape to be colored.

The final color that gets plotted to the screen is a combination
of many factors in real fractal rendering.

This color can be used to mutate (P) instead of using the (ET)'s alone.


I am still trying to decide on what color monitor algorithms to use for
the paper.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msvg4m$nne$1...@speranza.aioe.org...

> [...]

> A simple example of how an orbit trap, iteration count and the end value
> of Z can help out with coloring points that do not escape at (IC)
> iterations:

FWIW, here is a simple GPU example of real time orbit trap very similar to
the
one in the code, along with the special field line escape condition (EC) I
came up with:

http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html

Can you run this WebGL program in your browser?

You can click on any point and zoom in real time.

enjoy!

;^)

Notice how the color can get to a point where things looks kind of hard to
see?

I can turn this up further and make everything look like radical static.

These colors can be used instead of the (ET)'s.

Any thoughts?


Am I sounding fuc%ing crazy?

;^/

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msveg3$8pf$1...@dont-email.me...

[...]

> The autopilot must make some random choices I guess, otherwise it will
> always steer to the same region to make Alice's and Bob's choices
> better. So you'll need a good random generator. But this is what you
> were trying to achieve in the first place with this cipher.

Well, assume some plaintext (P) between Alice and Bob created bad (CP)'s.
Each (P)
that is different from each other has an individual (CP) used as the
"public" key
for that (P). Identical plaintexts in a correspondence for a moment:

The autopilot would find several good "local" axes in each (CP).

An autopilot would do a little search for better ciphertext attributes in a
local region of a (CP).

This should help resolve the very real issue you raised.

?


BTW, the sample code "tries" to make unique (CP) for (P)'s that are not
identical.

[Chris M. Thomasson]

"Chris M. Thomasson" wrote in message

news:msvi13$sqq$1...@speranza.aioe.org...

[...]

> Identical plaintexts in a correspondence for a moment:

I meant to say:

Identical plaintexts in a correspondence _aside_ for a moment:

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msveg3$8pf$1...@dont-email.me...

[...]

> The autopilot must make some random choices I guess,

There should be no need to resort to a third party prng. I can see how they
can be used, however I want to use as much information I can gather from
the chaotic nature of the fractals themselves.

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msvdad$4bh$1...@dont-email.me...

[...]

> I'm not sure if we're talking about the same here. Let's say IC=300
> which is bigger than AN (=256, I assume).

Okay.

> Now, if the "plaintext gridpoints" don't manage to escape in 300
> iterations, you will add 300 to every plaintext char (mod 256), which
> will just shift everything the same amount. Maybe changes are slim that
> this would actually happen, but just saying ...

There is a way around this by coloring points that don't manage to escape.

Here are a couple of renderings that visually show how this works:

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

(These are all at a (CP) of ((-0.5, 0.5), (-0.5, 0.5))

Take notice of the Mandelbrot set colored in black, then take a look at the
others
that fill it with color.

These color values can be used for the cipher instead of the direct (ET)'s.

All of this is going into the paper.

Thank you for taking notice of the issue!

:^D

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:msvbnk$ddj$1...@speranza.aioe.org...

[...]

> Right. Fractals aside for a moment, this all boils down to a stream cipher
> using substitution for the actual mutation of (P).

For people that are not following the fine grain threads in the topic, I
should
say substitution in the sense of each byte (PB) from (P) is added to the
“mutating
byte” that (PB) iterates into, escape time (ET) in the current draft of the
paper, and
mod'ed with (AN).


CB = (PB + ET) % AN

So far, each byte (CB) in the resulting cypertext is derived from the final
formula
above.

Wizzofozz pointed out that if axes in the complex plane (CP) happen to go
into
non-escaping regions of the Mandelbrot fractal, well, the result will be
(CB)
being computed with a damn constant number! Take an iteration count (IC) of
150...
The escape time (ET) will be equal to (IC) if a point escapes:

ET = 150
CB = (PB + ET) % AN

YIKES! Luckily, this can be eliminated by using existing information
available to
us after a "grid point in the plaintext" does not happen to escape (e.g.,
Orbit Traps,
the final value of (Z), ect...). The symmetry problem still exists, however
the problem
with a plaintext (P) creating a (CP) that wanders into the non-escaping
regions can
be addressed.

This will all be explained in the paper.

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:msvdad$4bh$1...@dont-email.me...

[...]

> I'm not sure if we're talking about the same here. Let's say IC=300
> which is bigger than AN (=256, I assume).
> Now, if the "plaintext gridpoints" don't manage to escape in 300
> iterations, you will add 300 to every plaintext char (mod 256), which
> will just shift everything the same amount. Maybe changes are slim that
> this would actually happen, but just saying ...

Data from the terrible case of non-escaping (CP)'s in the
Mandelbrot set:
____________________________________________________________
IC = 150
CP = ((-0.69,-0.19), (-0.27,0.23))

[0] = (0, 0) = (-0.69,0.23) = (-0.485874,0.101633) = 150
[1] = (1, 0) = (-0.44,0.23) = (-0.341821,0.136609) = 150
[2] = (2, 0) = (-0.19,0.23) = (-0.184283,0.168059) = 150
[3] = (0, 1) = (-0.69,-0.02) = (-0.469576,-0.0103122) = 150
[4] = (1, 1) = (-0.44,-0.02) = (-0.33075,-0.0120373) = 150
[5] = (2, 1) = (-0.19,-0.02) = (-0.163496,-0.0150717) = 150
[6] = (0, 2) = (-0.69,-0.27) = (-0.498001,0.0611528) = 150
[7] = (1, 2) = (-0.44,-0.27) = (-0.345856,-0.159602) = 150
[8] = (2, 2) = (-0.19,-0.27) = (-0.191461,-0.195239) = 150
____________________________________________________________



Data from the a possible fix using more information from a
non-escaping point (Z and orbit trap in this case):
____________________________________________________________
IC = 150
((-0.69,-0.19), (-0.27,0.23))

[0] = (0, 0) = (-0.69,0.23) = (-0.485874,0.101633) = 14
[1] = (1, 0) = (-0.44,0.23) = (-0.341821,0.136609) = 227
[2] = (2, 0) = (-0.19,0.23) = (-0.184283,0.168059) = 165
[3] = (0, 1) = (-0.69,-0.02) = (-0.469576,-0.0103122) = 135
[4] = (1, 1) = (-0.44,-0.02) = (-0.33075,-0.0120373) = 1
[5] = (2, 1) = (-0.19,-0.02) = (-0.163496,-0.0150717) = 49
[6] = (0, 2) = (-0.69,-0.27) = (-0.498001,0.0611528) = 226
[7] = (1, 2) = (-0.44,-0.27) = (-0.345856,-0.159602) = 4
[8] = (2, 2) = (-0.19,-0.27) = (-0.191461,-0.195239) = 238
____________________________________________________________


There is a massive difference! I am going to show exactly how to do this in
the paper.

:^)

[Chris M. Thomasson]

> The escape time (ET) will be equal to (IC) if a point escapes:

I meant:

The escape time (ET) will be equal to (IC) if a point _does_not_ escape:

> ET = 150
> CB = (PB + ET) % AN

Sorry about that!

;^o

[wizzofozz]

On 14-9-2015 1:08, Chris M. Thomasson wrote:

>
> Data from the a possible fix using more information from a
> non-escaping point (Z and orbit trap in this case):
> ____________________________________________________________
> IC = 150
> ((-0.69,-0.19), (-0.27,0.23))
>
> [0] = (0, 0) = (-0.69,0.23) = (-0.485874,0.101633) = 14
> [1] = (1, 0) = (-0.44,0.23) = (-0.341821,0.136609) = 227
> [2] = (2, 0) = (-0.19,0.23) = (-0.184283,0.168059) = 165
> [3] = (0, 1) = (-0.69,-0.02) = (-0.469576,-0.0103122) = 135
> [4] = (1, 1) = (-0.44,-0.02) = (-0.33075,-0.0120373) = 1
> [5] = (2, 1) = (-0.19,-0.02) = (-0.163496,-0.0150717) = 49
> [6] = (0, 2) = (-0.69,-0.27) = (-0.498001,0.0611528) = 226
> [7] = (1, 2) = (-0.44,-0.27) = (-0.345856,-0.159602) = 4
> [8] = (2, 2) = (-0.19,-0.27) = (-0.191461,-0.195239) = 238
> ____________________________________________________________
>
>
> There is a massive difference! I am going to show exactly how to do this
> in the paper.
>

Care to explain a bit already while we wait for the paper? ;-)

I imagine you check the final value of Z and if |Z| <= 2 you know it
didn't escape and then check when it first entered the trap? I didn't
verify the above numbers, just guessing..

Ozz

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mt775o$ug1$1...@dont-email.me...

> > On 14-9-2015 1:08, Chris M. Thomasson wrote:

> > [...]

> Care to explain a bit already while we wait for the paper? ;-)

Take the following Mandelbrot where ((F) = (Z = Z^2 + C)), dataset into
account:
____________________________________________________________
IC = 150
CP = ((-0.69,-0.19), (-0.27,0.23))

[0] = (0, 0) = (-0.69,0.23) = (-0.485874,0.101633) = 150
[1] = (1, 0) = (-0.44,0.23) = (-0.341821,0.136609) = 150
[2] = (2, 0) = (-0.19,0.23) = (-0.184283,0.168059) = 150
[3] = (0, 1) = (-0.69,-0.02) = (-0.469576,-0.0103122) = 150
[4] = (1, 1) = (-0.44,-0.02) = (-0.33075,-0.0120373) = 150
[5] = (2, 1) = (-0.19,-0.02) = (-0.163496,-0.0150717) = 150
[6] = (0, 2) = (-0.69,-0.27) = (-0.498001,0.0611528) = 150
[7] = (1, 2) = (-0.44,-0.27) = (-0.345856,-0.159602) = 150
[8] = (2, 2) = (-0.19,-0.27) = (-0.191461,-0.195239) = 150
____________________________________________________________

Notice how the (ET)'s are all the same at 150?

See how the complex numbers to the left of the equal sign of the
"= 150"'s are all different? We can use these to build a color. An
orbit trap is just another spice to add to the color...

So, a quick, dirty and naive function to do this without using orbit traps
is:

Take the complex result (Z) of an (ET). Add the real and imaginary parts
of (Z) together and multiply by a large constant; let the result be (ETC).
Take the absolute value of a sin/cos using (ETC) as an angle.


// for escaping values
large_number = 123031.0;
ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN - 1.0));


This color (ETC) can be used to encrypt a byte (PB) of a plaintext (P).


Is making any sense to you?

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mt79qc$l10$1...@speranza.aioe.org...

> > "wizzofozz" wrote in message news:mt775o$ug1$1...@dont-email.me...

[...]

> // for escaping values
> large_number = 123031.0;
> ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN -
> 1.0));

FWIW, I typed this "single channel" color monitor in at random. The one in
the paper will be a bit different...

I say single channel because this creates a value in the range of [0.255], a
single color in a 32-bit bmp can
hold four of these (AN)'s.

;^)

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mt79qc$l10$1...@speranza.aioe.org...

[...]

> // for escaping values
> large_number = 123031.0;
> ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN -
> 1.0));

The comment should read as:

// for escaping _or_ non-escaping values

Sorry about that! :^o

[wizzofozz]

On 14-9-2015 22:51, Chris M. Thomasson wrote:
>> "Chris M. Thomasson" wrote in message
>> news:mt79qc$l10$1...@speranza.aioe.org...
>
>> > "wizzofozz" wrote in message news:mt775o$ug1$1...@dont-email.me...
>
> [...]
>
>> // for escaping values
>> large_number = 123031.0;
>> ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN -
>> 1.0));
>

Adding z.real and z.imag seems a bit arbitrary, or is there some
rationale behind it?
For 'large_number' see
https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

(I found that actually enlightening to read)

Ozz

[wizzofozz]

On 14-9-2015 22:51, Chris M. Thomasson wrote:

>> "Chris M. Thomasson" wrote in message
>> news:mt79qc$l10$1...@speranza.aioe.org...
>
>> > "wizzofozz" wrote in message news:mt775o$ug1$1...@dont-email.me...
>
> [...]
>
>> // for escaping values
>> large_number = 123031.0;
>> ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN -
>> 1.0));
>

Another thing; after calculating ETC as above, it will be between 0 and
255, right?
I assume z.real() + z.imag() should give you the randomness you want for
your cipher. You multiply with large number for some reason. You apply
the cos() to get it between -1 and 1. Finally abs to get it between 0
and 1 and multiply with 256 (well, 255) to get your random byte for
encryption.

Doesn't the application of cos() mess up the uniform distribution (if
any in the first place)?

I mean, your ETC values will be biased (?) towards the higher values. I
ran some (simple) tests which seem to confirm this.

Is the intention of the multiplication with large_number somehow to fix
this?

Or am I way off?

Ozz

[Chris M. Thomasson]

> "wizzofozz" wrote in message news:mt9u24$or0$1...@dont-email.me...

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

> >> // for escaping values
> >> large_number = 123031.0;
> >> ETC = (ubyte)(abs(cos((Z.real() + Z.imag()) * large_number)) * (AN -
> >> 1.0));


> Adding z.real and z.imag seems a bit arbitrary, or is there some
> rationale behind it?

Unfortunately, this totally arbitrary. :^(

We can do much better with the fact that the result of the iterations of
Z are all different even though their escape times are equal to each other.
WRT (large_number), here are a series of renderings that show its effects:


(Sum of the real and imaginary parts of Z)
https://plus.google.com/101799841244447089430/posts/31QD8zLCfPD


(The result of an orbit trap of Z)
https://plus.google.com/101799841244447089430/posts/JBXp6QhgKWN


Each rendering is at increasing values of (large_number):
_______________________________________
[0]large_number = 123031.0
[1]large_number = 280068.0
[2]large_number = 840204.0
[3]large_number = 5881428.0
[4]large_number = 76458564.0
_______________________________________


There is a difference, but I think we _can_ do much, much better than this.

?



> For 'large_number' see
> https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

> (I found that actually enlightening to read)

So did I, and (large_number) seems to fit the bill!

;^o


Humm...

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message

> news:mtcop2$obq$1...@speranza.aioe.org...

[...]

> Unfortunately, this totally arbitrary. :^(

> We can do much better with the fact that the result of the iterations of
> Z are all different even though their escape times are equal to each
> other.
> WRT (large_number), here are a series of renderings that show its effects:

Humm... I believe I may be on to something based on a Buddhabrot iteration
and
Cantor packing in order to create uniqueness, pseudo randomness, and a much
deeper meaning for an iteration of a fractal. We count all of the points
each
iteration hits, and do cantor packing in a progressive nature. Now, these
number
can be used along with the final Z counts as they are already unique.

I am going to code this up right away and will post the code when it is
done.

[Chris M. Thomasson]

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

[...]

> Unfortunately, this totally arbitrary. :^(

> We can do much better with the fact that the result of the iterations of
> Z are all different even though their escape times are equal to each
> other.
> WRT (large_number), here are a series of renderings that show its effects:

I got something that is, so far, producing damn near perfect random
frequency
distributions for every plaintext I can throw at it.

I will present it here very soon.

I looks like its going to work out very well indeed!

:^D

[Chris M. Thomasson]

Dynamically producing good random frequency distributions...


<Brief introduction>

AN = 256

Here is a simplistic method for creating better frequency distributions with
regard to randomness in fractal encryption. First we create a table (T) of
(AN)
unsigned integer counters set to zero. Then we figure out the maximum value
(MP)
of each counter needs in order to encrypt a plaintext (P). Say we have a (P)
the
size of (PN) equal to 12341. The maximum value (MP) for (P) means that each
count
can hold an unsigned integer value of (PN / AN + 1). I included the plus one
to
deal with cases where (PN) is not perfectly divisible by (AN). Therefore MP
would
be equal to 49.

Okay, a good random frequency would want to completely fill the table of
counters
(T) such that each counter is close, or equal to (MP). A naive solution
could be
to only allow a result to encrypt a byte in (P) if and only if its counter
in (T)
is less then (MP).

If the iteration of a fractal does not end up producing enough results to
completely
encrypt (P), then we simply compute another fractal with a different
location, and
continue the process until (P) is completely encrypted.

There are some caveats... Can you spot them?

I have a C++ program that I am going to post later on today.

It keeps computing Julia sets with seed points generated by a parametric
spiral
formation until it has enough to encrypt every byte of (P). When this
occurs, the
table (T) should have a near perfect frequency distribution.

I wish I had more time for all of this!

;^(