HMAC cipher and a TRNG...

[Chris M. Thomasson]

If anybody ever chooses to play around with my HMAC cipher, be sure to
remove the call to the PRNG that is used to create the random numbers in
the plaintext. Remove the call and replace it with a TRNG. It is meant
to use a TRNG, but my experimental implementation uses Java's prng. My
cipher is not even meant to be used with a CSPRNG! It needs a TRNG, damn
it! I think it should be hard to find a period in a TRNG. For instance,
is this a number? Think of a base 10 number where each digit uses a TRNG
for its value, 0 through 9.

A decimal expansion with regard to digits, for instance:

TRNG().[TRNG(), TRNG(), TRNG(), ...]

Is this a number, or not a number.

A 10-ary die should be able to do this, right?

Here is an example of my HMAC Cipher example. You should all be able to
examine the plaintext because it was encrypted using the default key.
Now, keep in mind, that if I encrypted this again, it would have a
different ciphertext. This is where I _really_ need to use a TRNG in a
real impl, so to speak...

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

[Chris M. Thomasson]

On 7/5/2024 1:45 PM, Chris M. Thomasson wrote:
[...]

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

I cut off the link above for brevity. Here is a screenshot of what you
should get on your end such you click on the link:

Loading Image...

Here is my critical code, gui aside for a moment...:

https://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/ct_main.js

Notice the following function:
________________________
function ct_rand_bytes(n) {
var output = new Array();

for (var i = 0; i < n; ++i) {
var byte = Math.floor(Math.random() * 255);
output.push(byte);
}

return output;
}
________________________

Okay, Math.random() needs to be a TRNG, damn it!!!!!!!!!!!

;^o

[...]

[colin]

Post by Chris M. Thomasson
Here is an example of my HMAC Cipher example. You should all be able to
examine the plaintext because it was encrypted using the default key.
Now, keep in mind, that if I encrypted this again, it would have a
different ciphertext.

Security 101 - don't reuse passwords

[Chris M. Thomasson]

Post by colin

Post by Chris M. Thomasson
Here is an example of my HMAC Cipher example. You should all be able
to examine the plaintext because it was encrypted using the default
key. Now, keep in mind, that if I encrypted this again, it would have
a different ciphertext.

Security 101 - don't reuse passwords

:^) Indeed. However, creating radically different ciphertexts for the
same plaintext and password on a per-encryption bases is interesting to
me... Humm...

[colin]

Post by Chris M. Thomasson

Post by colin

Post by Chris M. Thomasson
Here is an example of my HMAC Cipher example. You should all be able
to examine the plaintext because it was encrypted using the default
key. Now, keep in mind, that if I encrypted this again, it would have
a different ciphertext.

Security 101 - don't reuse passwords

:^) Indeed. However, creating radically different ciphertexts for the
same plaintext and password on a per-encryption bases is interesting to
me... Humm...

Your advertising campaign seems to to be pushing this fact as a selling
point.

quote -
"Fwiw, it creates new ciphertexts for every encryption even with the
same password and/or plaintext."

Where your encryption is only as strong as a compromised reused
password. ( ie: pointless )

[Chris M. Thomasson]

Post by colin

Post by Chris M. Thomasson

Post by colin

Post by Chris M. Thomasson
Here is an example of my HMAC Cipher example. You should all be able
to examine the plaintext because it was encrypted using the default
key. Now, keep in mind, that if I encrypted this again, it would
have a different ciphertext.

Security 101 - don't reuse passwords

:^) Indeed. However, creating radically different ciphertexts for the
same plaintext and password on a per-encryption bases is interesting
to me... Humm...

Your advertising campaign seems to to be pushing this fact as a selling
point.

Selling point, what do you mean? This is an experiment! It would be fun
if somebody could bust it wide open. Where they don't need a damn
password, the ciphertext is all they need. That would be fun to learn
about. Advertising campaign as in I need it to be properly examined
before it can be used at all. Forever experimental it shall be.

:^)

Post by colin
quote -
"Fwiw, it creates new ciphertexts for every encryption even with the
same password and/or plaintext."
Where your encryption is only as strong as a compromised reused
password. ( ie: pointless )

A compromised secret password is bad. I was just interested if I could
create different ciphertexts for the same plaintext and password, as an
experiment. See?

[Chris M. Thomasson]

Post by Chris M. Thomasson

Post by colin

Post by Chris M. Thomasson

Post by colin

Post by Chris M. Thomasson
Here is an example of my HMAC Cipher example. You should all be
able to examine the plaintext because it was encrypted using the
default key. Now, keep in mind, that if I encrypted this again, it
would have a different ciphertext.

Security 101 - don't reuse passwords

:^) Indeed. However, creating radically different ciphertexts for the
same plaintext and password on a per-encryption bases is interesting
to me... Humm...

Your advertising campaign seems to to be pushing this fact as a
selling point.

Selling point, what do you mean? This is an experiment! It would be fun
if somebody could bust it wide open. Where they don't need a damn
password, the ciphertext is all they need. That would be fun to learn
about. Advertising campaign as in I need it to be properly examined
before it can be used at all. Forever experimental it shall be.
:^)

Post by colin
quote -
"Fwiw, it creates new ciphertexts for every encryption even with the
same password and/or plaintext."
Where your encryption is only as strong as a compromised reused
password. ( ie: pointless )

If somebody has your secret key for any symmetric cipher, well, that is
bad, right? I must be missing something.

Post by Chris M. Thomasson
A compromised secret password is bad. I was just interested if I could
create different ciphertexts for the same plaintext and password, as an
experiment. See?

[Rich]

A compromised secret password is bad. I was just interested if I
could create different ciphertexts for the same plaintext and
password, as an experiment. See?

Slightly revisionist history.

IIRC you were worried about having all bits of the plaintext change if
any one bit of the ciphertext was changed by Eve.

Because if all you were worried about was different ciphertexts from
same key and plaintext, that is already available from standard
constructions. Note this short example:

#!/usr/bin/tclsh

package require aes ;# aes encryption module

proc hexdump {value} {
binary scan $value H* hex
return $hex
}

set fd [open /dev/urandom {RDONLY BINARY}]

# IV #1
set iv1 [read $fd 16]

# IV #2
set iv2 [read $fd 16]

# key
set key [read $fd 16]

# plaintext
set pt [read $fd 32]

# ciphertext #1
puts "before creating ciphertext #1"
puts key=[hexdump $key]
puts "pt =[hexdump $pt]"
set ct1 [aes::aes -mode cbc -dir encrypt -key $key -iv $iv1 $pt]

# ciphertext #2 - same plaintext and key
puts "before creating ciphertext #2"
puts key=[hexdump $key]
puts "pt =[hexdump $pt]"
set ct2 [aes::aes -mode cbc -dir encrypt -key $key -iv $iv2 $pt]

# display cipher texts
puts ct1=[hexdump $ct1]
puts ct2=[hexdump $ct2]

This uses AES, and CBC mode. Running the above code (assuming you have
Tcl and Tcllib installed, results in:

before creating ciphertext #1
key=5726ed430f6b2f4ec4c18e68d77385a2
pt =e17752182f07dd0239ce09308b6f4912a043567f0df79fb176baf996d0772e4c
before creating ciphertext #2
key=5726ed430f6b2f4ec4c18e68d77385a2
pt =e17752182f07dd0239ce09308b6f4912a043567f0df79fb176baf996d0772e4c
ct1=ee68def5cb2978215356b585fe87d74a99a7786c08c6559594c82d0102c258b2
ct2=ae0b908dc7049a4608e57cd94249d00850b63ae1d1b9d4416fb8dda692df0da2

Same key, same plaintext, two different ciphertexts.

[Chris M. Thomasson]

Post by Rich

A compromised secret password is bad. I was just interested if I
could create different ciphertexts for the same plaintext and
password, as an experiment. See?

Slightly revisionist history.
IIRC you were worried about having all bits of the plaintext change if
any one bit of the ciphertext was changed by Eve.
Because if all you were worried about was different ciphertexts from
same key and plaintext, that is already available from standard

[...]

Post by Rich
Same key, same plaintext, two different ciphertexts.

Both. I wanted each encryption using the same key and plaintext to
create radically different ciphertexts.

Also, I wanted it to be bit sensitive. If a single bit of ciphertext is
altered it will decrypt to random junk.

My HMAC Cipher experiment does both.

I think those are interesting things.

[Chris M. Thomasson]

[...]

Post by Chris M. Thomasson

Post by Rich
Same key, same plaintext, two different ciphertexts.

Both. I wanted each encryption using the same key and plaintext to
create radically different ciphertexts.
Also, I wanted it to be bit sensitive. If a single bit of ciphertext is
altered it will decrypt to random junk.
My HMAC Cipher experiment does both.
I think those are interesting things.

You can play around with this on my site. Try altering the ciphertext in
anyway, and hit decrypt. The plaintext will be random garbage. It would
help if my site used a real TRNG, but oh well for now.

[Chris M. Thomasson]

Post by Chris M. Thomasson
[...]

Post by Chris M. Thomasson

Post by Rich
Same key, same plaintext, two different ciphertexts.

Both. I wanted each encryption using the same key and plaintext to
create radically different ciphertexts.
Also, I wanted it to be bit sensitive. If a single bit of ciphertext
is altered it will decrypt to random junk.
My HMAC Cipher experiment does both.
I think those are interesting things.

You can play around with this on my site. Try altering the ciphertext in
anyway, and hit decrypt. The plaintext will be random garbage. It would
help if my site used a real TRNG, but oh well for now.

Right now it's using hexbytes for ciphertext for the online version, my
parser could be better. Anyway, here is a version of it in C that you
can play around with:

https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ

[Chris M. Thomasson]

Post by Chris M. Thomasson

Post by Chris M. Thomasson
[...]

Post by Chris M. Thomasson

Post by Rich
Same key, same plaintext, two different ciphertexts.

Both. I wanted each encryption using the same key and plaintext to
create radically different ciphertexts.
Also, I wanted it to be bit sensitive. If a single bit of ciphertext
is altered it will decrypt to random junk.
My HMAC Cipher experiment does both.
I think those are interesting things.

You can play around with this on my site. Try altering the ciphertext
in anyway, and hit decrypt. The plaintext will be random garbage. It
would help if my site used a real TRNG, but oh well for now.

Right now it's using hexbytes for ciphertext for the online version, my
parser could be better. Anyway, here is a version of it in C that you
https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ

Just wondering if you found some time to compile my work in C99. If so,
did you give it a go? run it? Then you can perform your personal tests
against it. Have fun!

[Chris M. Thomasson]

Post by Chris M. Thomasson
If anybody ever chooses to play around with my HMAC cipher, be sure to
[...]

If you don't like my hmac cipher, you might like this:

https://paulbourke.org/fractals/multijulia

:^)