A question about some pseudo-code...

[Chris M. Thomasson]

I am not totally familiar with the common way to describe cipher
algorithms, terminology, ect... So, I am wondering if the following is
completely weird to you. If so, how can I improve it?

A simple piece of pseudo-code that xor's together two buffers, say the
size of n. h is an hmac digest the size of n, and p is a plaintext the
size of n:

h = HMAC(iv, password)

Okay we have an hmac digest h, size of n bytes. c is the resulting
xor'ed buffer, byte by byte:

c = p[0...n] ^ h[0...n]

c = xor the p bytes with the h bytes

Can you make heads or tails out of the line above?

Basically, if n = 3, then:

c[0] = p[0] ^ h[0]
c[1] = p[1] ^ h[1]
c[2] = p[2] ^ h[2]

I might have some more time to work on my hmac cipher again.

[Ben Bacarisse]

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

> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
> completely weird to you. If so, how can I improve it?
>
> A simple piece of pseudo-code that xor's together two buffers, say the
> size of n. h is an hmac digest the size of n, and p is a plaintext the
> size of n:
>
> h = HMAC(iv, password)
>

> Okay...

Sorry, already lost. What is h a digest of? The password? What is n?
Is it some size determined by the algorithm (like a block size) or is it
(as the last phrase suggests) the length of the plaintext?

--
Ben.

[Chris M. Thomasson]

On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
>> completely weird to you. If so, how can I improve it?
>>
>> A simple piece of pseudo-code that xor's together two buffers, say the
>> size of n. h is an hmac digest the size of n, and p is a plaintext the
>> size of n:
>>
>> h = HMAC(iv, password)
>>
>> Okay...
>
> Sorry, already lost. What is h a digest of?

h is a digest of the HMAC using an iv and a password in this example.

> The password?

The password is whatever the user uses as a password. So, say the user
used 259 bytes of TRNG data to create it. So password is [0...258] bytes.

> What is n?

n is the size of the HMAC digest. So, say HMAC is actually HMAC256.
Therefore, n would be the size of its digest, 32 bytes.

> Is it some size determined by the algorithm (like a block size) or is it
> (as the last phrase suggests) the length of the plaintext?

n is the size of the HMAC's digest, I guess we can call that a block. So
if a plaintext is say, 42 bytes, then that will take two digests worth
of HMAC data to cover. Have you taken a look at my pseudo-code in:

http://funwithfractals.atspace.cc/ct_cipher/

yet? The pseudo-code should be fairly easy to read? It shows how I am
using HMAC digests. Fwiw, I am going to try to convert my experimental
HMAC cipher from working on files, to working on a stream of data. Was
going to do it last night, but got caught up working on some fractals
and wav music.

[Ben Bacarisse]

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

> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
>>> completely weird to you. If so, how can I improve it?
>>>
>>> A simple piece of pseudo-code that xor's together two buffers, say the
>>> size of n. h is an hmac digest the size of n, and p is a plaintext the
>>> size of n:
>>>
>>> h = HMAC(iv, password)
>>>
>>> Okay...
>> Sorry, already lost. What is h a digest of?
>
> h is a digest of the HMAC using an iv and a password in this example.

That's less clear.

>> The password?
>
> The password is whatever the user uses as a password.

Yes, I could guess that. I was not asking a series of questions, but
related queries: What is h a digest of -- is it a digest of the
password?

Why do you use the term HMAC since, as far as I can tell, it is not a
Message Authentication Code?

>> What is n?
>
> n is the size of the HMAC digest. So, say HMAC is actually
> HMAC256. Therefore, n would be the size of its digest, 32 bytes.

OK.

>> Is it some size determined by the algorithm (like a block size) or is it
>> (as the last phrase suggests) the length of the plaintext?
>
> n is the size of the HMAC's digest, I guess we can call that a
> block. So if a plaintext is say, 42 bytes, then that will take two
> digests worth of HMAC data to cover.

Right. That "p is a plaintext the size of n" was confusing. The
plaintext is processed in blocks of length n.

> Have you taken a look at my
> pseudo-code in:
>
> http://funwithfractals.atspace.cc/ct_cipher/
>
> yet?

No. Please don't worry about it. I don't mind if I never understand
the algorithm.

--
Ben.

[Chris M. Thomasson]

On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>
>>>> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
>>>> completely weird to you. If so, how can I improve it?
>>>>
>>>> A simple piece of pseudo-code that xor's together two buffers, say the
>>>> size of n. h is an hmac digest the size of n, and p is a plaintext the
>>>> size of n:
>>>>
>>>> h = HMAC(iv, password)
>>>>
>>>> Okay...
>>> Sorry, already lost. What is h a digest of?
>>
>> h is a digest of the HMAC using an iv and a password in this example.
>
> That's less clear.

For some reason h = HMAC(iv, password) is clear to me. Damn.

HMAC creates a digest, so what do you get wrt HMAC256, with say:

h = HMAC("123", "321")?

I get:

h = 8de2d9aef6f2f0df0550f08a16f34077d2d848600643296a4af40215ef1c6048

Do you get that as well? Even my online program generates the same hash
for SHA-256:

https://i.ibb.co/CvXXH4z/image.png

I get it using some online tools as well:

https://i.ibb.co/CPq9Fkn/image.png

8de2d9aef6f2f0df0550f08a16f34077d2d848600643296a4af40215ef1c6048

In case I got it backwards, here is HMAC256("321", "123")

8427c46aef0e0e6262dbd8315264ba035b7b8bc03a254700cb121ce2d2279156

I get the same using my online HMAC cipher using a password of 321:

8427c46aef0e0e6262dbd8315264ba035b7b8bc03a254700cb121ce2d2279156

https://i.ibb.co/Hrqb62z/image.png

>
>>> The password?
>>
>> The password is whatever the user uses as a password.
>
> Yes, I could guess that. I was not asking a series of questions, but
> related queries: What is h a digest of -- is it a digest of the
> password?
>
> Why do you use the term HMAC since, as far as I can tell, it is not a
> Message Authentication Code

I am experimentally using HMAC to create digests as a sort of CSPRNG.
Also, my experimental cipher loads up HMAC with plaintext bytes as well.
Some people have said they think it actually is secure. It achieves a
100% total diffusion where if a single bit of ciphertext is altered it
decrypts into a radically different plaintext, and vise versa.

>
>>> What is n?
>>
>> n is the size of the HMAC digest. So, say HMAC is actually
>> HMAC256. Therefore, n would be the size of its digest, 32 bytes.
>
> OK.
>
>>> Is it some size determined by the algorithm (like a block size) or is it
>>> (as the last phrase suggests) the length of the plaintext?
>>
>> n is the size of the HMAC's digest, I guess we can call that a
>> block. So if a plaintext is say, 42 bytes, then that will take two
>> digests worth of HMAC data to cover.
>
> Right. That "p is a plaintext the size of n" was confusing. The
> plaintext is processed in blocks of length n.
>
>> Have you taken a look at my
>> pseudo-code in:
>>
>> http://funwithfractals.atspace.cc/ct_cipher/
>>
>> yet?
>
> No. Please don't worry about it. I don't mind if I never understand
> the algorithm.
>

:^)

[Ben Bacarisse]

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

> On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>
>>>>> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
>>>>> completely weird to you. If so, how can I improve it?
>>>>>
>>>>> A simple piece of pseudo-code that xor's together two buffers, say the
>>>>> size of n. h is an hmac digest the size of n, and p is a plaintext the
>>>>> size of n:
>>>>>
>>>>> h = HMAC(iv, password)
>>>>>
>>>>> Okay...
>>>>
>>>> Sorry, already lost. What is h a digest of?
>>>
>>> h is a digest of the HMAC using an iv and a password in this example.
>>
>> That's less clear.
>
> For some reason h = HMAC(iv, password) is clear to me. Damn.

I looked at the Python code and I think I understand the algorithm now.

--
Ben.

[Chris M. Thomasson]

Hey now! That's a good start. I a wondering if my pseudo-code was any
help at all, or did it act as a point of confusion?

Okay. When you get some more time to burn on it, have you taken a look
at my C impl? So far, I have implemented it in three languages, C,
Python 3 and JavaScript. And they all work with each other. In other
words a ciphertext created by one of the three languages decrypts with
all of them, and vise versa. One fine point. I needed to alter my Python
3 impl to not encode utf-8 wrt HMAC. Here is a Python version that is
meant as a test vector for my C impl. The following links are to raw
text, via pastebin raw:

Python 3 test vector:
https://pastebin.com/raw/NAnsBJAZ

For my C code at:
https://pastebin.com/raw/feUnA3kP

Here is my JavaScript impl:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/


Here is a link that sends a ciphertext to the client side site to
automatically decrypt using the default secret key:

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

Clicking on the link should look like this:

https://i.ibb.co/H70tgxt/image.png

Have you tried to play around with the online version?

[Ben Bacarisse]

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

> On 9/18/2022 4:54 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>
>>>>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>>
>>>>>>> I am not totally familiar with the common way to describe cipher algorithms, terminology, ect... So, I am wondering if the following is
>>>>>>> completely weird to you. If so, how can I improve it?
>>>>>>>
>>>>>>> A simple piece of pseudo-code that xor's together two buffers, say the
>>>>>>> size of n. h is an hmac digest the size of n, and p is a plaintext the
>>>>>>> size of n:
>>>>>>>
>>>>>>> h = HMAC(iv, password)
>>>>>>>
>>>>>>> Okay...
>>>>>>
>>>>>> Sorry, already lost. What is h a digest of?
>>>>>
>>>>> h is a digest of the HMAC using an iv and a password in this example.
>>>>
>>>> That's less clear.
>>>
>>> For some reason h = HMAC(iv, password) is clear to me. Damn.
>> I looked at the Python code and I think I understand the algorithm now.
>>
>
> Hey now! That's a good start. I a wondering if my pseudo-code was any
> help at all, or did it act as a point of confusion?

I didn't bother with the pseudo-code as I got tripped up by your use of
terms.

> Okay. When you get some more time to burn on it, have you taken a look
> at my C impl? So far, I have implemented it in three languages, C,
> Python 3 and JavaScript.

I may well have time to look, but why would you want me to?

> Have you tried to play around with the online version?

No, nor am I ever likely to. If I wanted to try it out, I'd want
something that read stdin and wrote stdout.

--
Ben.

[Chris M. Thomasson]

On 9/19/2022 7:29 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> On 9/18/2022 4:54 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>> On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:

[...]

>>>> For some reason h = HMAC(iv, password) is clear to me. Damn.
>>> I looked at the Python code and I think I understand the algorithm now.
>>>
>>
>> Hey now! That's a good start. I a wondering if my pseudo-code was any
>> help at all, or did it act as a point of confusion?
>
> I didn't bother with the pseudo-code as I got tripped up by your use of
> terms.
>
>> Okay. When you get some more time to burn on it, have you taken a look
>> at my C impl? So far, I have implemented it in three languages, C,
>> Python 3 and JavaScript.
>
> I may well have time to look, but why would you want me to?

The more smart eyes I can get on it, the better.

>> Have you tried to play around with the online version?
>
> No, nor am I ever likely to. If I wanted to try it out, I'd want
> something that read stdin and wrote stdout.

I think I can do it. My cipher is geared toward files right now.

[Ben Bacarisse]

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

> On 9/19/2022 7:29 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>> On 9/18/2022 4:54 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>> On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
> [...]
>>>>> For some reason h = HMAC(iv, password) is clear to me. Damn.
>>>> I looked at the Python code and I think I understand the algorithm now.
>>>>
>>>
>>> Hey now! That's a good start. I a wondering if my pseudo-code was any
>>> help at all, or did it act as a point of confusion?
>> I didn't bother with the pseudo-code as I got tripped up by your use of
>> terms.
>>
>>> Okay. When you get some more time to burn on it, have you taken a look
>>> at my C impl? So far, I have implemented it in three languages, C,
>>> Python 3 and JavaScript.
>> I may well have time to look, but why would you want me to?
>
> The more smart eyes I can get on it, the better.

Sorry, I realise (on re-reading) that this questions comes over as a bit
aggressive. I mean, rather, what sort of a look are you interested in.
I don't have the skill to make an reasonable cryptographic comments so,
other than a code review, I don't think I could contribute much of any
use.

--
Ben.

[Chris M. Thomasson]

On 9/19/2022 4:25 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 9/19/2022 7:29 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>> On 9/18/2022 4:54 PM, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>> On 9/18/2022 3:13 PM, Ben Bacarisse wrote:
>>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>>>>> On 9/18/2022 8:10 AM, Ben Bacarisse wrote:
>>>>>>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>> [...]
>>>>>> For some reason h = HMAC(iv, password) is clear to me. Damn.
>>>>> I looked at the Python code and I think I understand the algorithm now.
>>>>>
>>>>
>>>> Hey now! That's a good start. I a wondering if my pseudo-code was any
>>>> help at all, or did it act as a point of confusion?
>>> I didn't bother with the pseudo-code as I got tripped up by your use of
>>> terms.
>>>
>>>> Okay. When you get some more time to burn on it, have you taken a look
>>>> at my C impl? So far, I have implemented it in three languages, C,
>>>> Python 3 and JavaScript.
>>> I may well have time to look, but why would you want me to?
>>
>> The more smart eyes I can get on it, the better.
>
> Sorry, I realise (on re-reading) that this questions comes over as a bit
> aggressive.

No problem, Ben. I can take it. :^)

> I mean, rather, what sort of a look are you interested in.

A slaughter fest of a code review would be great. How bad is it? Would
you print out my code just to catch it on fire and watch it burn as you
drink a glass of wine? ;^) Oh, crap there goes that damn wink again.

> I don't have the skill to make an reasonable cryptographic comments so,
> other than a code review, I don't think I could contribute much of any
> use.

I bet you can help in several different ways. Just make sure to use some
really free time, you know, when you really have nothing to do, and are
bored out of your mind, from time to time. Fair enough?

[Ben Bacarisse]

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

> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:

>> I mean, rather, what sort of a look are you interested in.
>
> A slaughter fest of a code review would be great. How bad is it? Would
> you print out my code just to catch it on fire and watch it burn as
> you drink a glass of wine?

Why not post the links to the source here to keep them all on one place
(you have three versions I think)? I spotted one small error in one
version (the JavaScript one I think) but it's not easy for me to find
out where it was.

--
Ben.

[Chris M. Thomasson]

I am going to put them up on GitHub. Fwiw, here is my online JavaScript
version:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/

Main code:

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

Please point out any bug you find. :^)

[Ben Bacarisse]

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

> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:
>>
>>>> I mean, rather, what sort of a look are you interested in.
>>>
>>> A slaughter fest of a code review would be great. How bad is it? Would
>>> you print out my code just to catch it on fire and watch it burn as
>>> you drink a glass of wine?
>> Why not post the links to the source here to keep them all on one place
>> (you have three versions I think)? I spotted one small error in one
>> version (the JavaScript one I think) but it's not easy for me to find
>> out where it was.

> Main code:
>
> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/ct_main.js

I thought you had three versions (this + Python and C++)?

> Please point out any bug you find. :^)

Small bug: Math.floor(Math.random() * 255) will never be 255 so one byte
value is never generated. Since this is for a nonce, it won't affect
how the code works.

Bigger issues:

Separate the algorithm from the GUI. Having an encrypt function that
calls a function named ct_gui_parse_append_element_to_string is just
yucky.

I'd try to avoid all those ct_ prefixes. They don't fully avoid name
clashes and after a while they make the reader's eyes bleed (or they do
mine). Use one of the standard JS tricks to expose only one name. And
if you can rely on a modern browser, you could use JS modules.

--
Ben.

[Chris M. Thomasson]

On 9/26/2022 1:09 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>
>>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:
>>>
>>>>> I mean, rather, what sort of a look are you interested in.
>>>>
>>>> A slaughter fest of a code review would be great. How bad is it? Would
>>>> you print out my code just to catch it on fire and watch it burn as
>>>> you drink a glass of wine?
>>> Why not post the links to the source here to keep them all on one place
>>> (you have three versions I think)? I spotted one small error in one
>>> version (the JavaScript one I think) but it's not easy for me to find
>>> out where it was.
>
>> Main code:
>>
>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/ct_main.js
>
> I thought you had three versions (this + Python and C++)?

I do. Here is the crude C version, I posted a link to it up thread but
is sort of, buried. Sorry for that. I need to get them all up on GitHub
and make a new post. But, there they are over on PasteBin via raw links
that go to text only, no ads and shit like that:

(C version)
https://pastebin.com/raw/feUnA3kP

(A Python test vector for the C code above)
https://pastebin.com/raw/NAnsBJAZ

The Python test vector tests out a very specific plaintext, "Plaintext",
and uses a very specific nonce:

__________________________________
# Generate n random bytes
# These need should ideally be from a truly random, non-repeatable
# source. TRNG!
def ct_rand_bytes(n):
rb = "";
for i in range(n):
#rb = rb + chr(random.randint(0, 255));
# HACK to get the same numbers
rb = rb + chr(i);
return rb;
__________________________________

The "# HACK to get the same numbers" comment is meant to sync up with
the C code when PYTHON_TEST_VECTOR is defined. Here is a comment in my C
code that mentions it:

__________________________________
// Uncomment PYTHON_TEST_VECTOR to sync with the Python 3 test vector
// Python code: https://pastebin.com/raw/NAnsBJAZ
// plaintext 9 bytes at: "Plaintext"
// ciphertext bytes:
//723f811f5eb43df4e0dd50cc2016ff8f14f53137143135f31c99eb0030da44cbc6ace1d9be236858de
__________________________________

The ciphertext bytes are the same between the C and Python test vector
when these very specific rules are followed. Here is the part of the C
code that uses the PYTHON_TEST_VECTOR macro:
__________________________________
// return value ct_buf.p needs to be freed!
struct ct_buf
ct_prepend_from_file(
struct ct_secret_key const* const SK,
const char* fname
) {
FILE* file = fopen(fname, "rb");
assert(file);

size_t file_sz = ct_file_get_size(file) + SK->rand_n;

struct ct_buf buf = { calloc(1, file_sz), file_sz };

if (buf.p)
{
// Prepend the random bytes.
// These should be drawn from a TRNG!!!

srand((unsigned int)time(NULL));

#if defined (PYTHON_TEST_VECTOR)
for (size_t i = 0; i < SK->rand_n; ++i)
{
buf.p[i] = (unsigned char)i;
}
#else
for (size_t i = 0; i < SK->rand_n; ++i)
{
buf.p[i] = rand() % 256;
}
#endif

// Append the original plaintext
for (size_t i = SK->rand_n; i < file_sz; ++i)
{
int byte = fgetc(file);
assert(byte != EOF);
buf.p[i] = byte;
}
}

fclose(file);

return buf;
}
__________________________________

Well, I can see an annoying bugger in here. What was the return value
for fclose? Yikes! However, I admit that the C code is crude, and not
meant for a "bullet-proof" impl. Just a proof of concept. How does
anybody know if ct_prepend_from_file fails! Humm... Okay. I need to fix
these.

>> Please point out any bug you find. :^)
>
> Small bug: Math.floor(Math.random() * 255) will never be 255 so one byte
> value is never generated. Since this is for a nonce, it won't affect
> how the code works.

Ahhh! For some reason I thought that Math.random() could return 1. Damn.
Thanks Ben. I was going for a "random" unsigned integer from [0...255].
Actually, for my algorithm, a TRNG should be used.

> Bigger issues:
>
> Separate the algorithm from the GUI. Having an encrypt function that
> calls a function named ct_gui_parse_append_element_to_string is just
> yucky.

Yeah. Oh shit. I put the cipher logic in functions that are meant for
gui. Okay. Makes total sense to me. Thanks again, Ben. :^)

> I'd try to avoid all those ct_ prefixes. They don't fully avoid name
> clashes and after a while they make the reader's eyes bleed (or they do
> mine). Use one of the standard JS tricks to expose only one name. And
> if you can rely on a modern browser, you could use JS modules.
>

Okay. Basically, a ct namespace instead of ct_ all over the damn place.
Got it.

Excellent advise! Perfect. This is exactly what I am looking for. Some
smart eyes on my work, helping me out. Great.

:^)

[Chris M. Thomasson]

On 9/26/2022 4:00 PM, Chris M. Thomasson wrote:
> On 9/26/2022 1:09 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>
>>>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:

[...]
>>> http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1/ct_main.js
[...]

>>> Please point out any bug you find. :^)
>>
>> Small bug: Math.floor(Math.random() * 255) will never be 255 so one byte
>> value is never generated.  Since this is for a nonce, it won't affect
>> how the code works.
>
> Ahhh! For some reason I thought that Math.random() could return 1. Damn.
> Thanks Ben. I was going for a "random" unsigned integer from [0...255].
> Actually, for my algorithm, a TRNG should be used.
>
>
>> Bigger issues:
>>
>> Separate the algorithm from the GUI.  Having an encrypt function that
>> calls a function named ct_gui_parse_append_element_to_string is just
>> yucky.

[...]

Oh, wait a minute. The function calls
ct_gui_parse_append_element_to_string to update the Digest textbox.
However, I see what you mean. I need to do a better job at separation.

ct_hmac_cipher.prototype.crypt_round

calls:

ct_gui_parse_append_element_to_string("g_ct_html_input_digests",
digest_output);

To update the textbox "g_ct_html_input_digests" so the user can see the
actual HMAC digests that are used. I basically did this for my own use
so I can see the digests.

[Chris M. Thomasson]

On 9/26/2022 1:09 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>
>>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:

[...]

> I'd try to avoid all those ct_ prefixes. They don't fully avoid name
> clashes and after a while they make the reader's eyes bleed (or they do
> mine). Use one of the standard JS tricks to expose only one name. And
> if you can rely on a modern browser, you could use JS modules.
>

Fwiw, here is some old documentation I wrote about an reference counter
pointer with strong thread safety. Gotta love the way back machine:

https://web.archive.org/web/20070820025433/http://appcore.home.comcast.net/vzoom/refcount/doc/

[Chris M. Thomasson]

The ct_gui_* function calls in here definitely need to be separated out.
Luckily, this is a per-alpha version. It sure seems to work:


__________________
function ct_html_on_decrypt_click() {
//alert("ct_html_on_decrypt_click prolog");

var cipher = ct_hmac_cipher_create();

var ciphertext_hex =
ct_gui_parse_string_from_element("g_ct_html_input_ciphertext", "Plaintext");


var ciphertext = ct_hexbytes_to_string(ciphertext_hex, 0);

ct_gui_parse_element_to_string("g_ct_html_input_digests",
"Decrypting " + ciphertext.length + " bytes...\n");

var plaintext_codes = cipher.crypt(ciphertext, true);
var plaintext = ct_codes_to_string(plaintext_codes);

ct_gui_parse_element_to_string("g_ct_html_input_plaintext",
plaintext);

//alert("ct_html_on_decrypt_click epilog");
}
__________________



Fwiw, here is the function posted above "ct_html_on_decrypt_click", oh
ouch that _click postfix reeks of gui... Anyway, encrypted online using
the default key, in a link. The link simply goes to the site and
provides the client only page with a ciphertext to decrypt against the
default secret key. The ciphertext payload is in the URL.

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

[Ben Bacarisse]

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

> On 9/26/2022 1:09 PM, Ben Bacarisse wrote:

>> Separate the algorithm from the GUI. Having an encrypt function that
>> calls a function named ct_gui_parse_append_element_to_string is just
>> yucky.

<cut>

> The ct_gui_* function calls in here definitely need to be separated
> out.

I am glad you agree.

--
Ben.

[Chris M. Thomasson]

On 9/26/2022 1:09 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>
>>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:

[...]

> I'd try to avoid all those ct_ prefixes. They don't fully avoid name
> clashes and after a while they make the reader's eyes bleed (or they do
> mine). Use one of the standard JS tricks to expose only one name. And
> if you can rely on a modern browser, you could use JS modules.
>

Actually, I had a comment about the ct_ prefix in one of my shaders,
over on a private message in FB. Basically, it went like: We know the
code is yours, ct_everywhere. Well, at least I did not make it CT_* ;^)
Uppercase for the prefix. wow. Got a laugh!

The code in question:

https://www.shadertoy.com/view/MdcyRs

[Ben Bacarisse]

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

> On 9/26/2022 1:09 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>
>>> On 9/25/2022 2:02 PM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>>>
>>>>> On 9/19/2022 4:25 PM, Ben Bacarisse wrote:
> [...]
>> I'd try to avoid all those ct_ prefixes. They don't fully avoid name
>> clashes and after a while they make the reader's eyes bleed (or they do
>> mine). Use one of the standard JS tricks to expose only one name. And
>> if you can rely on a modern browser, you could use JS modules.
>
> Actually, I had a comment about the ct_ prefix in one of my shaders,
> over on a private message in FB. Basically, it went like: We know the
> code is yours, ct_everywhere.

I don't know what the point of this remark is. Some random person
approved or some random person disapproved? Or are you just saying
some random person commented? Why?

--
Ben.

[Chris M. Thomasson]

I am saying another smart person agreed with you about the ct_* prefix.
Eyes bleeding and all...