Reverse Iteration Fractal Encryption...

[Chris M. Thomasson]

Original idea by Juaquin Anderson in the comments of the
following thread:

https://plus.google.com/+JuaquinAnderson/posts/L9A3Da8ju3B


FWIW, here is the content of the comment:
_________________________________________________
“This has me thinking.. All the structure, in the reverse
iteration, and the sequence of roots, as well as the structure
of the level sets with the escape time algorithim.
Someone
suggested using fractals for encryption..

A method that would
actually work would be to choose an interesting value of c,
like this one, as the key.

1) If the message has length n bits,
choose a point in the n'th level set. The point can be chosen
by taking a starting point just outside the circle delimiting
the target set, and applying inverse iteration, choosing roots
by sign according to the bits in the sequence to be encoded.

2)
the result would be a point (x+yi) that is inside the nth level
set close to the Julia set.

3) encode that point accurately
enough to not confuse with points of a level deeper or further
out, and transmit that point.

4) receive that point.

5) decode
the point by applying forwards iteration with the key value c,
until the point lands in the target set. Tge decoded message
would have n bits determined by writing down the sign of the
imaginary component of the escape orbit for each iteration.



Sounds easy right?

:-)

The efficiency of the encrypted coding scheme has to do with
the fractal dimension of the Julia set, and the degree of
imbalance of the contractivity in the tree traversal of the
Julia set."
_________________________________________________


Juaquin Anderson has taken fractal encryption to another level
beyond the stuff I have been experiment with. He is basically
encoding a sequence of bytes inside a single complex number.
The reverse iteration method for a Julia set is being used to
store information. Lets say a byte. Well, a byte is made up of
a number of bits, on or off. These bits are used to decide which
root to choose for the square root of z during reverse iteration
of (z = z^2 + c). After this reverse iteration, one ends up with
an interesting point p. This point p can actually recreate the
bits of the byte when exposed to forward iteration. The number
of iterations for both forward and reverse iteration directly
corresponds to how many bits it stores. I can only do around 40
bits, but the little program I wrote just does 8 for clarity.

So, for encryption c is the secret key and the cipher text is a
list of complex numbers, or a single complex number if one uses
an arbitrary precision library to calculate both the reverse and
forward iterations.

Here is a simple proof of concept program in C++11 that encodes
a single byte:

http://pastebin.com/4Yu8uSKH


If one can encode a single byte, then one can encode multiple
bytes, and arbitrary binary files.

I know that this is going to work like a charm. I am working on
another proof of concept program that shows how to encode multiple
bytes in a single complex number, instead of the single byte
example shown here...


Any thoughts?

What do you think about the code? Is it crap?

;^)


Thank you all.

[Chris M. Thomasson]

> "Chris M. Thomasson" wrote in message news:nadaph$pnu$1...@gioia.aioe.org...

> Original idea by Juaquin Anderson in the comments of the
> following thread:

> https://plus.google.com/+JuaquinAnderson/posts/L9A3Da8ju3B

[...]

FWIW, here is another c++11 proof of concept program
that can encrypt all byte values:

http://pastebin.com/VsvH3HdE

Some essential further context:

https://plus.google.com/101799841244447089430/posts/6hYWn1YPd2C

This makes sense because there are an infinite number of
different representations of the root tree wrt going down
a positive or negative root during reverse iteration...

example code:
__________________________________________________
/*
Original idea by: Juaquin Anderson, in the comments of the following thread:

https://plus.google.com/+JuaquinAnderson/posts/L9A3Da8ju3B

Implementation by: Chris M. Thomasson
______________________________________________________________________
*/

#include <iostream>
#include <complex>
#include <array>
#include <vector>
#include <climits>
#include <cassert>



#define ESP ((iim_float_t)0.000000001)


typedef double iim_float_t;
typedef std::complex<iim_float_t> complex_t;
typedef std::array<bool, CHAR_BIT> bitchar_t;


struct forward_ret
{
complex_t z;
bitchar_t bc;
};




static unsigned char
bitchar_get(
bitchar_t
);


static complex_t
iterate_reverse(
complex_t,
complex_t,
bitchar_t const&
);


static forward_ret
iterate_forward(
complex_t,
complex_t
);


unsigned char
bitchar_get(
bitchar_t bc
) {
assert(bc.size() == CHAR_BIT);

unsigned char r = 0;
unsigned int b = 1;

for (unsigned int i = 0; i < bc.size(); ++i)
{
if (bc[i]) r = r | b;
b = b << 1;
}

return r;
}


bitchar_t
bitchar_set(
unsigned char n
) {
bitchar_t r = { false };
unsigned int b = 1;

for (unsigned int i = 0; i < r.size(); ++i)
{
r[i] = (n & b) ? true : false;
b = b << 1;
}

return r;
}


complex_t
iterate_reverse(
complex_t z,
complex_t c,
bitchar_t const& bc
) {
assert(bc.size() == CHAR_BIT);

for (std::size_t i = 0; i < CHAR_BIT; ++i)
{
complex_t d = z - c;

iim_float_t l = std::abs(d);
iim_float_t s = std::sqrt(l);
iim_float_t a = std::atan2(d.imag(), d.real()) / 2.0;
iim_float_t r = 0;

if (bc[i]) { r = 1; }
else { r = -1; }

complex_t nz = { r * s * std::cos(a), r * s * std::sin(a) };

if (bc[i] == 1)
{
std::cout << "iterate_reverse:[" << i << "]:("
<< bc[i] << "):(+) = " << nz << std::endl;
}

else
{
std::cout << "iterate_reverse:[" << i << "]:("
<< bc[i] << "):(-) = " << nz << std::endl;
}

z = nz;
}

std::cout << "__________________________________________" << std::endl;

return z;
}


forward_ret
iterate_forward(
complex_t z,
complex_t c
) {
forward_ret ret = { { z },{ false } };

std::cout << "iterate_forward:(origin):" << z << std::endl;

for (std::size_t i = 0; i < CHAR_BIT; ++i)
{
complex_t pz = ret.z;
ret.z = ret.z * ret.z + c;

// check for bit on condition
if (pz.real() > 0.0)
{
// turn the proper bit on...
std::size_t bc_i = CHAR_BIT - (i + 1);
ret.bc[bc_i] = true;
}

iim_float_t l = std::abs(ret.z);

if (l < ESP)
{
std::cout << "iterate_forward:(term):[" << i << "]: " << ret.z
<< std::endl;
break;
}

std::cout << "iterate_forward:[" << i << "]: " << ret.z <<
std::endl;
}

std::cout << "__________________________________________" << std::endl;

return ret;
}




int main()
{
{
// the secret key c
complex_t c = { -0.75, 0.09 };

// the origin of iteration z
complex_t z = { 0.0, 0.0 };

// A bytes to encode, the plaintext pt
std::cout << std::endl <<
"**********************************************************"
<< std::endl;

for (std::size_t pt = 0; pt < UCHAR_MAX + 1; ++pt)
{
std::cout << "encoding pt:" << pt << std::endl;
std::cout << "__________________________________________" <<
std::endl;

// set pt to bitchar_t
bitchar_t pt_bits = bitchar_set(pt);

// Our encoded byte point origin, out ciphertext ct
complex_t ct = iterate_reverse(z, c, pt_bits);

// Our decoded bits and point origin db_z
forward_ret db_z = iterate_forward(ct, c);

// Our decoded byte db, should be equal to plaintext pt.
unsigned char db = bitchar_get(db_z.bc);

if (pt != db)
{
std::cout << "pt:" << pt << " != db:" << (int)db <<
std::endl;
std::cin.get();
assert(pt == db);
}

std::cout << "decoded: pt:" << pt << " == db:" << (int)db <<
std::endl;

std::cout <<
"**********************************************************"
<< std::endl;
}
}

std::cout << std::endl << "__________________________________________"
<< std::endl << "Program Complete!" << std::endl;

std::cin.get();

return 0;
}
__________________________________________________


What do you think of this?

[Öö Tiib]

It likely makes sense to turn on FENV_ACCESS and (further) make sure that
floating point environment is same on encrypting and decrypting side

#pragma STDC FENV_ACCESS ON

etc. Modern compilers sometimes cause major headache without.

>
>
>
> #define ESP ((iim_float_t)0.000000001)
>
>
> typedef double iim_float_t;
> typedef std::complex<iim_float_t> complex_t;
> typedef std::array<bool, CHAR_BIT> bitchar_t;
>

I would consider 'std::bitset<CHAR_BIT>' here because it has semantics
of bool array plus number of handy methods. You are seemingly
manufacturing some yourself. Can't compare performance here since
amounts of standard output in code but it is highly competitive
container of bools wherever I have used it.

The 128 bit key looks small, I'm not expert enough to consider its
potential vulnerabilities otherwise.

[Chris M. Thomasson]

This: https://plus.google.com/101799841244447089430/posts/TJ6ELo7qgFb

is related to:

https://plus.google.com/101799841244447089430/posts/1YKAJn1XKYd


I'm wondering, if Juaquin Anderson, creator of the wonderful idea,
of using the reverse iteration method to forward iteration Julia
set encryption would approve of this line of thought in a possible
short paper... The main idea is zone based encryption. I attached
a very crude diagram of a line and a curve encoding 4 bytes P[n],
n=4 where byte values p[0] = red, p[1] = green, p[2] = blue and
p[3] = yellow. Encrypting a byte P is accomplished by choosing
its corresponding color, or zone of a section of a given curve
length. The zone database, if you will, can be created on the
fly by using the secret key K which is comprised of settings that
describe the size of the zones, and the “path” that the zones are
partitioned across. Fractals are used for efficient zone partitioning
basically similar to measuring fractal dimension using “boxes”.

This
cannot be anything new, but I am trying to understand the creators
idea of using field lines to store information. Well, the field lines
in my calculations, are perfectly segmented on the scaled unit vector
level. This would provide all we need to create the zones needed to
encode/decode a given datum.

256 zones means a byte can be encrypted
on a given line/curve length basis.

Encoding relates the byte of the
plaintext to its zone and transmits that point.

Decoding relates the
encoded points to their zones, and gets the byte back based on the
“value” of the zone color, so to speak.


I just thought that instead of transmitting an encoded point across the
network, why not send an iteration count? This count would of course be
sufficient enough for a given plaintext byte to traverse the field line into
its
corresponding zone!

Well, what do you think? Is this crap?

;^o


I am going to work on a proof of concept. For the graphics,
I will use the Cairo C lib. This should work damn it!

[Chris M. Thomasson]

> "嘱 Tiib" wrote in message
> news:582d193d-f16e-4e84...@googlegroups.com...

> > On Monday, 22 February 2016 00:31:09 UTC+2, Chris M. Thomasson wrote:
> > "Chris M. Thomasson" wrote in message
> > news:nadaph$pnu$1...@gioia.aioe.org...

[...]

> It likely makes sense to turn on FENV_ACCESS and (further) make sure that
> floating point environment is same on encrypting and decrypting side

> #pragma STDC FENV_ACCESS ON

> etc. Modern compilers sometimes cause major headache without.

Thank you. For some reason, I seemed to have forgot about this.

:^o

[...]

> I would consider 'std::bitset<CHAR_BIT>' here because it has semantics
> of bool array plus number of handy methods. You are seemingly
> manufacturing some yourself. Can't compare performance here since
> amounts of standard output in code but it is highly competitive
> container of bools wherever I have used it.

Yeah. I just wanted to be able to hold some extra information,
so I created a container of bools that can be extended.

> The 128 bit key looks small, I'm not expert enough to consider its
> potential vulnerabilities otherwise.

Excellent point! Yes. I think there is a way around this by
using more than one Julia point, or c if you will. Multiple
points can increase key space during iteration. Also, I am
tinkering around with some other ideas involving field lines
that should greatly increase secret key space.


Thank you for taking a look at it.

:^)

[Chris M. Thomasson]

FWIW, here are some field line examples on Julia set
points that can be used to encode a stream of bytes
via fractal based zone encoding scheme. Extra mass
points can be used int the secret key to bend the line
further, and basically radically distort the field...

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

https://plus.google.com/101799841244447089430/posts/5Jm2Q6APu8n

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

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


any thoughts?

Fractal based field distortion wrt encoding along a given field
line would really scramble the shit out of the lines.

[Peter Fairbrother]

On 21/02/16 21:38, Chris M. Thomasson wrote:
> Original idea by Juaquin Anderson in the comments of the
> following thread:
>
> https://plus.google.com/+JuaquinAnderson/posts/L9A3Da8ju3B
>
>
> FWIW, here is the content of the comment:
> _________________________________________________
> “This has me thinking.. All the structure, in the reverse
> iteration, and the sequence of roots, as well as the structure
> of the level sets with the escape time algorithim.
> Someone
> suggested using fractals for encryption..
>
> A method that would
> actually work would be to choose an interesting value of c,
> like this one, as the key.
>
> 1) If the message has length n bits,
> choose a point in the n'th level set. The point can be chosen
> by taking a starting point just outside the circle delimiting
> the target set,

I don't get this bit. I am not a chaos theorist, and I do not understand
_exactly_ what is being proposed. Could you explain further?

Please try and be as precise as you can.


For example, what is the n-th level set? Is it the same thing as the
target set? (if so, please don't call it by two different names... )

I initially thought it was the set of points which remain less than some
value after n iterations (presumably of x -> x^2 + c) - or possibly that
set minus the set for n-1 iterations - but I don't see how that would be
delimited by a circle.


Can c be freely chosen from some large range?

> and applying inverse iteration, choosing roots
> by sign according to the bits in the sequence to be encoded.

Is that the actual encryption operation?

>
> 2)
> the result would be a point (x+yi) that is inside the nth level
> set close to the Julia set.


> 3) encode that point accurately
> enough to not confuse with points of a level deeper or further
> out, and transmit that point.
>
> 4) receive that point.
>
> 5) decode
> the point by applying forwards iteration with the key value c,

> until the point lands in the target set. The decoded message

> would have n bits determined by writing down the sign of the
> imaginary component of the escape orbit for each iteration.

This last part 5, decode by repeatedly iterating and taking the sign of
the imaginary parts as plaintext bits, seems like it would work.

but oh oh, what is an escape orbit? for each iteration?

If you/he means the imaginary part of x, then it seems to make some sense.

But what is the imaginary component of the escape orbit of an iteration?



I still don't see how you get the initial ciphertext.

Repeated reverse iterations and choosing which root to use, OK, I get
that. But how do you choose the starting point, given some
arbitrarily-chosen c?




Assuming you can do that, as a cipher it seems to have several
disadvantages: first, it is computationally expensive.

Second, the ciphertext is somewhat longer than the plaintext. For cipher
purposes, you need too be able to encrypt say 128 bits in a block -
there are some 64-bit block ciphers still around, but they are
deprecated, and some people say you need 256 bits in a block nowadays.

As a corollary to the above, the actual length needed for the ciphertext
is ... variable, which is a bit disconcerting.

Another corollary, you might have to check whether each block decrypts
correctly, so as to tell whether you have enough precision ..

So in general it isn't that useful as a cipher.

except ..

it *may* have a slightly interesting security property, ie a strong
proof of security.

This is kinda a holy grail for some cryptologists, and if I am right
about that, it may have some limited use.



> Sounds easy right?

Maybe if you are a chaos theorist ..

- Peter Fairbrother

ps ignore anything austinobyrne has to say - he is a well-known idiot.

>
> :-)
>
> The efficiency of the encrypted coding scheme has to do with
> the fractal dimension of the Julia set, and the degree of
> imbalance of the contractivity in the tree traversal of the
> Julia set."

ps nope, that makes no sense to me either ..

[Chris M. Thomasson]

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:
> On 21/02/16 21:38, Chris M. Thomasson wrote:
>> Original idea by Juaquin Anderson in the comments of the
>> following thread:

[...]

>> 5) decode
>> the point by applying forwards iteration with the key value c,
>> until the point lands in the target set. The decoded message
>> would have n bits determined by writing down the sign of the
>> imaginary component of the escape orbit for each iteration.
>
>
> This last part 5, decode by repeatedly iterating and taking the sign of
> the imaginary parts as plaintext bits, seems like it would work.
>
> but oh oh, what is an escape orbit? for each iteration?
>
> If you/he means the imaginary part of x, then it seems to make some sense.

FWIW, my experiments say its the sign of the (real) part, during forward
iteration that can recreate the bits stored during reverse iteration:

http://pastebin.com/VsvH3HdE

Juaquin must have made a mistake here. Or, I created another version
accidentally that works with real. I will ask him. I need to go right
now, I have fairly limited time to work on this.

Your question is very great; insightful indeed! I will get back to you
later on tonight, or tomorrow morning. Also, take a close look at these
two threads:

https://groups.google.com/forum/#!original/sci.crypt/mycXj0ViYaw/hVFJ3vE4BAAJ

https://groups.google.com/forum/#!original/sci.crypt/mycXj0ViYaw/lS28y_52BAAJ

All of the required math can be found here:

https://groups.google.com/d/topic/comp.lang.javascript/dgakiMzhgv0/discussion

Sorry, got to go now.

;^o


[...]

[Chris M. Thomasson]

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:

> On 21/02/16 21:38, Chris M. Thomasson wrote:
>> Original idea by Juaquin Anderson in the comments of the

[...]

Read this as well:

https://plus.google.com/101799841244447089430/posts/1YKAJn1XKYd

[Chris M. Thomasson]

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:

The n-th level set is the n-th node in the “tree” created by the bits in
the plaintext bytes. So, if we store a byte per complex number we go
down CHAR_BIT levels in the “root tree” where every left-right decision
is a bit in a byte during reverse iteration. The level sets are
basically the equipotential field lines of a Julia set. Here is an
example rendering:

https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Julia_set#/media/File:LCMJ_rabbit.jpg

If you keep zooming out, they converge into a circle. If you zoom in,
they start to flow around the highly intricate border structure of the
fractal.

> or possibly that
> set minus the set for n-1 iterations - but I don't see how that would be
> delimited by a circle.

I think he means plotting the target set represented by the secret key
(c), and taking the largest distance (z) gets from the origin during
iteration of (c) on random data. (r) is the radius for a circle that the
set is inscribed within. I will try to clarify this with Juaquin.

> Can c be freely chosen from some large range?

Well, kind of. Humm, these numbers are not going to be very large, but
they can be very small, and describe precise Julia set locations in the
Mandelbrot set. However, I have managed to store bytes in values of
(c)'s that are fairly far away as well. Here are some example points,
that are all valid secret key values of (c):

http://colinlmiller.com/fractals/gallery.htm

Many digits in these suckers, and there all VERY important! Basically,
values of (c) are restricted by the level of precision used to represent
them. This project would be really interesting with a bignum lib, but
its still fun to pack information into floats. Here are some lower
precision example points:

{-1.295189; 0.440936}
{-1.746695; 0.000037}
{-0.74543, 0.11301}
{0.0, 1.0}
{0.0, -1.0}

Yes, these points are mostly on the negative side of the real axes, but
they contain fine grain structure, and can store data: more than a
single byte. Also, you can get a finer grain point:

real part =
-1.985,540,371,654,130,485,531,439,267,191,269,851,811,165,434,636,382,820,704,394,766,801,377

imag part =
+0.000,000,000,000,000,000,000,000,000,001,565,120,217,211,466,101,983,496,092,509,512,479,178

>> and applying inverse iteration, choosing roots
>> by sign according to the bits in the sequence to be encoded.
>
> Is that the actual encryption operation?

Exactly yes. The ciphertext is the complex number result from reverse
iteration.

>
>>
>> 2)
>> the result would be a point (x+yi) that is inside the nth level
>> set close to the Julia set.
>
>
>> 3) encode that point accurately
>> enough to not confuse with points of a level deeper or further
>> out, and transmit that point.
>>
>> 4) receive that point.
>>
>> 5) decode
>> the point by applying forwards iteration with the key value c,
>> until the point lands in the target set. The decoded message
>> would have n bits determined by writing down the sign of the
>> imaginary component of the escape orbit for each iteration.
>
>
> This last part 5, decode by repeatedly iterating and taking the sign of
> the imaginary parts as plaintext bits, seems like it would work.

Actually, I found that Juaquin must have made an error here. So far, I
can only decrypt the bits by using the sign of the real part during
forward iteration. The imaginary part produces another byte value, that
is not part of the plaintext, yet its definitely related in some way. I
have not explored this “auxiliary” byte in any detail quite yet. Still,
imho, its quite interesting.

> but oh oh, what is an escape orbit? for each iteration?

The escape orbit is the actual value of (z) during forward iteration.
Actually, the signs and/or values of this number can be integrated into
an escape condition to create many wonderful things. Pickover stalks,
and my own field line escape condition work nicely:

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

Ahh, well. Shi% hits the fan when one tries to store too many bits for
the current level of precision. The crap arises in the from of (z) going
extremely high, off to positive infinity. Or really low, if the secret
key (c) was inside the non-escaping region of the set. The precision
loss is apparent when you take a look at the digits of (z) during
forward iteration, and compare them to the results of reverse iteration.

> If you/he means the imaginary part of x, then it seems to make some sense.

Humm... All of my “proof of concept” experimental code uses the real part.

> But what is the imaginary component of the escape orbit of an iteration?

The imaginary component of an escape orbit is the imaginary part of (z)
of an iteration.

> I still don't see how you get the initial ciphertext.

Take a deep look at the (iterate_reverse) function in:

http://pastebin.com/VsvH3HdE

> Repeated reverse iterations and choosing which root to use, OK, I get
> that. But how do you choose the starting point, given some
> arbitrarily-chosen c?

Ahhh. The starting point (z) can be very fairly far away from the
origin, or it can be the origin itself. This point quickly converges
into the Julia set of (c), in CHAR_BIT iterations with large (z) will
still be fairly close to the set at the end. The origin point of (z) can
actually plot the equipotential field when its very far away. I used a
starting point of (0, 0) for my example code.

Interestingly, the starting point of (z) can be random.

> Assuming you can do that, as a cipher it seems to have several
> disadvantages: first, it is computationally expensive.

Agreed. The reverse formula is in polar form and uses square root and
trig under iteration. Pretty expensive!

> Second, the ciphertext is somewhat longer than the plaintext. For cipher
> purposes, you need too be able to encrypt say 128 bits in a block -
> there are some 64-bit block ciphers still around, but they are
> deprecated, and some people say you need 256 bits in a block nowadays.

Yeah. There are ways to pack more precision, but there is a limit... Go
to high, and they start going out of control wrt decryption.

> As a corollary to the above, the actual length needed for the ciphertext
> is ... variable, which is a bit disconcerting.
>
> Another corollary, you might have to check whether each block decrypts
> correctly, so as to tell whether you have enough precision ..
>
> So in general it isn't that useful as a cipher.
>
> except ..
>
> it *may* have a slightly interesting security property, ie a strong
> proof of security.
>
> This is kinda a holy grail for some cryptologists, and if I am right
> about that, it may have some limited use.

I was kind of thinking along the same lines here.

>> Sounds easy right?
>
> Maybe if you are a chaos theorist ..
>
> - Peter Fairbrother
>
> ps ignore anything austinobyrne has to say - he is a well-known idiot.

All that aside for a moment, well, it is still good to be friendly? :^o

>>
>> :-)
>>
>> The efficiency of the encrypted coding scheme has to do with
>> the fractal dimension of the Julia set, and the degree of
>> imbalance of the contractivity in the tree traversal of the
>> Julia set."
>
> ps nope, that makes no sense to me either ..

It has to do with how much data the scheme can contain in a single
complex number vs how big these darn things are going to actually be.
AFAICT, they are related to the dimension of the fractal:

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

I kind of boils down to the fact that we are storing single bits from
basically one dimensional data (single number) into two dimensions
(single number, comprised of two parts). The imaginary part takes up
extra space in the ciphertext, the 2d point is bigger than the 1d point!



I really need more time to work on this damn it!

[Chris M. Thomasson]

I think I may have figured out a way to store two numbers in the range
of -999999999999 to +999999999999, along with a byte. In addition to
encrypting a byte with +- roots, we use an origin point for (z) that
stores these two integers. I think the range of these extra numbers are
around 6 bytes each. So, it looks like I can store 13 bytes in a single
16 byte complex number based on two 8 byte doubles. Now, this extra byte
can be a random number, or hold anything we want. Humm... So, the idea
is to simply set (z) to an origin point that contains actual data. This
value of (z) will be restored during decryption. Here is some example data:


Encrypting values: -12301, 989854412345 and 63

z = { -12301, 989854412345 }
c = { -.74543, .11301 }
_____________________________________
z[origin]:((-12301.000000000000000,989854412345.000000000000000)
z[0]:(1) = (703510.625379827688448,703510.634121880866587)
z[1]:(1) = (921.527561135795622,381.708887927776345)
z[2]:(1) = (30.986873249490291,6.157379527378633)
z[3]:(1) = (5.658407163514809,0.534105213067071)
z[4]:(1) = (2.531946317498929,0.083156425978855)
z[5]:(1) = (1.810371315513342,-0.008245152186550)
z[6]:(-1) = (-1.599136856993362,0.037912687602776)
z[7]:(-1) = (-0.040599543843387,0.924854139826196)

Decryption:
------------------------------------------------------------
z[7]:(-1) = (-0.040599543843388,0.924854139826196)
z[6]:(-1) = (-1.599136856993362,0.037912687602775)
z[5]:(1) = (1.810371315513342,-0.008245152186545)
z[4]:(1) = (2.531946317498928,0.083156425978872)
z[3]:(1) = (5.658407163514803,0.534105213067157)
z[2]:(1) = (30.986873249490127,6.157379527379598)
z[1]:(1) = (921.527561135773453,381.708887927834041)
z[0]:(1) = (703510.625379742938094,703510.634121970389970)
z[end]:((-12301.000000000000000,989854412345.000000000000000)
_____________________________________
pt:63 == db:63


This is working. BTW, I am also rounding the final numbers. This
restores problems where the right number is just one digit off, but the
decimal is very close like. 989854412344.789...

This is experimental, but it seems to be working. Trial decrypt is very
important here!

;^o

[Chris M. Thomasson]

On 6/26/2016 8:52 AM, Peter Fairbrother wrote:

> On 21/02/16 21:38, Chris M. Thomasson wrote:

[...]

> For example, what is the n-th level set? Is it the same thing as the
> target set? (if so, please don't call it by two different names... )

[...]

FWIW, here is an animation of the n-th level sets as
anit-equipotentials: the field lines if you will. Basically the
perpendicular field that can also be used to store data:

https://en.wikibooks.org/wiki/Fractals/Iterations_in_the_complex_plane/Julia_set#/media/File:From_decomposition_to_checkerboard.gif

Here is a fairly crude animation I made of field lines:

http://funwithfractals.atspace.cc/ct_fdla_anime_test_0
(it runs a little slow on a phone...)

[Chris M. Thomasson]

On 6/30/2016 11:15 AM, Chris M. Thomasson wrote:
> I think I may have figured out a way to store two numbers in the range
> of -999999999999 to +999999999999, along with a byte. In addition to
> encrypting a byte with +- roots, we use an origin point for (z) that
> stores these two integers. I think the range of these extra numbers are
> around 6 bytes each. So, it looks like I can store 13 bytes in a single
> 16 byte complex number based on two 8 byte doubles. Now, this extra byte
> can be a random number, or hold anything we want. Humm... So, the idea
> is to simply set (z) to an origin point that contains actual data. This
> value of (z) will be restored during decryption. Here is some example data:

[...]

FWIW, there is a direct connect between the level of precision loss and
the size of the integers we store in the origin point (z).
(+-999999999999) for real and imaginary parts of (z) are about as far as
I can push this thing before shi% hits the damn fan during the decoding
process. Numbers less than that, say (+-9999999999) just get more and
more precise, and that is nice!

[Chris M. Thomasson]

On 6/30/2016 11:15 AM, Chris M. Thomasson wrote:

> I think I may have figured out a way to store two numbers in the range
> of -999999999999 to +999999999999, along with a byte. In addition to
> encrypting a byte with +- roots, we use an origin point for (z) that
> stores these two integers. I think the range of these extra numbers are
> around 6 bytes each. So, it looks like I can store 13 bytes in a single
> 16 byte complex number based on two 8 byte doubles. Now, this extra byte
> can be a random number, or hold anything we want. Humm... So, the idea
> is to simply set (z) to an origin point that contains actual data. This
> value of (z) will be restored during decryption. Here is some example data:

[...]

> This is experimental, but it seems to be working. Trial decrypt is very
> important here!

There are many possibilities wrt taking advantage of the extra byte wrt
using +- roots in reverse iteration. We can store plaintext bytes in the
origin points and use random numbers in the extra byte to scramble the
ciphertext even further. Or, we can use it to store information about
the block. We can use the high nibble for random data, and the lower
nibble for information about the block. We can use it for an exponent to
store larger numbers wrt the range of (+-999999999999).

We can store an entire channel of auxiliary/meta data in the extra byte.

This is very interesting to me.

[Chris M. Thomasson]

On 2/21/2016 1:38 PM, Chris M. Thomasson wrote:
[...]

I am thinking on how to crack this thing. So far, using the following
arbitrary precision library:

https://mikemcl.github.io/decimal.js

allows me to store plaintext in a (single complex number) of a (custom
fitted precision) by performing (trial decrypts) and (adding more
precision) during (reverse iteration).

However, if we were to turn this into a block based cipher, then the
number of complex numbers would be increased; greater than one. Okay, so
if we send a large ciphertext with a lot of complex numbers each
representing a block, well, Eve can simply plot those fuc%ing things and
get a visual insight into possible orbits of (c)! Her job is still hard
because (c) can be a thousand digits. However, she can get close to the
initial area; damn it. The more points we send as ciphertext, the easier
Eve's job gets wrt just plotting them. I can get around this by sending
a single point, or using my existing forward iteration fractal
encryption to heavily disguise each point in the block style
implementation of the reverse fractal cipher. Heck, I can increase
precision and encrypt garbage/random meaningless bits to try and hide
each point. Single point is super hard to crack, multiple points are
easier. The webpage I am working on only deals with reverse fractal in
block style mode, however I am also creating a hybrid with this and my
existing work. Online example:

http://funwithfractals.atspace.cc/ffe

;^)

[Christian Gollwitzer]

Am 01.07.16 um 23:23 schrieb Chris M. Thomasson:
> Online example:
>
> http://funwithfractals.atspace.cc/ffe
>

There is a bug in the decryptor.

I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE

If I change only a single byte and decrypt

6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu

First I thought it is a flaw, but encrypting again gives a different
ciphertext.

Christian

[Chris M. Thomasson]

On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:
> Am 01.07.16 um 23:23 schrieb Chris M. Thomasson:
>> Online example:
>>
>> http://funwithfractals.atspace.cc/ffe
>>
>
> There is a bug in the decryptor.

I don't think there is, but lets see here.

> I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE

Okay.

> If I change only a single byte and decrypt
>
> 6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu
>
> First I thought it is a flaw,

This is normal. You changed a single byte in the ciphertext. It will
change a single byte in the plaintext. I will do this right now.

The plaintext is
___________________
Christian
___________________


the ciphertext with the default key is:
___________________
0.059597818467851275 0.069599977755982
0.060204896883700613 0.20476592051063616

37 57 40 E6 4B AF 31 4A 83
___________________

You can check this by going to the page, pasting the ciphertext in the
ciphertext box. Click decrypt, and you get your first name.

Now... If I change a single byte, say the last (83), to say (38), and
hit decrypt I get:

______________________
Christia#
______________________


Now, If it hit encrypt again, I get a ciphertext of:
______________________
0.3368721280009776 0.4406627195365929
0.2638329392146355 0.16157543875510105

83 96 47 12 D5 23 FF 60 37
______________________


This decrypts into

______________________
Christia#
______________________



AFAICT, there is no bug. Can you please try out the ciphertext I posted
with the default key and tell me what happens?

> but encrypting again gives a different
> ciphertext.

Yes. Each time you click encrypt it will give a different cipher text
because it inserts an offset location into the ciphertext. These are the
4 base 10 decimal numbers. Each time you click encrypt it randomizes
this IV.

[Chris M. Thomasson]

On 7/2/2016 12:25 PM, Chris M. Thomasson wrote:
> On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:
>> Am 01.07.16 um 23:23 schrieb Chris M. Thomasson:
>>> Online example:
>>>
>>> http://funwithfractals.atspace.cc/ffe
>>>
>>
>> There is a bug in the decryptor.
>
> I don't think there is, but lets see here.
>
>> I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE
>
> Okay.
>
>
>> If I change only a single byte and decrypt
>>
>> 6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu
>>
>> First I thought it is a flaw,
>
> This is normal. You changed a single byte in the ciphertext. It will
> change a single byte in the plaintext.

When you have the secret key, or private key in the webpage, a single
change to a byte in the ciphertext creates a single change in the
resulting plaintext. This is normal.

[Chris M. Thomasson]

On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:

> Am 01.07.16 um 23:23 schrieb Chris M. Thomasson:
>> Online example:
>>
>> http://funwithfractals.atspace.cc/ffe
>>
>
> There is a bug in the decryptor.
>
> I tried: Plaintext -> 6D 32 B0 90 0F 50 4F E3 DE

I am sorry, did you use the hexbyte ciphertext for another plaintext?

I get garbage when I map these bytes to ascii table:

m2[blah]

Or, are these hexbytes derived from the ciphertext of a plaintext you
encrypted on the page? I am wondering because there are no axes, the 4
decimal numbers. I cannot decrypt this because I need those darn axes.

[Christian Gollwitzer]

Am 02.07.16 um 21:28 schrieb Chris M. Thomasson:

If it's not a bug, then I think it is a flaw. I didn't bother to read
through your algorithm description, and my knowledge of encryption is
shallow - but I know that in modern algorithms, each bit of the output
is dependent on each bit of the input and the key. I think otherwise it
makes it vulnerable to known plaintext attacks. Or is each byte a block
in your block cipher (for demonstration purposes?)

However I do not understand how the website works. If I hit encrypt
multiple times, I get different answers with different public keys, yet
the same private key. Is this intended? I would have expected that there
is a "Generate key" button, and a button "encrypt" and another one
"decrypt" so that I can encrypt different texts with the same key over
and over again.

Christian

[Chris M. Thomasson]

On 7/2/2016 1:41 PM, Christian Gollwitzer wrote:
> Am 02.07.16 um 21:28 schrieb Chris M. Thomasson:
>> On 7/2/2016 12:25 PM, Chris M. Thomasson wrote:
>>> On 7/1/2016 11:17 PM, Christian Gollwitzer wrote:
>>>>
>>>> If I change only a single byte and decrypt
>>>>
>>>> 6D 32 B0 90 0F 50 4F E3 DF -> Plaintexu
>>>>
>>>> First I thought it is a flaw,
>>>
>>> This is normal. You changed a single byte in the ciphertext. It will
>>> change a single byte in the plaintext.
>>
>> When you have the secret key, or private key in the webpage, a single
>> change to a byte in the ciphertext creates a single change in the
>> resulting plaintext. This is normal.
>
> If it's not a bug, then I think it is a flaw. I didn't bother to read
> through your algorithm description, and my knowledge of encryption is
> shallow - but I know that in modern algorithms, each bit of the output
> is dependent on each bit of the input and the key. I think otherwise it
> makes it vulnerable to known plaintext attacks. Or is each byte a block
> in your block cipher (for demonstration purposes?)

Each byte is a block. It transforms each byte in the plaintext to a
point in the complex plane.

>
> However I do not understand how the website works. If I hit encrypt
> multiple times, I get different answers with different public keys, yet
> the same private key. Is this intended?

Yes! Also, my terminology wrt private/public key is flawed. The private
key should be secret key, and public key should be the random IV sent
along with the ciphertext. I used the word pubic because it gets sent
out for an attacker to see.

> I would have expected that there
> is a "Generate key" button, and a button "encrypt" and another one
> "decrypt" so that I can encrypt different texts with the same key over
> and over again.

You can generate different ciphertexts with the same key. Just keep
hitting the encrypt button, and see how the ciphertext changes. If you
change a single byte in the plaintext, all of the ciphertext bytes
change. This is a fairly decent avalanche effect. However, if you change
a single byte in the ciphertext, a single change will occur in the
decrypted plaintext. This is normal.

[Chris M. Thomasson]

On 7/1/2016 2:23 PM, Chris M. Thomasson wrote:
> On 2/21/2016 1:38 PM, Chris M. Thomasson wrote:
> [...]
>
> I am thinking on how to crack this thing. So far, using the following
> arbitrary precision library:

[...]

There is a flaw, Peter Fairbrother noticed it... The problem is the sign
of the real part is the first bit of a real byte in the damn plaintext!
This is crap: Total garbage. However, how can we hide a single complex
number, with around 90 points of precision? Can we just multiply it by a
complex with irrationals 90 points deep for real and imaginary parts,
try to get it back, and add more bits until we can? Can we just expand
the secret key space from a single (c), to multiple (c) and an offset to
hide this point? I think we can also add an randomized IV to the
ciphertext, along with encrypting random bytes. Also, we can use forward
iteration (c) using each byte of the plaintext as a pixel, to hide the
final point of reverse iteration. I am thinking of a hybrid of all the
above.

If we have a single point, it should be easy to hide? However, a block
cipher would give up much more information about the hiding process. I
think a single point is "more secure" if we cleverly hide its digits.

A clever combination of my existing forward iteration with Juaquin's
reverse iteration will produce a single point with many digits and a
random IV as the ciphertext that will not give any clear insight of the
first bit of the plaintext.

[Chris M. Thomasson]

On 7/2/2016 2:37 PM, Chris M. Thomasson wrote:
> On 7/1/2016 2:23 PM, Chris M. Thomasson wrote:
>> On 2/21/2016 1:38 PM, Chris M. Thomasson wrote:
>> [...]
>>
>> I am thinking on how to crack this thing. So far, using the following
>> arbitrary precision library:
> [...]
>
> There is a flaw, Peter Fairbrother noticed it... The problem is the sign
> of the real part is the first bit of a real byte in the damn plaintext!
> This is crap: Total garbage.

I mean, the sign of the real part of the single arbitrary precision
complex number in the _ciphertext_ will be a byte in the plaintext. So,
we need to hide this single point. Block cypher makes it more difficult.

Any clever ideas? Suggestions?

Thank you all.

[Chris M. Thomasson]

On 7/2/2016 2:18 PM, Chris M. Thomasson wrote:
> On 7/2/2016 1:41 PM, Christian Gollwitzer wrote:

[...]

>> I would have expected that there
>> is a "Generate key" button,

That's an interesting question in and of it self. How can we generate
these secret keys? I think we can use existing fractal explorer
programs, or something simple like the one I made here, just click on a
point-of-interest to zoom in:

http://webpages.charter.net/appcore/fractal/webglx/ct_complex_field.html
(a crude webgl experiment I made)


Its very crude, but all clickable points are valid (c)'s, this is only
in 32 bit precision, however I can do this with arbitrary precision for
very complex and sensitive values of (c). Zooming in just means that the
clickable surface area of (c) will have more digits of precision to
target the zoom just right. So, one can click in many times, and get to
a place, then click on a "capture secret key" button or something. Bang!
They have one.

Hummm... I need to think a lot more on this. Any thoughts on using
fractal explorers to generate secret keys?

Thanks again.

[Chris M. Thomasson]

On 2/21/2016 1:38 PM, Chris M. Thomasson wrote:
> Original idea by Juaquin Anderson in the comments of the
> following thread:

[...]

Here is pretty neat projection to the integer plane that really
increases storage efficiency:

Reverse Fractal Encryption 1d Integer Plane:

https://xp-dev.com/svn/FractalCodes/trunk

[Chris M. Thomasson]

On 2/21/2016 1:38 PM, Chris M. Thomasson wrote:

> Original idea by Juaquin Anderson in the comments of the
> following thread:

[...]

> What do you think about the code? Is it crap?
>
> ;^)
>
>
> Thank you all.

Well, it does seem to be vulnerable to known plaintext attack, Eve is
smart with many spies. I think a single point is hard, well if I sent a
shi% load of them, then Eve's tap will just plot them and get visually
close to the secret key, comprised of a single complex number and an
origin point that is random for each ciphertext. Still, Eve should not
get naked points from reverse iteration. The should be hidden.
Encrypting random bytes, and using entropy from forward iteration will
help. Also, radically increasing the key space with several (c)'s and
random IV's and direct hiding of the points. Also, we have not even got
into zooming, and the effects it casts. Yes we have a single (c) in the
secret key, but, we can add a zoom level.... This increases key space
right off the bat.

Any other ideas? I do not think this is totally doomed.