Logo by kr0mat1k - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Follow us on Twitter
 
*
Welcome, Guest. Please login or register. October 03, 2022, 07:41:24 AM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: 1 [2]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Encrypted Fractal Root Storage...  (Read 3168 times)
Description: Storing information inside of escape time fractals...
0 Members and 1 Guest are viewing this topic.
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #15 on: May 30, 2016, 09:20:19 PM »

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.
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #16 on: June 30, 2016, 10:57:59 PM »

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]sad(-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]sad-1) = (-1.599136856993362,0.037912687602776)
z[7]sad-1) = (-0.040599543843387,0.924854139826196)

Decryption:
------------------------------------------------------------
z[7]sad-1) = (-0.040599543843388,0.924854139826196)
z[6]sad-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]sad(-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!
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #17 on: July 01, 2016, 06:27:45 AM »

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!
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #18 on: July 02, 2016, 12:01:39 AM »

 
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!
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #19 on: July 02, 2016, 12:02:27 AM »

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

;^)
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #20 on: July 02, 2016, 11:53:19 PM »

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.
Logged
TheRedshiftRider
Fractalist Chemist
Global Moderator
Fractal Iambus
******
Posts: 854



WWW
« Reply #21 on: July 03, 2016, 08:25:50 AM »

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

Motivation is like a salt, once it has been dissolved it can react with things it comes into contact with to form something interesting. nerd
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #22 on: July 06, 2016, 12:24:45 AM »


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! :^)
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #23 on: July 06, 2016, 12:27:16 AM »

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

Thank you very much!  :^)
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #24 on: July 10, 2016, 11:09:19 PM »

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

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

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

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

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.
Logged
TheRedshiftRider
Fractalist Chemist
Global Moderator
Fractal Iambus
******
Posts: 854



WWW
« Reply #25 on: July 11, 2016, 08:36:31 AM »


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

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

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

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

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?
Logged

Motivation is like a salt, once it has been dissolved it can react with things it comes into contact with to form something interesting. nerd
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #26 on: July 12, 2016, 01:26:01 AM »

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/1h9c5HVpBQAJ

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.
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #27 on: July 14, 2016, 02:58:39 AM »


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
Logged
Chris Thomasson
Conqueror
*******
Posts: 137



« Reply #28 on: July 14, 2016, 06:58:20 AM »

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) + "]sad" + 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) + "]sad" + 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)sad-0.9551091176839042+0.5035767961580385j)
z[3]:(3)sad-0.4377271477816378-0.7365056013652742j)
z[4]:(4):(0.07042003964910772-0.9729932435136784j)
z[5]:(4):(0.13904278139280354-1.0515670852882053j)
z[6]:(3)sad-0.9711340891379753-0.46491924409551966j)
z[7]:(2)sad-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)sad-0.4734106347448228+0.7678784601618056j)
z[6]:(3)sad-0.9711340891379746-0.46491924409551677j)
z[5]:(4):(0.1390427813927817-1.0515670852882062j)
z[4]:(4):(0.0704200396489919-0.9729932435137526j)
z[3]:(3)sad-0.43772714778204685-0.7365056013657469j)
z[2]:(2)sad-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
« Last Edit: July 14, 2016, 08:05:22 AM by Chris Thomasson » Logged
Pages: 1 [2]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Xenon-135 Storage Facility Mandelbulb3D Gallery lenord 0 383 Last post July 22, 2011, 06:47:32 PM
by lenord
Storage Node Mandelbulb3D Gallery PO 0 508 Last post March 15, 2012, 09:57:48 AM
by PO
Propeller Storage Wildstyle ClydeFrog 0 571 Last post May 25, 2012, 12:29:22 AM
by ClydeFrog
The Root Fractal - The One Plus Times Table? (new) Theories & Research kevinmorais 0 246 Last post September 16, 2013, 05:09:08 PM
by kevinmorais
Mysterious site with encrypted messages and quasi-quasi-fuchsian fractal (?) Fractal News across the World KRAFTWERK 3 1032 Last post December 30, 2015, 08:47:54 PM
by KRAFTWERK

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.223 seconds with 24 queries. (Pretty URLs adds 0.008s, 2q)