On 2/1/2024 2:49 PM, Leo wrote:
> On Thu, 1 Feb 2024 14:10:48 -0800, Chris M. Thomasson wrote:
>
>>> Nice! I need to study this some more for sure. Thanks Leo! :^)
>>>
>>> Fwiw, I am kind of busy right now... Basically, it kind of reminds me
>>> of one of my experimental HMAC ciphers. Altering a single byte of the
>>> ciphertext causes a radically different plaintext to be generated,
>>> random? Humm... A radically different ciphertext is generated on every
>>> encryption of the exact same cipher text:
>>>
>>>
http://funwithfractals.atspace.cc/ct_cipher/
>>>
>>> Fwiw, here in an online example using the default key to encrypt.
>
> HMAC would fit into this cipher very naturally too. Instead of sha256(key
> + data), you'd do hmacsha256(key, data).
>
>>> The online version has an option of sha-256 and sha-512 in the secret
>>> key. You should be able to click on the link, and see the decrypted
>>> message since it uses the default key.
>
>>> Fwiw, as of now, it does not use a final MAC...
>
> I am wondering if a proper MAC is even with these kinds of constructions.
Interesting because the plaintext is basically "randomized" if a single
bit of the ciphertext and/or password is altered. Since I think adding
what HMAC and HASH to use should be in the secret key itself, well, that
is a factor... ;^)
> Have you run any tests on how many random bit flips / modifications you
> need in order to have something that is all ASCII?
No. Well, I don't think so. You mean trying to flips bits until the
generated plaintext wrt decrypting is all ASCII? Or do you mean
something else I am missing? Thanks Leo.
> I think especially with
> things with humans in the loop (like messaging or emails), it will be very
> obvious if someone is tampering with the message.
Humm... I need to create a new thread to test drive this. Btw, I did not
mean to hijack your thread with my work. I am glad that you are
experimenting around with these types of cipher schemes. Thanks!
>
>>> It sure seems to be fairly, "secure"... Although it has not been
>>> properly peer reviewed yet. So, experimental is shall remain... ;^)
>
> It's possible to mess up, of course, but using HMAC-SHA256 is a very safe
> bet.
I second that. It seems to be okay to "abuse" HMAC like this. Humm. Not
100% sure on that. But, it sure "seems" to be okay.
> You can be pretty much 100% sure that any vulnerabilities or problems
> will arise from your own code or protocol instead of the core primitive.
> This is very useful, much less code to comb over and usually much simpler
> code too.
>
> And especially HMACs are very forgiving, pretty hard to misuse those.
>
> When someone posts on sci.crypt with a completely custom construction it's
> more likely to be broken by someone here. Can't say the same about people
> re-using SHA-256.
>
>> Also, try altering a single bit of the password and/or ciphertext, or
>> changing the hash function, then clicking decrypt. The plaintext will be
>> radically different.
>
> Yep, this is what made me want the entire message in one "block" too.
> Block ciphers have excellent avalanche/garbling with unintended
> modifications, but it's usually only for a single block. So if you have
> your entire message and nonce/IV in a single block, everything has this
> useful property.
>
I just use enough digests, or blocks if you will to cover any sized
plaintext.