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

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:

https://i.ibb.co/4R2NXLM/image.png

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

[...]

> 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

On 7/5/2024 4:29 PM, colin wrote:
>> 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...

On 7/07/24 09:24, Chris M. Thomasson wrote:
> On 7/5/2024 4:29 PM, colin wrote:
>>> 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 )

On 7/6/2024 2:58 PM, colin wrote:
> On 7/07/24 09:24, Chris M. Thomasson wrote:
>> On 7/5/2024 4:29 PM, colin wrote:
>>>> 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.

:^)

> 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?

On 7/7/2024 12:33 PM, Chris M. Thomasson wrote:
> On 7/6/2024 2:58 PM, colin wrote:
>> On 7/07/24 09:24, Chris M. Thomasson wrote:
>>> On 7/5/2024 4:29 PM, colin wrote:
>>>>> 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.
>
> :^)
>
>
>> 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.

>
> 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 <chris.m.thomasson.1@gmail.com> wrote:
> 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.

On 7/7/2024 8:10 PM, Rich wrote:
> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> 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:
[...]

> 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.

On 7/7/2024 10:34 PM, Chris M. Thomasson wrote:
> On 7/7/2024 8:10 PM, Rich wrote:
>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
[...]
>> 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.

On 7/7/2024 10:37 PM, Chris M. Thomasson wrote:
> On 7/7/2024 10:34 PM, Chris M. Thomasson wrote:
>> On 7/7/2024 8:10 PM, Rich wrote:
>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> [...]
>>> 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

On 7/5/2024 1:45 PM, Chris M. Thomasson wrote:
> 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

:^)

On 7/7/2024 10:41 PM, Chris M. Thomasson wrote:
> On 7/7/2024 10:37 PM, Chris M. Thomasson wrote:
>> On 7/7/2024 10:34 PM, Chris M. Thomasson wrote:
>>> On 7/7/2024 8:10 PM, Rich wrote:
>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> [...]
>>>> 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

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!