info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
my highly experimental RIFC is online...
29 views
Skip to first unread message
Chris M. Thomasson
Jun 3, 2021, 4:01:10 PM6/3/21
to
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 this 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
;^)
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 this 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
;^)
Chris M. Thomasson
Jun 3, 2021, 5:00:35 PM6/3/21
to
On 6/3/2021 1:01 PM, 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 this 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
>
[...]
> 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 this 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 encrypted a youtube link here:
real:
-0.44522927646106797862921274074342758409573999592862476419126622693651958264434921654091616918946448906203355266470620799321636871
imag:
0.88136653485196831497593821841243667499596931040860439001562416209416442374028137753913244828471874958358366817539478332179351311
Can you decrypt it?
Chris M. Thomasson
Jun 10, 2021, 6:54:14 PM6/10/21
to
On 6/3/2021 1:01 PM, 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.
[...]
> 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.
This is has to be open to attack! Known plaintext should hurt it really
bad. Lets encrypt a single A:
-0.0039515378043068135821667885002556418995438007518213724464522143111695139243766773436030826491752345508363794213455500663395289003
1.0318692707265907745223932953406058981891692914000433146986920275114237742646958989251792088228424642163845314095570908650067524
means the letter A using the default key. Encrypting a single A multiple
times in a row gives the exact same ciphertext.
Lets encrypt two A's using the default key:
-0.012989571487827561197256587465491885541215971523966508394828409233816836724448477680832090798856645146732219441334037454162310944
1.0334563605404757151533956699947626427609615892184085915556036292587047174914618874267710841402909251725386333763204482550511212
Okay, but Eve knows what plaintext equals the known ciphertext because
there is no random element to this. So, encrypting AA multiple times
will give the exact same ciphertext.
This seems really wrong to me. Bad!
Also, since there is no random element, encrypting different random
plaintexts and plotting their points on the complex plane will build a
fractal that shows the secret key point!
Wow.
Chris M. Thomasson
Jun 10, 2021, 8:07:46 PM6/10/21
to
On 6/10/2021 3:54 PM, Chris M. Thomasson wrote:
> On 6/3/2021 1:01 PM, 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.
> [...]
>
> This is has to be open to attack! Known plaintext should hurt it really
> bad. Lets encrypt a single A:
>
> -0.0039515378043068135821667885002556418995438007518213724464522143111695139243766773436030826491752345508363794213455500663395289003
>
>
> 1.0318692707265907745223932953406058981891692914000433146986920275114237742646958989251792088228424642163845314095570908650067524
>
>
> means the letter A using the default key. Encrypting a single A multiple
> times in a row gives the exact same ciphertext.
To clarify, encrypting the a single A, or the same plaintext multiple
> On 6/3/2021 1:01 PM, 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.
> [...]
>
> This is has to be open to attack! Known plaintext should hurt it really
> bad. Lets encrypt a single A:
>
> -0.0039515378043068135821667885002556418995438007518213724464522143111695139243766773436030826491752345508363794213455500663395289003
>
>
> 1.0318692707265907745223932953406058981891692914000433146986920275114237742646958989251792088228424642163845314095570908650067524
>
>
> means the letter A using the default key. Encrypting a single A multiple
> times in a row gives the exact same ciphertext.
times in a row using the exact same secret key, gives the same
ciphertext. This is bad to me. Very bad!
;^o Ouch.
[...]
0 new messages