My HMAC Cipher is finally online...

[Chris M. Thomasson]

I finally put my experimental HMAC cipher up online... YEAH!

http://fractallife247.com/test/hmac_cipher

Try to decrypt the following ciphertext in between the lines. It is
using the default secret key. To decrypt it, just copy the ciphertext,
paste it into the Ciphertext box, and click the decrypt button:
_________________________________
78bc9bc6d4c1e1947fc6fb64da48b98c94e039ba65f7452daabe2be198d0dddb9cc0e752e04b37b6bd613246c4773b47af29ad46fdc1205004081c2f36b2e075a8e29bc108e5e2b0e63e79d6b5d895298c1bbb16c6f4
_________________________________

Can you get it to work?

So far, I am allowing the user to pick SHA-256, or SHA-512 as the hash
algorihtm. This algorithm choice is part of the secret key. I am going
to add more hashes, SHA-384, ect...

Thanks everybody! :^D

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> So far, I am allowing the user to pick SHA-256, or SHA-512 as the hash
> algorihtm. This algorithm choice is part of the secret key.

Is there any difference in the output (i.e., length of output, not
content) depending upon which hash is chosen?

[Chris M. Thomasson]

No. For an example, here is a ciphertext that uses SHA-256:
_____________________________
d53101a9de7984547dcbbb14d952fd5c61ecad249e576afefd08a23fca8943f425193236055357b5ec5118652458a4e9244990e9a1011744453bf1a42fd5f71ce5d805aefabf222ac0385a8dad5f746c380db763e2
_____________________________


And here is a ciphertext that uses SHA-512:
_____________________________
cfe8031ddf53e8e0837e9bf51e0fe0c657cd16fa15e520dd0275f1e444de5c752453702f9c7182f2d1cd60cca03e01127f40f52beddc420ca07d3cfa52a1f8418387e83a8c9c3d813f7f738b0e4bfeb6e2f403eec6
_____________________________

They both encrypt the exact same plaintext.

[Max]

On 20.05.21 16:18, Chris M. Thomasson wrote:
> I finally put my experimental HMAC cipher up online... YEAH!
>
> http://fractallife247.com/test/hmac_cipher

Nice!

>
> Try to decrypt the following ciphertext in between the lines. It is
> using the default secret key. To decrypt it, just copy the ciphertext,
> paste it into the Ciphertext box, and click the decrypt button:
> _________________________________
> 78bc9bc6d4c1e1947fc6fb64da48b98c94e039ba65f7452daabe2be198d0dddb9cc0e752e04b37b6bd613246c4773b47af29ad46fdc1205004081c2f36b2e075a8e29bc108e5e2b0e63e79d6b5d895298c1bbb16c6f4
>
> _________________________________
>
> Can you get it to work?

Yes, I can.

>
> So far, I am allowing the user to pick SHA-256, or SHA-512 as the hash
> algorihtm. This algorithm choice is part of the secret key. I am going
> to add more hashes, SHA-384, ect...

Why?

>
> Thanks everybody! :^D

[Rich]

My guess: For some reason no one has yet been able to properly convince
Chris of the value of Kerckhoffs's principle [1] and as a result he
continues to operate under the incorrect belief that keeping some part
of the algorithm secret is valuable.

Of course, as we are well aware, it is not valuable to do so. But
somehow it appears we have failed at convincing Chris of that fact.



[1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

[Max]

That might indeed be the case. When I read "algorithm choice is part of
the secret key" I just wondered, if all this extra complexity was just
for, say, 4 more bits for the key.

[Rich]

This is possibly where Chris' mental block originates. Although for
the example above it adds one bit, as there is only a selection between
two choices.

But he has previously argued, when pressed with Kerckhoffs's principle,
that he can't seem to wrap his mind around how "not hiding anything
about the algorithm" is actually better. In those arguments he's
usually fallen back to "but... but... but..., if Eve does not know
which hash Alice and Bob used, then Eve has more effort to first figure
that out".

[Max]

On 20.05.21 20:19, Rich wrote:
> Max <maxt...@gmx.net> wrote:
>> On 20.05.21 17:53, Rich wrote:
>>> Max <maxt...@gmx.net> wrote:
>>>> On 20.05.21 16:18, Chris M. Thomasson wrote:
>>>>> So far, I am allowing the user to pick SHA-256, or SHA-512 as the
>>>>> hash algorihtm. This algorithm choice is part of the secret key. I
>>>>> am going to add more hashes, SHA-384, ect...
>>>>
>>>> Why?
>>>
>>> My guess: For some reason no one has yet been able to properly convince
>>> Chris of the value of Kerckhoffs's principle [1] and as a result he
>>> continues to operate under the incorrect belief that keeping some part
>>> of the algorithm secret is valuable.
>>>
>>> Of course, as we are well aware, it is not valuable to do so. But
>>> somehow it appears we have failed at convincing Chris of that fact.
>>>
>>>
>>>
>>> [1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
>>>
>>
>> That might indeed be the case. When I read "algorithm choice is part of
>> the secret key" I just wondered, if all this extra complexity was just
>> for, say, 4 more bits for the key.
>
> This is possibly where Chris' mental block originates. Although for
> the example above it adds one bit, as there is only a selection between
> two choices.

In another discussion Chris told me he wants "as many hashes as I can
get", naming MD5, SHA1, SHA2-384, SHA3 and RMD160. The library he links
to in his Javascript implementation already includes some of those
hashes. He just hasn't implemented them (yet?). That's why I rounded up
to the maximum possible security effect I can see here.

>
> But he has previously argued, when pressed with Kerckhoffs's principle,
> that he can't seem to wrap his mind around how "not hiding anything
> about the algorithm" is actually better. In those arguments he's
> usually fallen back to "but... but... but..., if Eve does not know
> which hash Alice and Bob used, then Eve has more effort to first figure
> that out".
>

That's a pity, but I am confident, he'll get there eventually. It's not
that obscure.

[Chris M. Thomasson]

Well, it all started when I was first developing my experimental HMAC
cipher a couple of years ago. I wanted it to be able to be used with any
hash. So, I started with SHA2. Turns out that my algorihtm works with
all of the hashes in SHA2! I felt really good. So, I thought to myself,
my algorihtm is flexible enough to use any hash! So, I decided to keep it...

Then I thought that it just might be "fun" to allow the hash algorihtm
choice to be in the secret key itself, I thought, heck, why not... So,
for this try "zero", online version 0.0.0.0 JavaScript implementation of
my cipher, I added the ability for the user to choose what hash
algorihtm to use. Only have two choices of hash algorithms now. I really
want to add all of SHA2, SHA3, ect... At least, just to be able to see
how different hashes interact with my algorihtm...

The default key, when you go to the site is SHA-256. So, it makes things
"easy". Should I add some links on the page to this discussion?

Now, the Password textbox is the "main" aspect of the key. It is used
for an HMAC session as its key. Allowing the user to choose the hash
algorihtm could be labeled as an "Advanced, Highly Experimental"
feature? Otherwise, just use the default hash algo.

Like I said, adding the ability to use multiple hashes started out
during development as a proof that my algorihtm can work with any hash.

Does that sound a little bit Kosher? ;^o

[Chris M. Thomasson]

Just to see how my cipher algorihtm works/interacts with different hashes.

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

> On 5/20/2021 12:11 PM, Max wrote:
>> On 20.05.21 20:19, Rich wrote:
>>> But he has previously argued, when pressed with Kerckhoffs's
>>> principle, that he can't seem to wrap his mind around how "not
>>> hiding anything about the algorithm" is actually better.  In those
>>> arguments he's usually fallen back to "but... but... but..., if
>>> Eve does not know which hash Alice and Bob used, then Eve has more
>>> effort to first figure that out".
>>
>> That's a pity, but I am confident, he'll get there eventually. It's
>> not that obscure.
>

> Turns out that my algorihtm works with all of the hashes in SHA2!

Your algorithm would work with any "function" that takes an input value
and then returns a deterministic output value. It would 'work' with
this function:

function unity(input) {
return input
}

It would not be terribly secure, but it would 'work' (as in iterate
and produce an output).

> Like I said, adding the ability to use multiple hashes started out
> during development as a proof that my algorihtm can work with any
> hash.
>
> Does that sound a little bit Kosher? ;^o

Allowing use of multiple hashes is fine.

Allowing the users to select which hash they want to use is also fine.

Making the selection of which hash is used be part of the secret key is
where you run smack into Kerckhoffs's principle.

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

You can do that without *also* making the choice be part of the
"secret".

You run into Kerckhoffs's principle when you say: "This algorithm

[Chris M. Thomasson]

Well, I can easily move it out of the secret key, and create a new
section on the page called, Hash Selection, or something. Then I can say
the ability to choose different hash algorithms is not under the secret
key header? Is that fair enough?

Well, now that I think about it, if I did that, I would be "forced" to
send the hash algo name the user/Alice chooses along in the ciphertext?
Or else, how would Bob decrypt it unless the chosen hash algo was
communicated in the ciphertext?

The way I have it now, Alice and Bob both know the hash because it is
part of the secret key...

[Chris M. Thomasson]

On 5/20/2021 1:50 PM, Rich wrote:

Well, the algorithm is choosing between well known hashes. No secret
hash... Does that make any sense at all? ;^o

[wizzofozz]

Op 20-5-2021 om 22:50 schreef Rich:

>
> You run into Kerckhoffs's principle when you say: "This algorithm
> choice is part of the secret key."
>

I don't agree with this. It's in his specs that some bits of the key
select a specific hash algorithm. You would also know which value of
which keybit selects which hashfunction. So everyone knows exactly
what's happening. For me, it's the same as selecting a specific (known)
substitution table based on some keybits. Basically what Max said; you
get (as it's now in its current state) just an extra keybit.

If he were to create his own hashfunction to be used internally, not
telling you what it was, then you would encounter Kerckhoffs's
principle, IMO.

Ozz

[Max]

Absolutely kosher, halal and A-OK. ;-) As the secrecy of your system
seems to depend on HMAC, not the hash-algorithm (in the first place),
it's interesting to test and analyze it with different hashes. Yet,
imho, it's your job as the designer to find out, which hash serves one
best wrt speed, secrecy, side-channel security, yada yada. No user and
no one trying to implement your algorithm into a product can and/or
wants to decide which hash is most useful to them. So I think, in the
end you might want to decide, which hash is "your" standard for your
scheme (at least for the time).

Then again, making the algorithm part of the secret key comes with some
baggage
- Every implementation of your algorithm has to support all possible
hash functions, making the implementations bulky and harder to maintain.
- All those hash functions have to be secured, kept up to date, etc.
- The hash functions may have different advantages or disadvantages when
implemented in hardware, software, IOT-devices, etc. So, if they are not
equivalent to one another but their choice is "randomly" based on a part
of the key, the result will be sub-optimal
- There might be differences regarding the security of your cipher when
used with different hash functions. To analyze an implementation, one
would have to analyze it for every single hash function used, not just one.

And all you get in return is (at best) 4 bits of extra security (if you
use 16 hash functions).

The Kerckhoff argument is also important, but for another reason: It
helps you to tell apart crypto and snake-oil and to focus your resources
on making the crypto better, not just flashier.

[Chris M. Thomasson]

On 5/20/2021 2:33 PM, wizzofozz wrote:
> Op 20-5-2021 om 22:50 schreef Rich:
>>
>> You run into Kerckhoffs's principle when you say: "This algorithm
>> choice is part of the secret key."
>>
>
> I don't agree with this. It's in his specs that some bits of the key
> select a specific hash algorithm. You would also know which value of
> which keybit selects which hashfunction. So everyone knows exactly
> what's happening. For me, it's the same as selecting a specific (known)
> substitution table based on some keybits. Basically what Max said; you
> get (as it's now in its current state) just an extra keybit.

Agreed. I figure, as long as all the hash choices are public, and the
site is client side only, then everything is there for all to see.

> If he were to create his own hashfunction to be used internally, not
> telling you what it was, then you would encounter Kerckhoffs's
> principle, IMO.

Agreed again. :^D

[Chris M. Thomasson]

Humm... I am thinking about adding a "feature" that allows a ciphertext
to be contained within a URL. So, a user would just click on the
ciphertext; the site would come up; the ciphertext would be inserted
into the Ciphertext textbox, and decrypted using the default key.

Perhaps creating a new button that generates a URL with the ciphertext
contained within it. The URL would not contain any secret key material.
If Alice created a URL with a payload that did not use the default key,
then Bob would have to know the secret key in order to properly decrypt it.

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

> On 5/20/2021 2:33 PM, wizzofozz wrote:
>> Op 20-5-2021 om 22:50 schreef Rich:
>>>
>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>> choice is part of the secret key."
>>>
>>
>> I don't agree with this. It's in his specs that some bits of the
>> key select a specific hash algorithm. You would also know which
>> value of which keybit selects which hashfunction. So everyone knows
>> exactly what's happening. For me, it's the same as selecting a
>> specific (known) substitution table based on some keybits.
>> Basically what Max said; you get (as it's now in its current state)
>> just an extra keybit.
>
> Agreed. I figure, as long as all the hash choices are public, and
> the site is client side only, then everything is there for all to
> see.

But, lets look at two senarios.

Scenario one: Your algorithm using HMAC is secure, as long as the HMAC
you utilize is secure. In this situation, your algorithm is secure as
long as the HMAC is also secure, and you don't need to 'hide' the
selection of which HMAC was used in the secret key. It is already
secure without doing so, therefore no need to try to obfuscate more.

Scenario two: Your algorithm contains some flaw that makes it insecure,
no matter how secure the HMAC used happens to be. In this scenario,
your algorithm is insecure, and hiding which HMAC was used in the
secret key does nothing to change the fact that the algorithm is
insecure.

[Chris M. Thomasson]

I got a feature request over on FB in a private message where somebody
asked me to include a HMAC verification that allows the user to be
alerted if a ciphertext was altered. I can do this for sure, but, iirc,
I should use a different key for the HMAC verification.

[Chris M. Thomasson]

On 5/21/2021 2:25 PM, Rich wrote:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> On 5/20/2021 2:33 PM, wizzofozz wrote:
>>> Op 20-5-2021 om 22:50 schreef Rich:
>>>>
>>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>>> choice is part of the secret key."
>>>>
>>>
>>> I don't agree with this. It's in his specs that some bits of the
>>> key select a specific hash algorithm. You would also know which
>>> value of which keybit selects which hashfunction. So everyone knows
>>> exactly what's happening. For me, it's the same as selecting a
>>> specific (known) substitution table based on some keybits.
>>> Basically what Max said; you get (as it's now in its current state)
>>> just an extra keybit.
>>
>> Agreed. I figure, as long as all the hash choices are public, and
>> the site is client side only, then everything is there for all to
>> see.
>
> But, lets look at two senarios.
>
> Scenario one: Your algorithm using HMAC is secure, as long as the HMAC
> you utilize is secure. In this situation, your algorithm is secure as
> long as the HMAC is also secure, and you don't need to 'hide' the
> selection of which HMAC was used in the secret key. It is already
> secure without doing so, therefore no need to try to obfuscate more.

So far, I seem to be hovering around Scenario one, but I still want to
be able to give the ability to choose other hashes.

> Scenario two: Your algorithm contains some flaw that makes it insecure,
> no matter how secure the HMAC used happens to be. In this scenario,
> your algorithm is insecure, and hiding which HMAC was used in the
> secret key does nothing to change the fact that the algorithm is
> insecure.

So far, over the years, I have been told my cipher is basically as
strong as the underlying HMAC. It makes sense to me. Running some
diehard tests a while back showed basically identical results as the
underlying HMAC and hash when encrypting shitloads of zeros.

[Chris M. Thomasson]

Using HMAC with other hashes is definitely interesting to me.

> Yet,
> imho, it's your job as the designer to find out, which hash serves one
> best wrt speed, secrecy, side-channel security, yada yada. No user and
> no one trying to implement your algorithm into a product can and/or
> wants to decide which hash is most useful to them. So I think, in the
> end you might want to decide, which hash is "your" standard for your
> scheme (at least for the time).

This is the difficult part! So far, my security is derived from the
underlying HMAC and hashes. So, one reason why I keep mentioning SHA-384
is because it might be "better" than SHA-512, even though it has less
bits. I remember reading about SHA-512 being vulnerable to length
extension attack. Something akin to:

https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks

> Then again, making the algorithm part of the secret key comes with some
> baggage
> - Every implementation of your algorithm has to support all possible
> hash functions, making the implementations bulky and harder to maintain.
> - All those hash functions have to be secured, kept up to date, etc.
> - The hash functions may have different advantages or disadvantages when
> implemented in hardware, software, IOT-devices, etc. So, if they are not
> equivalent to one another but their choice is "randomly" based on a part
> of the key, the result will be sub-optimal
> - There might be differences regarding the security of your cipher when
> used with different hash functions. To analyze an implementation, one
> would have to analyze it for every single hash function used, not just one.
>
> And all you get in return is (at best) 4 bits of extra security (if you
> use 16 hash functions).
>
> The Kerckhoff argument is also important, but for another reason: It
> helps you to tell apart crypto and snake-oil and to focus your resources
> on making the crypto better, not just flashier.
>

Humm.... Okay. I need to think about this some more. Humm... Well, can
allowing people to experiment with different hashes help me make my
crypto better? At least I am not hiding anything as everything is client
side, and the code is there for all to see. That has to count for
something... ;^o

[Rich]

But, also, do keep in mind that your algorithm has not yet been (to
your knowledge) attacked by truly great codebreakers (i.e. NSA level
ones). You are hovering around the "Anyone, from the most clueless
amateur to the best cryptographer, can create an algorithm that he
himself can't break. It's not even hard." from Bruce Schneier's blog
here:
https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

And you have this problem from that article:

"The real world isn't that tidy. Cryptographers look at algorithms
that are either interesting or are likely to yield publishable
results. This means that they are going to look at algorithms by
respected cryptographers, algorithms fielded in large public
systems (e.g., cellular phones, pay-TV decoders, Microsoft
products), and algorithms that are published in the academic
literature. Algorithms posted to Internet newsgroups by unknowns
won't get a second glance."

Reading the remainder of the blog entry would be educational for you as
well.

My point is, you fall into the "random unknown posting on internet
newsgroups" arena as far as the best code breakers attention goes. So
99.999% likely your algorithm, as secure as you /think/ it is, and as
secure as you've been /told/ it is, has not likely ever caught the
attention of the really good code breakers. And so it is likely
sitting in a grey area. It is too difficult for most of those left
posting here in sci.crypt to break, but that says nothing about what a
true pro. might be able to do to the algorithm.

[wizzofozz]

Op 21-5-2021 om 23:25 schreef Rich:

OK, I see your point, but to me this seems to be addressing the question
whether it is wise to 'parametrize' the hashtype in the first place.

As a user I sometimes find it very annoying when I'm presented with
choices to which I cannot immediately foresee the consequences, don't
understand what I'm being asked, or don't understand if/why it matters.

I can imagine that if someone uses Chris's cipher, that they don't feel
comfortable choosing the hash algorithm (so there should be some sane
default). If it cannot be made clear how/why to choose one over the
other, I agree with just sticking with one choice. But 'for fun' or
'educational value' etc, are also valid reasons (but should be
documented as such).
Also, users don't typically decide on keybits, so this could mean that
the used algorithm would be decided by change. That does not feel right,
since there probably is a best choice for a given situation/usecase
(EDIT; I just see that Max already used this argument, so agree with him).

I just read Max's excellent answer a couple of posts ago, about why NOT
include it as part of the key. I totally agree with those arguments,
especially the one that every implementation would need to support all
hashtypes (I still don't agree with the Kerckhoffs argument since
nothing is hidden in the implementation ;-)).

Ozz

[Max]

On 22.05.21 03:22, Chris M. Thomasson wrote:

> So, one reason why I keep mentioning SHA-384
> is because it might be "better" than SHA-512, even though it has less
> bits. I remember reading about SHA-512 being vulnerable to length
> extension attack. Something akin to:
>
> https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks

Ah, now I get it. I don't see how this would affect your cipher though.
First, you don't use the hash to verify the integrity of anything and
second, you're already using HMAC which in itself defies length
extension attacks. As SHA-384 is simply a truncated version of SHA512,
you just make your cipher 25% slower, by throwing away 128 perfectly
fine bits in each block.

[Chris M. Thomasson]

Excellent points. I noticed that David Oranchak has posted here wrt
breaking the Zodiac cipher. He knows people in the places that I need to
present my work to. The FBI, ect... Wondering if I posted a new thread
here with attention to him... Well, I wonder if he just might find the
spare time to forward my cipher to the higher ups, so to speak...

https://youtu.be/CX0XP3d0q2Q

How do I get my cipher out there?

[Chris M. Thomasson]

On 5/22/2021 2:42 PM, Chris M. Thomasson wrote:
> On 5/21/2021 9:13 PM, Rich wrote:
>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>> On 5/21/2021 2:25 PM, Rich wrote:
>>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>>> On 5/20/2021 2:33 PM, wizzofozz wrote:
>>>>>> Op 20-5-2021 om 22:50 schreef Rich:
>>>>>>>
>>>>>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>>>>>> choice is part of the secret key."

[...]

>> My point is, you fall into the "random unknown posting on internet
>> newsgroups" arena as far as the best code breakers attention goes.  So
>> 99.999% likely your algorithm, as secure as you /think/ it is, and as
>> secure as you've been /told/ it is, has not likely ever caught the
>> attention of the really good code breakers.  And so it is likely
>> sitting in a grey area.  It is too difficult for most of those left
>> posting here in sci.crypt to break, but that says nothing about what a
>> true pro.  might be able to do to the algorithm.
>>
>
> Excellent points. I noticed that David Oranchak has posted here wrt
> breaking the Zodiac cipher. He knows people in the places that I need to
> present my work to. The FBI, ect... Wondering if I posted a new thread
> here with attention to him... Well, I wonder if he just might find the
> spare time to forward my cipher to the higher ups, so to speak...
>
> https://youtu.be/CX0XP3d0q2Q
>
> How do I get my cipher out there?

I made a friend request to David over on the FaceBook.

[Chris M. Thomasson]

I get that loud and clear. Is it "wise"? Humm...

> As a user I sometimes find it very annoying when I'm presented with
> choices to which I cannot immediately foresee the consequences, don't
> understand what I'm being asked, or don't understand if/why it matters.

This is why I want to finally "default" to a good hashfunction
selection, so users don't really have to care about it so much...

> I can imagine that if someone uses Chris's cipher, that they don't feel
> comfortable choosing the hash algorithm (so there should be some sane
> default). If it cannot be made clear how/why to choose one over the
> other, I agree with just sticking with one choice. But 'for fun' or
> 'educational value' etc, are also valid reasons (but should be
> documented as such).

Right. I still do not know what hash would be the "best". I need some
help here. I can just naively say SHA-512 is the "best" because it has
more bits than SHA-256. But, is that totally true? Perhaps, but I just
cannot say such things for sure...

> Also, users don't typically decide on keybits, so this could mean that
> the used algorithm would be decided by change.

Did you mean my "chance" instead of "change"?

> That does not feel right,
> since there probably is a best choice for a given situation/usecase
> (EDIT; I just see that Max already used this argument, so agree with him).

Indeed!

> I just read Max's excellent answer a couple of posts ago, about why NOT
> include it as part of the key. I totally agree with those arguments,
> especially the one that every implementation would need to support all
> hashtypes (I still don't agree with the Kerckhoffs argument since
> nothing is hidden in the implementation ;-)).

So far, on my end, supporting the hashes would be all on me during this
experimental phase. If a "best" hash can be determined through thorough
experimentation, then that would be the default in a so-called "final"
version.

Humm...

[Chris M. Thomasson]

On 5/22/2021 3:35 AM, Max wrote:
> On 22.05.21 03:22, Chris M. Thomasson wrote:
>
>>  So, one reason why I keep mentioning SHA-384 is because it might be
>> "better" than SHA-512, even though it has less bits. I remember
>> reading about SHA-512 being vulnerable to length extension attack.
>> Something akin to:
>>
>> https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
>
>
> Ah, now I get it. I don't see how this would affect your cipher though.

It creates different ciphertexts. For instance, a ciphertext encrypted
with sha-512 cannot be decrypted with sha-256, and vise versa. So, as an
experiment it should be fairly beneficial to deeply examine these
differences.

> First, you don't use the hash to verify the integrity of anything and
> second, you're already using HMAC which in itself defies length
> extension attacks.

Yes! Okay. Good point. Fwiw, I did get a request to HMAC the ciphertext
to allow Bob to know if it has been mutated before decryption even
begins. Iirc, this should use a separate key than the HMAC used for
encryption/decryption...

> As SHA-384 is simply a truncated version of SHA512,
> you just make your cipher 25% slower, by throwing away 128 perfectly
> fine bits in each block.

True. I still do not know what hash would be the "best": need some help
here. I can just _naively_ say SHA-512 is the "best" because it has more

bits than SHA-256. But, is that totally true? Perhaps, but I just cannot
say such things for sure...

Humm...

[Chris M. Thomasson]

On 5/20/2021 2:33 PM, wizzofozz wrote:

> Op 20-5-2021 om 22:50 schreef Rich:
>>
>> You run into Kerckhoffs's principle when you say: "This algorithm
>> choice is part of the secret key."
>>
>
> I don't agree with this. It's in his specs that some bits of the key
> select a specific hash algorithm.

I also mention in my specs:

http://funwithfractals.atspace.cc/ct_cipher

That a TRNG must be used to generate the random numbers. My online code
in JavaScript uses Math.random(). So, this is in effect breaking my
specs. Humm... I wonder if that can be exploited?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random

[Chris M. Thomasson]

On 5/22/2021 3:38 PM, Chris M. Thomasson wrote:
> On 5/20/2021 2:33 PM, wizzofozz wrote:
>> Op 20-5-2021 om 22:50 schreef Rich:
>>>
>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>> choice is part of the secret key."
>>>
>>
>> I don't agree with this. It's in his specs that some bits of the key
>> select a specific hash algorithm.
>
> I also mention in my specs:
>
> http://funwithfractals.atspace.cc/ct_cipher
>
> That a TRNG must be used to generate the random numbers. My online code
> in JavaScript uses Math.random(). So, this is in effect breaking my
> specs. Humm... I wonder if that can be exploited?
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/random

Ahhh! I should be generating these random bytes using Web Crypto:

https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues

[Chris M. Thomasson]

On 5/22/2021 3:35 AM, Max wrote:

Speaking of slower, the online HMAC lib I am using does not keep its
internal state active for an update function. So, I had to create a
little shim function that keeps appending HMAC data in order to get the
same hashes in my test vectors I make in C and Python 3:

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

C: https://pastebin.com/raw/feUnA3kP
Python 3: https://pastebin.com/raw/NAnsBJAZ

They allow their HMAC state to be preserved, and run MUCH faster!


This shim I made for my online version is:

// My Ciphers required HMAC Support
// Quick and Dirty! ;^o
// consistent API, digest and update
//___________________________________________________
function ct_hmac(key, hash) {
this.m_key = key;
this.m_data = "";
this.m_hash = hash;
this.m_hash.setUTF8(false);
}

ct_hmac.prototype.clear = function (data) {
this.m_data = "";
};

ct_hmac.prototype.update = function (data) {
this.m_data += data;
};

ct_hmac.prototype.digest = function () {
return this.m_hash.hex_hmac(this.m_key, this.m_data);
};


It works, but can be very slow. The update is appending data for the
HMAC to use in the digest function. It works because I can reap test
vector hashes that occur in my C and Python 3 code.

I forgot if your HMAC lib can do this:

https://pastebin.com/raw/sMZhpf6x

[Max]

You could just adjust the function fHmacSha2_512_1(key1, message1) to
your needs or add your special calling function to the code. It should
be pretty straight forward. If you run into any problems, just ask.

But if I were you, I wouldn't bother. Our coding styles are very
different. I just wrote some functions that I copy into my code when
needed. Your object-oriented approach with linked libraries is much
cleaner and much more flexible if you want to use several hash functions
at the same time. So maybe it's just not worth your time digging into my
code for just 1 (at most 3, if you care for my SHA-256 and
SHA3-implementations) hash function. Also, my code is hardly optimized
in any way. You're certainly better off with some library.

Btw, have you thought about using SubtleCrypto.digest() from the Crypto
Web API?
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest

This might make your code even cleaner and faster.

[Rich]

Read this quote from the Bruce Schneier blog post:

Algorithms posted to Internet newsgroups by unknowns won't get a
second glance.

Now, read it a second time, then a third time. Continue reading it,
over and over, until you finally have that "flash" of understanding go
off that indicates you /finally/ understand the true meaning of the
sentence.

Then go read the Bruce Schneier article. It contains some tips for
"how" to get your algorithm to be looked at by these folks. Note, the
way to go about it is a lot of long hard work.

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

> On 5/20/2021 2:33 PM, wizzofozz wrote:
>> Op 20-5-2021 om 22:50 schreef Rich:
>>>
>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>> choice is part of the secret key."
>>>
>>
>> I don't agree with this. It's in his specs that some bits of the key
>> select a specific hash algorithm.
>
> I also mention in my specs:
>
> http://funwithfractals.atspace.cc/ct_cipher
>
> That a TRNG must be used to generate the random numbers. My online
> code in JavaScript uses Math.random(). So, this is in effect
> breaking my specs. Humm... I wonder if that can be exploited?

Many an algorithm has been exploited in the past due to weaknesses in
the random number generator algorithm. And math.random in standard
javascript is unlikely to be anywhere near crypto strength.

[Chris M. Thomasson]

Exactly. It would be really fun to try to really exploit Math.random()
to see how it can be used to break my cipher! Then again, can we even
totally "trust":

https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues

I mean, where is its algorihtm published? Is it "secret"? GRRRRR!!!!

[Chris M. Thomasson]

Yeah..... Damn. The hard part has begun. Here are some of my thoughts:


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

[Max]

1, You better use crypto.getRandomValues then

2. Yes, the algorithm(s) are published. Math.random is implementation
specific. This might point you in the right direction:

https://coderwhodreams.com/blog/understanding-the-randomness-behind-math-random-function/

[Chris M. Thomasson]

On 5/22/2021 7:58 PM, Rich wrote:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> On 5/21/2021 9:13 PM, Rich wrote:
>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>> On 5/21/2021 2:25 PM, Rich wrote:
>>>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>>>> On 5/20/2021 2:33 PM, wizzofozz wrote:
>>>>>>> Op 20-5-2021 om 22:50 schreef Rich:

[...]

> Read this quote from the Bruce Schneier blog post:
>
> Algorithms posted to Internet newsgroups by unknowns won't get a
> second glance.
>
> Now, read it a second time, then a third time. Continue reading it,
> over and over, until you finally have that "flash" of understanding go
> off that indicates you /finally/ understand the true meaning of the
> sentence.
>
> Then go read the Bruce Schneier article. It contains some tips for
> "how" to get your algorithm to be looked at by these folks. Note, the
> way to go about it is a lot of long hard work.
>

I am not sure exactly where to Publish the cipher.

[Rich]

Did you read the article.

It tells you exactly how to get it reviewed.

[Chris M. Thomasson]

Yes. Memo to the Amateur Cipher Designer.

>
> It tells you exactly how to get it reviewed.
>

Oh damn. I am totally missing it. I suppose an email to:

schn...@schneier.com

would be dumped in the junk folder?

[Rich]

Seems so. Try reading it again. The key part of how to get
recognition is these portions:

"Unknowns can become knowns by publishing cryptanalyses of existing
ciphers; most conferences accept these papers."

...

"If you want to design algorithms, start by breaking the ones out
there. Practice by breaking algorithms that have already been
broken (without peeking at the answers). Break something no one
else has broken. Break another. Get your breaks published. When
you have established yourself as someone who can break algorithms,
then you can start designing new algorithms. Before then, no one
will take you seriously."

> schn...@schneier.com
>
> would be dumped in the junk folder?

Most likely -- until after you follow the steps he outlines in the blog
post.

[Chris M. Thomasson]

I read that. So far, my little "paper" is nowhere near ready:

http://funwithfractals.atspace.cc/ct_cipher

> ...
>
> "If you want to design algorithms, start by breaking the ones out
> there. Practice by breaking algorithms that have already been
> broken (without peeking at the answers). Break something no one
> else has broken. Break another. Get your breaks published. When
> you have established yourself as someone who can break algorithms,
> then you can start designing new algorithms. Before then, no one
> will take you seriously."
>
>> schn...@schneier.com
>>
>> would be dumped in the junk folder?
>
> Most likely -- until after you follow the steps he outlines in the blog
> post.

That is a skill that I am lacking in. I am wondering about how to
exploit using Math.random() in JavaScript to try bust my HMAC cipher.

A long hard road indeed! ;^o

[Chris M. Thomasson]

On 5/22/2021 11:28 PM, Max wrote:
> On 23.05.21 06:26, Chris M. Thomasson wrote:
>> On 5/22/2021 8:00 PM, Rich wrote:
>>> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>>>> On 5/20/2021 2:33 PM, wizzofozz wrote:
>>>>> Op 20-5-2021 om 22:50 schreef Rich:
>>>>>>
>>>>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>>>>> choice is part of the secret key."
>>>>>>
>>>>>
>>>>> I don't agree with this. It's in his specs that some bits of the key
>>>>> select a specific hash algorithm.
>>>>
>>>> I also mention in my specs:
>>>>
>>>> http://funwithfractals.atspace.cc/ct_cipher
>>>>
>>>> That a TRNG must be used to generate the random numbers.  My online
>>>> code in JavaScript uses Math.random().  So, this is in effect
>>>> breaking my specs.  Humm...  I wonder if that can be exploited?
>>>
>>> Many an algorithm has been exploited in the past due to weaknesses in
>>> the random number generator algorithm.  And math.random in standard
>>> javascript is unlikely to be anywhere near crypto strength.
>>>
>>
>> Exactly. It would be really fun to try to really exploit Math.random()
>> to see how it can be used to break my cipher! Then again, can we even
>> totally "trust":
>>
>> https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues
>>
>> I mean, where is its algorihtm published? Is it "secret"? GRRRRR!!!!
>
> 1, You better use crypto.getRandomValues then

Okay. I will include that in version 0.0.0.2. I have never used
webcrypto before:

https://www.w3.org/TR/WebCryptoAPI

> 2. Yes, the algorithm(s) are published. Math.random is implementation
> specific. This might point you in the right direction:
>
> https://coderwhodreams.com/blog/understanding-the-randomness-behind-math-random-function/
>

Thank you Max. :^)

[Chris M. Thomasson]

I did break a cipher posted over on sci.math. I need to find the damn post.

https://groups.google.com/g/sci.math/c/l3rXvU7yHHY/m/BW38LRf-AQAJ

[Chris M. Thomasson]

Here is where the creator of the cipher told me that I got it:

https://groups.google.com/g/sci.math/c/l3rXvU7yHHY/m/UmdZhucBAgAJ

Iirc, he was using convergents on continued fractions to encrypt/decrypt.

[Chris M. Thomasson]

On 5/23/2021 6:08 PM, Rich wrote:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> On 5/23/2021 3:28 PM, Rich wrote:

[...]

> "If you want to design algorithms, start by breaking the ones out
> there.

[...]

https://groups.google.com/g/sci.crypt/c/3zYsIKPu710/m/sZWsS8XHBAAJ

[Rich]

Except that paper is not a cryptanalyses -- it is at best documenting
the operation of the hmac cipher, using non-standard terms (note one of
the requirements in the blog post was to use the industry standard
terms and labels).

> That is a skill that I am lacking in. I am wondering about how to
> exploit using Math.random() in JavaScript to try bust my HMAC cipher.

Why not start by determining if it is possible to exploit
Math.random()?

I.e., start small, then build up.

Hint: if Math.random() is your typical programming language random
generator, it is possible to exploit it, because it was never intended
to be 'secure'.

> A long hard road indeed! ;^o

Yup.

[Chris M. Thomasson]

Yup. I need to study up on the standard terms Rich. My pseudo-code is
not going to cut it! Yikes!

>> That is a skill that I am lacking in. I am wondering about how to
>> exploit using Math.random() in JavaScript to try bust my HMAC cipher.
>
> Why not start by determining if it is possible to exploit
> Math.random()?
>
> I.e., start small, then build up.

Actually, the only reason why I am prepending the plaintext with these
"random" bytes _before_ encryption is to be able to generate a different
ciphertext for the same plaintext on a per-encryption basis, aka every
time I click the encrypt button. So, starting really small, just might
be to actually eliminate them as a pure experiment: no random numbers at
all. I can do that on my site by setting the number of random bytes to
zero. Here are some examples encrypting the plaintext between the quotes
"Plaintext" using the default key with 64 "random" bytes, three encryptions:

79b0cd27a8fd6d28b115112966cd3defcf89267843ecbd7d26281f12f20b70bd1ae6b9b1427d53aa8e0a6f2aff64d1ed9f5483e1de3e9049f4826bfcfdec1abf32b9a33e97dd403ba9

a854296adb9aeb8fc317257974687daa1e13cccd941d5fce649d3112fd419a65facf6e1a97500124a6ab63de9fca6ebce18006fb3ed6e8c0f33ea689f2caed1b409eb4f4b9ff931f02

f24c5a383ac51a6b90f9cef640ce7981a0f95574c74967450fb5d0415a6fa96818068fa6d063e6f40266da2b5dd383a856f8670abc6278ae67237e6a657bab39c537de913c5c311b5b

Okay, the ciphertexts above all encrypt "Plaintext" using the default
key, and they are all different. Okay.... Let me set the number of
random bytes to zero. Here is the ciphertext:

b90427406e5d23109d

I can encrypt "Plaintext" a thousand times in a row now, and it is the
same using no random bytes:

b90427406e5d23109d


Okay.... This is raw. Imvho, wrt starting small, this is as small as I
can get. Let me think on this Rich...

You can decrypt it by going to the site, setting the number of random
bytes to zero, and copy-and-paste the ciphertext b90427406e5d23109d into
the ciphertext box and click decrypt.

Now, this is where the rubber hits the road, imvvvho... Any thoughts
about starting _this_ small? I think removing the damn random bytes just
might be a decent start?

>
> Hint: if Math.random() is your typical programming language random
> generator, it is possible to exploit it, because it was never intended
> to be 'secure'.
>
>> A long hard road indeed! ;^o
>
> Yup.
>

Big time! WOha!

[Rich]

Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> On 5/24/2021 3:38 PM, Rich wrote:
>> Why not start by determining if it is possible to exploit
>> Math.random()?
>>
>> I.e., start small, then build up.
>

> Now, this is where the rubber hits the road, imvvvho... Any thoughts
> about starting _this_ small? I think removing the damn random bytes
> just might be a decent start?

Go read some of the published literature on attacks on the major
algorithims.

What you will find is that a good number of them are against "smaller"
variants.

I.e., if AES normally uses 20 rounds (I just made that value up, as I'm
not bothered to look up the real amount) then you'll find many
published breaks against, say, 3 round AES and then 4 round AES, and
then 6 round AES, etc.

Smaller versions....

So, no, that is not too small.

[Chris M. Thomasson]

NO! I never used it before. I need to read up. Will have some more time
tomorrow.

>
> This might make your code even cleaner and faster.
>

Crossing fingers!

[Chris M. Thomasson]

Well, the first thing that stands out loud and clear when I artificially
break one of my specs, e.g. the number of random bytes shall be at least
as big as a digest, means my cipher does not hold up to my claims unless
the specs are followed. Hummm....

Breaking my specs in this way means that changing a single bit of
ciphertext does _not_ result in radically different plaintext. Check
this out... All using the default key with zero random bytes, clearly
breaking my specs:

Plaintext encrypts to b90427406e5d23109d

So, lets alter the ciphertext, decrypt and see what happens...

b80427406e5d23109d decrypts to Plaintexu

Oh my GOD that is NOT Kosher. Wow. This is open to attack using known
plaintext at least. Now, lets see what happens when I encrypt Plaintext
using 64 "random" bytes:

Plaintext encrypts to
c35efb329bda8b9ea03061ad3b9761be856c9b908384aed667c8b641bfe328150cb24682d07efca8f97e520dfc815bd72421b14ae2cac27cc20298e975317928d7367e835ed4a17bc1


Now, lets alter the ciphertext:

c45efb329bda8b9ea03061ad3b9761be856c9b908384aed667c8b641bfe328150cb24682d07efca8f97e520dfc815bd72421b14ae2cac27cc20298e975317928d7367e835ed4a17bc1
decrypts to 5E'ÈÊ0Ô6S


Okay, that is much better. Lets try again altering the last hexbyte:

c35efb329bda8b9ea03061ad3b9761be856c9b908384aed667c8b641bfe328150cb24682d07efca8f97e520dfc815bd72421b14ae2cac27cc20298e975317928d7367e835ed4a17bc2
decrypts to ¶K„$ã¬0U .

Ahh good. Lets try a byte somewhere in the middle:

c35efb329bda8b9ea03061ad3b9761be856c9b908384aed667c8b641bfe328150cb24682d07efca8f97e520dfc815bd72421b14ae3cac27cc20298e975317928d7367e835ed4a17bc1
decrypts to .`·žJ¥óÍ£


Perfect! Okay, so my cipher is not that great unless my specs are
followed... I need to ponder on this Rich. Humm... I feel like writing a
new program to check this out, and help _automate_ it for me.

[Chris M. Thomasson]

Those random bytes are critical to my cipher, and there must be enough
of them to cover a digest of the chosen hash algorithm.

[char]

On 5/21/21 4:25 PM, Rich wrote:
> Chris M. Thomasson <chris.m.t...@gmail.com> wrote:

>> On 5/20/2021 2:33 PM, wizzofozz wrote:
>>> Op 20-5-2021 om 22:50 schreef Rich:
>>>>

>>>> You run into Kerckhoffs's principle when you say: "This algorithm
>>>> choice is part of the secret key."
>>>>
>>>
>>> I don't agree with this. It's in his specs that some bits of the

>>> key select a specific hash algorithm. You would also know which
>>> value of which keybit selects which hashfunction. So everyone knows
>>> exactly what's happening. For me, it's the same as selecting a
>>> specific (known) substitution table based on some keybits.
>>> Basically what Max said; you get (as it's now in its current state)
>>> just an extra keybit.
>>
>> Agreed. I figure, as long as all the hash choices are public, and
>> the site is client side only, then everything is there for all to
>> see.
>
> But, lets look at two senarios.
>
> Scenario one: Your algorithm using HMAC is secure, as long as the HMAC
> you utilize is secure. In this situation, your algorithm is secure as
> long as the HMAC is also secure, and you don't need to 'hide' the
> selection of which HMAC was used in the secret key. It is already
> secure without doing so, therefore no need to try to obfuscate more.
>

> Scenario two: Your algorithm contains some flaw that makes it insecure,
> no matter how secure the HMAC used happens to be. In this scenario,
> your algorithm is insecure, and hiding which HMAC was used in the
> secret key does nothing to change the fact that the algorithm is
> insecure.
>

Part of security is how much work does the attacker have to do to guess.
The more combinatorial complexity involved, the harder the attack.

I would chain the HMAC through a generator function and use it to
deterministically select different, multiple hash algorithms from a
basket for each block, then exor the results of those digests with the
current block of plaintext. If you're going to over-engineer, you must
dig into combinatorial loading or else you're wasting time and hash power.

~ char

[Chris M. Thomasson]

I need to point out that the plaintext is also being fed into the HMAC.
The first HMAC digest is the place to target wrt my algorihtm. Now, I
need to read more and digest your comment! Thanks.

If Alice and Bob send a shit load of encrypted messages using the same
secret key, and if Eve can gain that key, then she can read them. Well,
if she can get that initial digest, then shit happens! The initial
digest might be from sha-n, where n is a hash of choice. My online
program only has two to choose from for now:

This was encrypted using SHA512:

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

To decrypt, choose the SHA512 radio button, then click on decrypt.