Welcome to Fractal Forums

Check this out:

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

https://plus.google.com/+JuaquinAnderson/posts/L9A3Da8ju3B (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 (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.


Also, I have a fractal encryption scheme that is actually compatible with this using minimal changes of incorporation:

http://www.fractalforums.com/fractals-in-nature/fractal-encryption/ (http://www.fractalforums.com/fractals-in-nature/fractal-encryption/)

What do you think of the code?

I will look at the code now but the method sounds solid. This wasn't even an area of interest to me until yesterday I got the idea of doing the same thing with the Game Of Life (it is deterministic going forward but you can choose bits when going backward). This is MUCH more straight forward. Off to steal your code!
edit: The code seems to work fine - it would be awesome if it didn't lose precision! I will go experiment as well. Thanks for this!

nice idea!  I thought about doing something similar with external angles in the Mandelbrot set, but Julia sets are better as you can pick a secret key c.

Thank you for taking a look at the rather crude code. IMHO, it does indeed show how this can work. FWIW, here is another version of it that tests all bit patterns for a byte:

http://pastebin.com/VsvH3HdE (http://pastebin.com/VsvH3HdE)

I am thinking of doing an HTML 5 app that visually shows how this works. IMHO, it is basically like storing information in a waveform. Also, AFAICT, Juaquin Anderson's original description has an error in it. He says that the sign of the imaginary part determines the proper bits to turn on during forward iteration. The code I quickly created shows that the sign of the real part is key to recreating the bit pattern. The signs of the imaginary parts are different than the information that was encoded during reverse iteration.

Agreed! FWIW, the secret key c can be expanded into multiple c's during iteration. Think of a forward iteration like:

<quick pseudo-code>
___________________________________________

c[cmax] = { (julia point 0), (julia point 1), (julia point ...) };

for (unsigned int i = 0; i < imax; ++i)
{
    z = z^2 + c[i % cmax];
}

___________________________________________

One can expand the secret key space by using multiple Julia set seed points as c. FWIW, I have created some example renderings with this:

(http://nocache-nocookies.digitalgott.com/gallery/17/11687_18_04_15_8_48_41.jpeg)

(http://nocache-nocookies.digitalgott.com/gallery/18/11687_10_12_15_6_39_31.jpeg)

(http://nocache-nocookies.digitalgott.com/gallery/17/11687_15_04_15_2_45_16.jpeg)

These did not have encrypted bit storage in mind, but they are all compatible with the overall technique.

There are many ways to create a larger keyspace. The one I have for my current fractal encryption:

http://funwithfractals.atspace.cc/ffe/ (http://funwithfractals.atspace.cc/ffe/)

Is not that big, but gives an idea of how to do it.

Humm... Another thought. So, wrt using multiple secret key's as c. I think the bits of the plaintext can be used to select from a pool of c's. AFAICT, this would greatly expand the key space. Not only does reverse iteration store data wrt roots of the sqrt of c, but it has multiple c's to choose from. The secret key would contain an array of different c's. The bits of the plaintext determine what c to use. any thoughts? Is this a crap idea? Humm...

The precision loss is the bastard wall that is limiting the number of bits I can store in a complex number with double's. I can store 32, but anything larger than 40'ish starts to die, and produce radical errors during forward iteration, some bits actually decrypt, and others fail. I think an arbitrary precision lib can be used to store N bits in a single complex number. That would be interesting. I have not tried it yet. Humm...

Yep I hit the 40 bit limit right away as I was wondering if this can do compression. You can use arbitrary precision but the complex number will have more bits than what is encrypted. (2x32 bit floats to 40 bits) No compression there - but IF there is a formula that works with integers to create the same +/- encoding then you could compress an arbitrary length string of bits into 2 integers (no fear of losing precision). Seems impossible on the face of it, but fun to try.

FWIW, here is an example of using two secret keys at { -0.2, 0.0 } and { 0.3, 0.0 }:

(http://nocache-nocookies.digitalgott.com/gallery/19/11687_24_05_16_5_31_47.jpeg)

Yes. The secret key c is very interesting wrt how data can be stored. Very interesting.

 O0

Now, how to minimize precision loss!? Damn...  :alien:

Assuming I haven't completely misunderstood this concept, my preliminary experiments make it seem like it is trivial to find points that can reliably store 8 bytes, and not much harder to find ones that can store 9 or 10 bytes.  Higher than that might be impractically rare, and I'm going to take a wild guess and suggest that we won't find points that can reliably store more than 16 bytes while still being representable by two 64 bit floating point numbers.

I'll take a bit more time to try to understand what exactly is being described... because I'm definitely missing some parts still.  But if my subsequent playing around yields anything interesting, I'll post again.

Apeirographer

So far, I cannot find a point that can reliably store around 40 bits. If you can find one, please let me know. I have used points like { -0.74543, -0.11301 }, but they still fall apart during forward iteration wrt storing large numbers of bits! They start to escape during forward iteration, even though the reverse iteration keeps all points bounded to a "close" to the border formation. AFAICT, the precision loss starts to explode.

Damn!

FWIW, I think I managed to create a BuddaBrot like formation that is compatible with basically any reverse iteration Julia set. A crude initial example:

(http://nocache-nocookies.digitalgott.com/gallery/19/11687_25_05_16_10_44_43.jpeg)

It might be able to be used in this type of encryption. Humm... The code that produces this rendering should be posted tonight or tomorrow. BTW, thank you all your interest!

 :dink:

;^)

FWIW, the code for the reverse iteration wrt the "Buddhabrot" like reverse iterations can be found here:

https://plus.google.com/101799841244447089430/posts/UPf7RKrkiYm (https://plus.google.com/101799841244447089430/posts/UPf7RKrkiYm)

FWIW, I thank you all for any interest you have in this subject.

 :alien:

http://pastebin.com/d6L89bBZ (http://pastebin.com/d6L89bBZ)

I forgot to mention that the (c) for the function (ct_reversex) needs to be:

complex_t c = { 0.47, 0.7 };

 :-\

I thought you must be playing with the distance metric in that last pic because I was doing something similar s=sqrt(sqrt(x*x-y*y)) and getting similar lines. Thanks for sharing the code.

Exactly! I will try the s=sqrt(sqrt(x*x-y*y)) as well. Thank you.

I think I may have figured out a way to store two numbers in the range of negative 999999999999 to positive 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


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


Also, the precision is 15 decimal points. I need to do a lot more work on this. Example source code, and a little webpage is coming soon!

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!

 
FWIW, I am using a fairly nice big decimal library:

http://mikemcl.github.io/decimal.js
(trig functions are a bit slow on high precision numbers, but they work and allow a proof of concept to be created)

I am storing 256-bit blocks that require around 90 bit's of precision wrt significant digits. I am using an adaptive encryption algorithm that performs trial decryption, and adds more precision each time it fails. Basically, its the same thing that Peter Fairbrother described. He suggested trial decrypt, and adding more precision. Well, it works. I can store quite a bit of data in a single complex number. Here is a simple example ciphertext that stores the following string:

plaintext - 32-bytes, 256-bits:
_____________________________________________
Having Fun With Fractals is Good
_____________________________________________



ciphertext, 81 point of precision required:
_____________________________________________
x:-1.40671908764936961512398419133109623095250597042532480395711455165016474134535925

y:0.00944239408403734327190341674814485098947052840036562960580747161769090947636525034
_____________________________________________


Also, the precision can vary depending on the bit pattern of the 256-bit block of plaintext. Also, interesting deep zooms wrt the secret key (c) can be more efficient and require less precision overall.


This is awesome to me! The size of the ciphertext is pretty darn gnarly in size, but the security is pretty darn nice. Not sure how to crack the plaintext out of this. Humm...


Example webpage will be online in a couple of days. So far, its working very nicely.

Thank you Rich!

Juaquin's integer projection 32-bit technique aside for a moment...

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

;^)

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.

I totally forgot about this encryptor, it is such an amazing project.

Lets say Eve got her hands on a couple of plaintext bytes and the ciphertext that creates them: Yikes! How close can Eve get to the secret key (c) from this information alone?

The search space in this example is way lower than 256-bit...

Okay... Let's say for now, Eve happens to have the following information:
________________________________________
Plaintext byte: 253

Ciphertext:
---------------------
x: 1.215960450608117637827377
y: 0.01311725132325351761419796
---------------------
________________________________________



________________________________________
Plaintext byte: 103

Ciphertext:
---------------------
x:-1.167621845875606245712675
y:-0.112981805846028890427668
---------------------

Here is some other ciphertext she has, but does not know the byte values they decrypt to:
---------------------
x:0.05988579450856802710578819
y:0.9437085045171635933058951
---------------------
x:0.9326755532101024259716837
y:0.3806497564762469920651711
---------------------
________________________________________


I will try the simple attack described by Peter Fairbrother to see how close I can get to the secret key (c):

https://groups.google.com/d/msg/sci.crypt/mycXj0ViYaw/AGSMH3HhAgAJ

https://groups.google.com/d/msg/sci.crypt/mycXj0ViYaw/th3VxXOkAgAJ



This simulation is limited to complex numbers with 64-bit precision for now. Does Eve need more bytes in order to crack out a (c) that can decrypt many other bytes: such as the ciphertext she has, but does not yet know the plaintext they decode into?

If we can crack reverse fractal encryption at this low-level, with single bytes based 64-bit precision level, then we should gain a better insight into cracking it at the n-byte arbitrary precision level...

Any thoughts? I am working on the crack code now. This is going to be fun.

Thanks! :^)

Thank you very much!  :^)

 
Ummm... There is a nasty pattern in the ciphetext:

http://pastebin.com/2SRADkgn (http://pastebin.com/2SRADkgn) - 256 pairs

http://pastebin.com/GxgAjgeT (http://pastebin.com/GxgAjgeT) - 128 pairs

http://pastebin.com/Jcns9P8J (http://pastebin.com/Jcns9P8J) - 128 pairs

http://pastebin.com/YQDyYQwu (http://pastebin.com/YQDyYQwu) - 256 pairs

Eve is pissed off, and neutralized a couple of spies for the outrage!

Eve has been noticing that the real component of every damn ciphetext is fuc%king negative... Yet, her spies said nothing to her! This has been silently pissing Eve off to the point here she takes corrective action wrt some "higher ups" in her elaborate, fractal like spy network.

Wait, what do you mean with this?

Well, it means that the sign of the real part of every ciphetext point corresponds to a bit in the plaintext. This is an absolutely terrible information leak. I can get around this in many different ways. Encoding some random garbage bits might help.


Also, I wrt all of the cipher/plain text pairs I posted, well, the encoded bit pattern is backwards from the norm. So, I erroneously encoded the letter (A) as bit pattern (10000010), instead of the normal way of (01000001).

I got reamed on this one:

please, read all if interested:


https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/ucwRnv9nBQAJ (https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/ucwRnv9nBQAJ)

https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/1h9c5HVpBQAJ (https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/1h9c5HVpBQAJ)

https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/iq6SnoNqBQAJ (https://groups.google.com/forum/#!original/sci.crypt/ark0QZ6QW_8/iq6SnoNqBQAJ)

shi%!

Well, the nice thing is all of my posted cipher/plaintext works when my backwards way of storing bits is taken into account.



WRT Eve, Alice and Bob. I am trying to present the cipher/plain texts in a sort of, story like form.

From the thread: "Reverse Iteration Fractal Encryption"

On 7/3/2016 8:04 AM, Peter Fairbrother wrote:
> On 03/07/16 08:06, Chris M. Thomasson wrote:
>> On 7/2/2016 5:57 PM, Peter Fairbrother wrote:
>>> On 02/07/16 22:21, Chris M. Thomasson wrote:
>>>> On 7/2/2016 1:26 PM, Peter Fairbrother wrote:
>>>> [...]
>>>>> How this known plaintext attack works is, suppose the first bit of the
>>>>> message is 1, then an attacker can tell something about the key c -
>>>>> certain values of c in the 1st iteration will give a +ve real part,
>>>>> certain values won't.
>>>>
>>>> Okay, you much be referring to the fact that the first bit of the
>>>> message can be determined by looking at the sign of the real part. this
>>>> has to be hidden!
>>>
>>> No, I'm talking about the result of the first forward iteration, I was
>>> assuming the sign of the ciphertext would be unused.
>>>
>>>
>>> And that is not the weakness.
>>>
>>> Suppose an attacker knows a ciphertext z is 2,0. Suppose the attacker
>>> also knows the first bit of the relevant plaintext is 0.
>>>
>>> And you can't say an attacker can't know some plaintext/ciphertext
>>> pairs, that is assumed in the known-plaintext attack model.
>>>
>>> Iterating z' -> z^2 + c, we get z^2 = 4,0.
>>
>> How does the attacker get (c) to iterate the ciphertext in the first
>> place?
>>
>
> He doesn't.
>
> Writing the forward iteration as z' = z^2 + c
>
> The attacker knows z, from which he calculates z^2. He also knows the
> sign of the real part of z'.
>
> Initially, he does not know anything about c.
>
> But from those two pieces of information which he does know, he can find
> a limit on c.
>
> Considering only real parts [I will write as Re(x) is the real part of
> the complex number x] in my example we know that R(z') the real part of
> z', is negative, ie
>
> Re(z') < 0. Now we know
>
> Re(z') = Re(z)^2 + R(c), therefore
>
> Re(z)^2 + Re(c) < 0
>
> Re(c) < 0 - Re(z)^2
>
> Re(c) < 0 - 4
>
> Re(c) < -4.
>
> Thus the attacker learns a little about c.
>
> He repeats this, each time learning a little more about c, until he
> knows enough about c to reconstruct it exactly.
>
>
> Actually it is more complex than that, as an attacker can use the second
> and later iterations and their signs to put limits on both the real and
> imaginary parts of c - but I won't go into that math here.
>
> (mainly because I can't be bothered to work it out in detail, it is left
> as an exercise for the interested.
>
> It might be worth working through it, as it might be a little harder
> than I envisage to collect enough information to reconstruct c exactly.
>
> However from a cryptologist's point of view, as a cipher, the above is
> more than enough to say that, as a secure cipher, it is broken.)


My response, wow this is going to be fun, because I have already implemented it in C++, but I will post a Python version for The Wizz!
_______________________________________________________
This is great stuff! Thank you, I see how it works, yes its a little by little more difficult going up the power of two root tree, but it makes total sense. Okay, I think there is a very simple change that can be applied that might make this simple method much harder. Right now, we are working with a power of two. Well, I can use basically any real number for the power except for zero. Negative fractional roots, whatever. What if the ciphertext blocks each used a different power? Also, what if we used several different values of (c) during iteration? This would be a multi Julia set. So, lets say we have a list of ciphertext points. Each one uses a different power, and the same pool of several different values of (c)? Your method is based on z^2, well if block 0 uses an unknown power and several (c), and block 1 uses a different power and several (c)'s. how does your method work out then?

Keep in mind that if a block out of a batch of ciphertext is using something like 2.75 power, then its possible roots will be 3 and it will be encoded in ternary. If its something like 7.6 then its encoded in octal.

Also, keep in mind that the negative and positive aspects of the root only applies to powers of two! So, you get random powers for the ciphertext blocks, how do you do this? I need some help here. Does it make it more difficult?

Would this make things harder for your method?

Thanks Peter! :^)
_______________________________________________________

There is a way to save this, damn it!

;^o

I mentioned that we can use higher powers to encode more symbols than binary. Well, here is a quick example that uses quinary. It can encode five symbols (0, 1, 2, 3, 4). This means that we cannot use the sign of the root go get at the data anymore. Take a close look at the (encrypt_quinary) and (decrypt_quinary) functions. To decrypt we need to forward iterate (z^5+c) into (f), get (f - c)'s 5 roots, then find which one is closest to (z). This indexes directly into the 5 symbols. We then set z to f, and continue. I implemented an example in Python 3, check this out:

http://pastebin.com/mX0SG5kM
__________________________________________________
# Chris M. Thomasson 2016
# Reverse Fractal Iteration Quinary Encoding
# Does NOT work with fractional powers yet!
# Thats coming...


import math;


# Complex Roots
def croots(z, p):
    l = math.sqrt(z.real**2 + z.imag**2);
    s = l**(1.0 / p);
    a = math.atan2(z.imag, z.real) / p;

    n = math.ceil(math.fabs(p));
    astep = (math.pi * 2.0) / p;

    result = [];

    for i in range(n):
        r = complex(math.cos(a + astep * i) * s,
                    math.sin(a + astep * i) * s);
        # print(r);
        result.append(r);

    return result;


# Find Root
def froots(z, r):
    n = 0;
    for i in r:
        d = z - i;
        l = math.sqrt(d.real**2 + d.imag**2);
        if l < 0.000001: return n;
        n = n + 1;
    return -1;


# Encrypt quinary stream
def encrypt_quinary(z, c, p):
    n = 0;
    for i in p:
        r = croots(z - c, 5.0);
        z = r[int(i)];
        print("z[" + str(n) + "]:(" + i + "):" + str(z));
        n = n + 1;
    return z;

# Decrypt quinary stream
def decrypt_quinary(z, c, n):
    s = "";
    for i in range(n):
        f = z**5.0 + c;
        r = croots(f - c, 5.0);
        b = froots(z, r);
        s += str(b);
        print("z[" + str(n - i - 1) + "]:(" + str(b) + "):" + str(z));
        z = f;
    s = s[::-1];
    return s;




# The secret key (c), and origin point (z)
c = (-.75+.09j);
z = (0+0j);
pt0 = "0123443210";

n = len(pt0);

# Display our environment.
print("c:" + str(c));
print("z:" + str(z));
print("n:" + str(n));
print("pt0:" + str(pt0));
print("");


print("Encrypt Quinary: " + str(n) + " Iterations");
print("_________________________________________");
ct = encrypt_quinary(z, c, pt0);
print("_________________________________________");
print("");


print("Decrypt Quinary: " + str(n) + " Iterations");
print("_________________________________________");
pt1 = decrypt_quinary(ct, c, n);
print("_________________________________________");
print("");


print("pt1:" + pt1);

if pt0 != pt1: print("DATA CORRUPTED!!! ;^o");
__________________________________________________



I get an output of:
__________________________________________________
c:(-0.75+0.09j)
z:0j
n:10
pt0:0123443210

Encrypt Quinary: 10 Iterations
_________________________________________
z[0]:(0):(0.9451685793824627-0.02258038810019985j)
z[1]:(1):(0.35756437868104407+1.0527521186191984j)
z[2]:(2):(-0.9551091176839042+0.5035767961580385j)
z[3]:(3):(-0.4377271477816378-0.7365056013652742j)
z[4]:(4):(0.07042003964910772-0.9729932435136784j)
z[5]:(4):(0.13904278139280354-1.0515670852882053j)
z[6]:(3):(-0.9711340891379753-0.46491924409551966j)
z[7]:(2):(-0.4734106347448234+0.7678784601618063j)
z[8]:(1):(0.0727237491661892+0.9367275179453214j)
z[9]:(0):(1.0205658310765122+0.16465132844438568j)
_________________________________________

Decrypt Quinary: 10 Iterations
_________________________________________
z[9]:(0):(1.0205658310765122+0.16465132844438568j)
z[8]:(1):(0.0727237491661894+0.9367275179453213j)
z[7]:(2):(-0.4734106347448228+0.7678784601618056j)
z[6]:(3):(-0.9711340891379746-0.46491924409551677j)
z[5]:(4):(0.1390427813927817-1.0515670852882062j)
z[4]:(4):(0.0704200396489919-0.9729932435137526j)
z[3]:(3):(-0.43772714778204685-0.7365056013657469j)
z[2]:(2):(-0.9551091176843745+0.5035767961596559j)
z[1]:(1):(0.3575643786924483+1.0527521186182027j)
z[0]:(0):(0.9451685793976057-0.022580388186342365j)
_________________________________________

pt1:0123443210
__________________________________________________


Is this working for you?

FWIW, you run, play with the code here:

https://repl.it

Many thanks to +Juaquin Anderson for the original idea of storing binary! Wow. :^D