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

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

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!

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

;^)

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

Thank you very much!  :^)

Wait, what do you mean with this?

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