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!