This is version 0.0.0.0, and decrypting is _slow_. So beware as it can
lock up the browser while waiting for the decryption process to
complete. Encryption is definitely faster than decryption. I have an
idea that would increase the decryption by several orders of magnitude,
should work. That will be in version 0.0.0.1. Basically, it would
eliminate searching for a root for a symbol during decryption. This is
hard coded to hexbytes, so it makes power 16 Julias.

To eliminate the lock up during encryption/decryption I can use
WebWorkers and/or the animation loop in version 0.0.0.1:

http://fractallife247.com/test/rifc_cipher

The ciphertext is the real and imaginary parts of a complex number. So,
here is the name of a group "sci.crypt", encrypted in a complex number
using 128 digits of precision. I have an idea to search for an ideal
precision for any plaintext. The user would not have to worry about
manually entering in a precision. Its hard coded at 128 digits now, now
way to change it except by altering my JS code.

real:

-0.94663620135166780019794463049314550766304439084042331566030420526574461454955598072140428280633385050544450858241456620471182823

imag:

0.32931108752907156908170889543382519175253406054957362774132682738685455267759728128397029204309717808677120255541538509711747233

Copy and paste the real part into the ciphertext real textbox, and do
the same for the imaginary part. Then, click decrypt and you should see
"sci.crypt" in the plaintext textbox in a couple of seconds. If you make
a mistake, it will take a while, 20-30 seconds to attempt decryption as
best it can. This is using 128 digits of precision.

Fwiw, I did this for fun, because in further versions one can actually
generate fractal images using plaintext! The Julia key at -.75+.1i can
generate that Julia while storing the actual plaintext within it! I find
this to be great fun. The cipher itself, as-is, cannot be secure because
if I generate a lot of ciphertext complex numbers with different
plaintexts, using the same key, and plotted them... Well, it would end
up rendering the Julia from that key! lol. This is just for fun.

I can make it stronger, but for now, its pure fun. I really need to put
up a canvas element to plot things on. Double fun. Also, I need it to
generate a url with the real and imaginary components of the ciphertext
within it. Parse the url, and automatically put them in the correct
places in the page. Something like this:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=bf8cf62fef505c4cd92dfb3eb66c1874de741822c8de965d519eb915985a9fe6ad79f0a96114064f75116c44ede9a5b1a137449f40e6e963330658828d296762b561c357abad2200582c97bfa7353f944ce9a78912552003039b8fd7d27f81323e5c27ce4ac884ac13ad217bd13e13bf4e98a446c23ce9cba9dd5ffe163f55068caadd0f434323d9dfe2

;^)

On Thursday, June 3, 2021 at 4:28:13 PM UTC-4, Chris M. Thomasson wrote:
> This is version 0.0.0.0, and decrypting is _slow_. So beware as it can
> lock up the browser while waiting for the decryption process to
> complete. Encryption is definitely faster than decryption. I have an
> idea that would increase the decryption by several orders of magnitude,
> should work. That will be in version 0.0.0.1. Basically, it would
> eliminate searching for a root for a symbol during decryption. This is
> hard coded to hexbytes, so it makes power 16 Julias.
>
> To eliminate the lock up during encryption/decryption I can use
> WebWorkers and/or the animation loop in version 0.0.0.1:
>
> http://fractallife247.com/test/rifc_cipher
>
> The ciphertext is the real and imaginary parts of a complex number. So,
> here is the name of a group "sci.crypt", encrypted in a complex number
> using 128 digits of precision. I have an idea to search for an ideal
> precision for any plaintext. The user would not have to worry about
> manually entering in a precision. Its hard coded at 128 digits now, now
> way to change it except by altering my JS code.
>
> real:
>
> -0.94663620135166780019794463049314550766304439084042331566030420526574461454955598072140428280633385050544450858241456620471182823
>
> imag:
>
> 0.32931108752907156908170889543382519175253406054957362774132682738685455267759728128397029204309717808677120255541538509711747233

I tried it on 'the cat is out of the bag' and then tried adjusting digits. It's not very sensetive to the end digits. Could be that javascript is just using doubles and you've got excess digits.

It would be really fun if strange but coherent messages came back when you tweak the digits.
Instead I eventually just got a bunch of rectangular non chars coming back. Could mod out the unicode and bring it down to ASCII.

>
> Copy and paste the real part into the ciphertext real textbox, and do
> the same for the imaginary part. Then, click decrypt and you should see
> "sci.crypt" in the plaintext textbox in a couple of seconds. If you make
> a mistake, it will take a while, 20-30 seconds to attempt decryption as
> best it can. This is using 128 digits of precision.
>
> Fwiw, I did this for fun, because in further versions one can actually
> generate fractal images using plaintext! The Julia key at -.75+.1i can
> generate that Julia while storing the actual plaintext within it! I find
> this to be great fun. The cipher itself, as-is, cannot be secure because
> if I generate a lot of ciphertext complex numbers with different
> plaintexts, using the same key, and plotted them... Well, it would end
> up rendering the Julia from that key! lol. This is just for fun.
>
> I can make it stronger, but for now, its pure fun. I really need to put
> up a canvas element to plot things on. Double fun. Also, I need it to
> generate a url with the real and imaginary components of the ciphertext
> within it. Parse the url, and automatically put them in the correct
> places in the page. Something like this:
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=bf8cf62fef505c4cd92dfb3eb66c1874de741822c8de965d519eb915985a9fe6ad79f0a96114064f75116c44ede9a5b1a137449f40e6e963330658828d296762b561c357abad2200582c97bfa7353f944ce9a78912552003039b8fd7d27f81323e5c27ce4ac884ac13ad217bd13e13bf4e98a446c23ce9cba9dd5ffe163f55068caadd0f434323d9dfe2
>
> ;^)

On 6/4/2021 6:00 AM, Timothy Golden wrote:
> On Thursday, June 3, 2021 at 4:28:13 PM UTC-4, Chris M. Thomasson wrote:
>> This is version 0.0.0.0, and decrypting is _slow_. So beware as it can
>> lock up the browser while waiting for the decryption process to
>> complete. Encryption is definitely faster than decryption. I have an
>> idea that would increase the decryption by several orders of magnitude,
>> should work. That will be in version 0.0.0.1. Basically, it would
>> eliminate searching for a root for a symbol during decryption. This is
>> hard coded to hexbytes, so it makes power 16 Julias.
>>
>> To eliminate the lock up during encryption/decryption I can use
>> WebWorkers and/or the animation loop in version 0.0.0.1:
>>
>> http://fractallife247.com/test/rifc_cipher
>>
>> The ciphertext is the real and imaginary parts of a complex number. So,
>> here is the name of a group "sci.crypt", encrypted in a complex number
>> using 128 digits of precision. I have an idea to search for an ideal
>> precision for any plaintext. The user would not have to worry about
>> manually entering in a precision. Its hard coded at 128 digits now, now
>> way to change it except by altering my JS code.
>>
>> real:
>>
>> -0.94663620135166780019794463049314550766304439084042331566030420526574461454955598072140428280633385050544450858241456620471182823
>>
>> imag:
>>
>> 0.32931108752907156908170889543382519175253406054957362774132682738685455267759728128397029204309717808677120255541538509711747233
>
> I tried it on 'the cat is out of the bag' and then tried adjusting digits. It's not very sensetive to the end digits. Could be that javascript is just using doubles and you've got excess digits.

I am using Decimal.js so its not using doubles. However, you are 100%
correct that its not sensitive to mutating the ciphertext. This is in
deep contrast to my HMAC cipher where altering a single bit of the
ciphertext results in radically different decrypted plaintext. Try
altering a single bit of the following ciphertext:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b315e017bd632bb05b6331fd8794a1844abef2f1b40593780437f66f382f385a38b50cf63ecdebae4d098e5fd6cc67cce0848fbe23ff8122493cf365e78f8b3be991756c6f6a80689344ebe7ff340dcc2284d91d984711f895

Click on the link, then alter the ciphertext, click decrypt and it will
give a radically different plaintext.

Now, my RIFC is just a toy, a fun project that proves that it is
possible to store data in a complex number using a Julia set fractal.
Well, I think its fun... ;^)

My HMAC cipher is a real cipher. My RIFC is a toy. However, it is going
to be fun to make RIFC more sensitive, and more secure.

> It would be really fun if strange but coherent messages came back when you tweak the digits.

That would be really fun!

> Instead I eventually just got a bunch of rectangular non chars coming back. Could mod out the unicode and bring it down to ASCII.

Right now, my RIFC is working on hexbytes so it is using a power of 16
Julia set. Another fun aspect is that one can plot a Julia set by
literally plotting multiple ciphertexts on the complex plane. I should
have some more time later on today to show fractal images being
generated from multiple plaintexts. Also, I have to make it use an
animation loop or even WebWorkers so that it can run in the background
and not lock up the god damn browser during processing! Yikes. Sorry
about the long processing times! ;^/

Fwiw, here is the ciphertext I get for your plaintext "the cat is out of
the bag", between the quotes:

real:

-0.73711886500038428868668555096685774528445498224902290534933225169283348834444548659405143360762622066528368196206473276783879997

imag:

0.5475361748522650026629688507418667669962462472177686566185020900262796304775785674928556029035968137002078440815240497311989775

It works, but not sensitive. Humm... I am using 128 digits of precision
here as a hard coded default. I have an idea that would generate a
ciphertext with the minimal amount of precision. I just have not
implemented it yet. Wait for version 0.0.0.1. ;^)

Using the minimal amount of precision should increase sensitivity.

By the way, thank you for giving it a go!

:^)

[...]

On 6/4/2021 1:53 PM, Chris M. Thomasson wrote:
> On 6/4/2021 6:00 AM, Timothy Golden wrote:
>> On Thursday, June 3, 2021 at 4:28:13 PM UTC-4, Chris M. Thomasson wrote:
>>> This is version 0.0.0.0, and decrypting is _slow_. So beware as it can
>>> lock up the browser while waiting for the decryption process to
>>> complete. Encryption is definitely faster than decryption. I have an
>>> idea that would increase the decryption by several orders of magnitude,
>>> should work. That will be in version 0.0.0.1. Basically, it would
>>> eliminate searching for a root for a symbol during decryption. This is
>>> hard coded to hexbytes, so it makes power 16 Julias.
>>>
>>> To eliminate the lock up during encryption/decryption I can use
>>> WebWorkers and/or the animation loop in version 0.0.0.1:
>>>
>>> http://fractallife247.com/test/rifc_cipher
>>>
>>> The ciphertext is the real and imaginary parts of a complex number. So,
>>> here is the name of a group "sci.crypt", encrypted in a complex number
>>> using 128 digits of precision. I have an idea to search for an ideal
>>> precision for any plaintext. The user would not have to worry about
>>> manually entering in a precision. Its hard coded at 128 digits now, now
>>> way to change it except by altering my JS code.
>>>
>>> real:
>>>
>>> -0.94663620135166780019794463049314550766304439084042331566030420526574461454955598072140428280633385050544450858241456620471182823
>>>
>>>
>>> imag:
>>>
>>> 0.32931108752907156908170889543382519175253406054957362774132682738685455267759728128397029204309717808677120255541538509711747233
>>>
>>
>> I tried it on 'the cat is out of the bag' and then tried adjusting
>> digits. It's not very sensetive to the end digits. Could be that
>> javascript is just using doubles and you've got excess digits.
>
> I am using Decimal.js so its not using doubles. However, you are 100%
> correct that its not sensitive to mutating the ciphertext. This is in
> deep contrast to my HMAC cipher where altering a single bit of the
> ciphertext results in radically different decrypted plaintext. Try
> altering a single bit of the following ciphertext:
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b315e017bd632bb05b6331fd8794a1844abef2f1b40593780437f66f382f385a38b50cf63ecdebae4d098e5fd6cc67cce0848fbe23ff8122493cf365e78f8b3be991756c6f6a80689344ebe7ff340dcc2284d91d984711f895
>
>
> Click on the link, then alter the ciphertext, click decrypt and it will
> give a radically different plaintext.
>
> Now, my RIFC is just a toy, a fun project that proves that it is
> possible to store data in a complex number using a Julia set fractal.
> Well, I think its fun... ;^)
>
> My HMAC cipher is a real cipher. My RIFC is a toy. However, it is going
> to be fun to make RIFC more sensitive, and more secure.
>
>
>> It would be really fun if strange but coherent messages came back when
>> you tweak the digits.
>
> That would be really fun!
>
>
>> Instead I eventually just got a bunch of rectangular non chars coming
>> back. Could mod out the unicode and bring it down to ASCII.
>
> Right now, my RIFC is working on hexbytes so it is using a power of 16
> Julia set. Another fun aspect is that one can plot a Julia set by
> literally plotting multiple ciphertexts on the complex plane. I should
> have some more time later on today to show fractal images being
> generated from multiple plaintexts. Also, I have to make it use an
> animation loop or even WebWorkers so that it can run in the background
> and not lock up the god damn browser during processing! Yikes. Sorry
> about the long processing times! ;^/
>
>
> Fwiw, here is the ciphertext I get for your plaintext "the cat is out of
> the bag", between the quotes:
>
> real:
>
> -0.73711886500038428868668555096685774528445498224902290534933225169283348834444548659405143360762622066528368196206473276783879997
>
>
> imag:
>
> 0.5475361748522650026629688507418667669962462472177686566185020900262796304775785674928556029035968137002078440815240497311989775
>
>
>
> It works, but not sensitive. Humm... I am using 128 digits of precision
> here as a hard coded default. I have an idea that would generate a
> ciphertext with the minimal amount of precision. I just have not
> implemented it yet. Wait for version 0.0.0.1. ;^)
>
> Using the minimal amount of precision should increase sensitivity.
>
> By the way, thank you for giving it a go!
>
> :^)
>
>
> [...]

To clarify, encrypting the a single A, or the same plaintext multiple
times in a row using the exact same secret key, gives the same
ciphertext. This is bad to me. Very bad!

;^o Ouch.

I feel bad for trying to use some aspects of my secure HMAC encryption
as a base for this, which would make my experimental fractal cipher a
heck of a lot more secure. It feels like cheating!