Hey sci.crypt,

I wanted an encrypted and authenticated "secret box" like thing. Instead
of the usual IV + encrypted blob + MAC combination, I wanted to explore
the problem space and have a little fun.

I used an unbalanced Feistel network, with one part being a single byte.
For this, I needed a round function that can take the rest of the block
along with a key, and reduce it into a single byte. I go through the
entire block and perform N rounds of Feistel for an N-byte block.

A standard Merkle-Damgard hash works well for this, but there are a ton of
options that can work for this purpose. Perhaps something to explore in
the future.

"Regular" solutions are really malleable. Depending on the block cipher
mode, it is quite easy to modify the ciphertext to affect the plaintext in
predictable ways. This goes from flipping bits while only breaking a
single block all the way to being able to make arbitrary modifications as
long as you know the plaintext. This causes MACs to have a massive
importance.

With this mode, any change to the ciphertext affects the entire plaintext
in a random way. It sort of An ASCII message ceases to be meaningful text,
a JSON message ceases to be valid JSON etc. Depending on the security
target, a MAC can be completely left out. Or a fixed string somewhere can
be used in place of a MAC, like every valid block starting/ending with
0xCAFEBABE to have the same effect as a 32-bit MAC.

Have any of you used a similar construction anywhere? I'd be curious to
know what you think, I had a lot of fun playing around with this, and it
even ended up having some convenient properties.

I'm putting a small example in Python with SHA-256 as the round function.

import hashlib

def sha256(x: bytes) -> int: return hashlib.sha256(x).digest()[0]

def encrypt(buf: bytes, key: bytes) -> bytes:
key = len(key).to_bytes(8, 'little') + key

for _ in range(len(buf)):
left, right = buf[0], buf[1:]
new_right = sha256(key + right) ^ left
buf = right + bytes([new_right])

return buf

def decrypt(buf: bytes, key: bytes) -> bytes:
key = len(key).to_bytes(8, 'little') + key

for _ in range(len(buf)):
left, right = buf[:-1], buf[-1]
new_left = sha256(key + left) ^ right
buf = bytes([new_left]) + left

return buf

while True:
action = input("'encrypt' or 'decrypt'? ")
if action not in ('encrypt', 'decrypt'): continue
key = input("key: ").encode("utf-8")
buf = input("data: ")

if action == 'encrypt':
buf = buf.encode("utf-8")
print(encrypt(buf, key).hex())
elif action == 'decrypt':
buf = bytes.fromhex(buf)
print(decrypt(buf, key))

--
Leo

On 2/1/2024 1:58 PM, Leo wrote:
> Hey sci.crypt,
>
> I wanted an encrypted and authenticated "secret box" like thing. Instead
> of the usual IV + encrypted blob + MAC combination, I wanted to explore
> the problem space and have a little fun.
>
> I used an unbalanced Feistel network, with one part being a single byte.
> For this, I needed a round function that can take the rest of the block
> along with a key, and reduce it into a single byte. I go through the
> entire block and perform N rounds of Feistel for an N-byte block.
>
> A standard Merkle-Damgard hash works well for this, but there are a ton of
> options that can work for this purpose. Perhaps something to explore in
> the future.
>
> "Regular" solutions are really malleable. Depending on the block cipher
> mode, it is quite easy to modify the ciphertext to affect the plaintext in
> predictable ways. This goes from flipping bits while only breaking a
> single block all the way to being able to make arbitrary modifications as
> long as you know the plaintext. This causes MACs to have a massive
> importance.
>
> With this mode, any change to the ciphertext affects the entire plaintext
> in a random way. It sort of An ASCII message ceases to be meaningful text,
> a JSON message ceases to be valid JSON etc. Depending on the security
> target, a MAC can be completely left out. Or a fixed string somewhere can
> be used in place of a MAC, like every valid block starting/ending with
> 0xCAFEBABE to have the same effect as a 32-bit MAC.
>
> Have any of you used a similar construction anywhere? I'd be curious to
> know what you think, I had a lot of fun playing around with this, and it
> even ended up having some convenient properties.

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.

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

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

It sure seems to be fairly, "secure"... Although it has not been
properly peer reviewed yet. So, experimental is shall remain... ;^)

>
> I'm putting a small example in Python with SHA-256 as the round function.
>
> import hashlib
>
> def sha256(x: bytes) -> int: return hashlib.sha256(x).digest()[0]
>
> def encrypt(buf: bytes, key: bytes) -> bytes:
> key = len(key).to_bytes(8, 'little') + key
>
> for _ in range(len(buf)):
> left, right = buf[0], buf[1:]
> new_right = sha256(key + right) ^ left
> buf = right + bytes([new_right])
>
> return buf
>
> def decrypt(buf: bytes, key: bytes) -> bytes:
> key = len(key).to_bytes(8, 'little') + key
>
> for _ in range(len(buf)):
> left, right = buf[:-1], buf[-1]
> new_left = sha256(key + left) ^ right
> buf = bytes([new_left]) + left
>
> return buf
>
> while True:
> action = input("'encrypt' or 'decrypt'? ")
> if action not in ('encrypt', 'decrypt'): continue
> key = input("key: ").encode("utf-8")
> buf = input("data: ")
>
> if action == 'encrypt':
> buf = buf.encode("utf-8")
> print(encrypt(buf, key).hex())
> elif action == 'decrypt':
> buf = bytes.fromhex(buf)
> print(decrypt(buf, key))
>
>

On 2/1/2024 2:06 PM, Chris M. Thomasson wrote:
> On 2/1/2024 1:58 PM, Leo wrote:
>> Hey sci.crypt,
>>
>> I wanted an encrypted and authenticated "secret box" like thing. Instead
>> of the usual IV + encrypted blob + MAC combination, I wanted to explore
>> the problem space and have a little fun.
>>
>> I used an unbalanced Feistel network, with one part being a single byte.
>> For this, I needed a round function that can take the rest of the block
>> along with a key, and reduce it into a single byte. I go through the
>> entire block and perform N rounds of Feistel for an N-byte block.
>>
>> A standard Merkle-Damgard hash works well for this, but there are a
>> ton of
>> options that can work for this purpose. Perhaps something to explore in
>> the future.
>>
>> "Regular" solutions are really malleable. Depending on the block cipher
>> mode, it is quite easy to modify the ciphertext to affect the
>> plaintext in
>> predictable ways. This goes from flipping bits while only breaking a
>> single block all the way to being able to make arbitrary modifications as
>> long as you know the plaintext. This causes MACs to have a massive
>> importance.
>>
>> With this mode, any change to the ciphertext affects the entire plaintext
>> in a random way. It sort of An ASCII message ceases to be meaningful
>> text,
>> a JSON message ceases to be valid JSON etc. Depending on the security
>> target, a MAC can be completely left out. Or a fixed string somewhere can
>> be used in place of a MAC, like every valid block starting/ending with
>> 0xCAFEBABE to have the same effect as a 32-bit MAC.
>>
>> Have any of you used a similar construction anywhere? I'd be curious to
>> know what you think, I had a lot of fun playing around with this, and it
>> even ended up having some convenient properties.
>
> 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.
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=6eb6ffcc4ecce8d2f154fd52fb847accc4904df790294012eea5570f619d65a3a2cc0e682a0298274a692955fbd3d77ed0fd15812e0afbc1c8f5e5d47a8ebc7026ad512165ad6207961f1c5eb731e704
>
> 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...
>
> It sure seems to be fairly, "secure"... Although it has not been
> properly peer reviewed yet. So, experimental is shall remain... ;^)

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.

>
>
>
>>
>> I'm putting a small example in Python with SHA-256 as the round function.
>>
>> import hashlib
>>
>> def sha256(x: bytes) -> int: return hashlib.sha256(x).digest()[0]
>>
>> def encrypt(buf: bytes, key: bytes) -> bytes:
>>      key = len(key).to_bytes(8, 'little') + key
>>
>>      for _ in range(len(buf)):
>>          left, right = buf[0], buf[1:]
>>          new_right = sha256(key + right) ^ left
>>          buf = right + bytes([new_right])
>>
>>      return buf
>>
>> def decrypt(buf: bytes, key: bytes) -> bytes:
>>      key = len(key).to_bytes(8, 'little') + key
>>
>>      for _ in range(len(buf)):
>>          left, right = buf[:-1], buf[-1]
>>          new_left = sha256(key + left) ^ right
>>          buf = bytes([new_left]) + left
>>
>>      return buf
>>
>> while True:
>>      action = input("'encrypt' or 'decrypt'? ")
>>      if action not in ('encrypt', 'decrypt'): continue
>>      key = input("key: ").encode("utf-8")
>>      buf = input("data: ")
>>
>>      if action == 'encrypt':
>>          buf = buf.encode("utf-8")
>>          print(encrypt(buf, key).hex())
>>      elif action == 'decrypt':
>>          buf = bytes.fromhex(buf)
>>          print(decrypt(buf, key))
>>
>>
>

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.
Have you run any tests on how many random bit flips / modifications you
need in order to have something that is all ASCII? 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.

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

--
Leo

On Thu, 1 Feb 2024 21:58:23 -0000 (UTC), Leo wrote:

> "Regular" solutions are really malleable. Depending on the block cipher
> mode, it is quite easy to modify the ciphertext to affect the plaintext
> in predictable ways. This goes from flipping bits while only breaking a
> single block all the way to being able to make arbitrary modifications
> as long as you know the plaintext. This causes MACs to have a massive
> importance.
>
> With this mode, any change to the ciphertext affects the entire
> plaintext in a random way. It sort of

Oops, looks like I forgot to finish my sentence there.

I mean to say, "It sort of behaves like an All-or-nothing transform".

--
Leo

On 01/02/2024 22:06, Chris M. Thomasson wrote:
> On 2/1/2024 1:58 PM, Leo wrote:
>> Hey sci.crypt,
>>
>> I wanted an encrypted and authenticated "secret box" like thing. Instead
>> of the usual IV + encrypted blob + MAC combination, I wanted to explore
>> the problem space and have a little fun.
>
> Fwiw, [...]

Chris: please stop trying to turn every thread into 'look at my highly
experimental hmac cipher wotsit'

On 2/2/2024 8:42 AM, Richard Harnden wrote:
> On 01/02/2024 22:06, Chris M. Thomasson wrote:
>> On 2/1/2024 1:58 PM, Leo wrote:
>>> Hey sci.crypt,
>>>
>>> I wanted an encrypted and authenticated "secret box" like thing. Instead
>>> of the usual IV + encrypted blob + MAC combination, I wanted to explore
>>> the problem space and have a little fun.
>>
>> Fwiw, [...]
>
> Chris:  please stop trying to turn every thread into 'look at my highly
> experimental hmac cipher wotsit'
>
>

Not meant as a hijack at all. My apologies to Leo. Do you have any
constructive comments, or examples of other ciphers that might be similar?

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.

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

Also, when you get some free time to burn, try to put your idea up on
the web, where you contain ciphertext in the actual URL. Something like
this:

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

On 2/5/2024 10:31 PM, Chris M. Thomasson wrote:
> On 2/5/2024 10:26 PM, Chris M. Thomasson wrote:
>> 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.
[...]

Fwiw, also, wrt the way I am using HMAC, well, I am feeding it plaintext
as well. So this makes it kind of like MAC'ing a completed ciphertext.
Humm... The ciphertext/plaintext sensitivity is pretty damn good in
these types of ciphers Leo. You already know that, but its interesting
to me. Prepending TRNG numbers to the plaintext larger than a digest is
very important. These random numbers get fed in the HMAC chain, if you
will...