Richard Heathfield wrote:

On 08/03/2025 09:22, Stefan Claas wrote:

Well, the mouse coordinates are not the only entropy source.

Indeed.

Similarly, you can go to the trouble of travelling a hundred miles to
the coast to spit in the ocean to make it deeper.

But if you don't bother, fear not because the ocean has other sources of water.

Well, as another solution ... Have you checked out my latest thread:
Subject: lun - Lucky Number? Maybe this is something for you, or others,
who prefer the command line, without using your mouse. It generates only strings of 20 random digits, but it's entropy should be good enough too.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/03/2025 09:22, Stefan Claas wrote:

Well, the mouse coordinates are not the only entropy source.

Indeed.

Similarly, you can go to the trouble of travelling a hundred
miles to the coast to spit in the ocean to make it deeper.

But if you don't bother, fear not because the ocean has other
sources of water.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/03/2025 10:27, Stefan Claas wrote:

Richard Heathfield wrote:

On 08/03/2025 09:22, Stefan Claas wrote:

Well, the mouse coordinates are not the only entropy source.

Indeed.

Similarly, you can go to the trouble of travelling a hundred miles to
the coast to spit in the ocean to make it deeper.

But if you don't bother, fear not because the ocean has other sources of
water.

Well, as another solution ... Have you checked out my latest thread:

I saw it.

Subject: lun - Lucky Number? Maybe this is something for you, or others,
who prefer the command line, without using your mouse. It generates only strings of 20 random digits, but it's entropy should be good enough too.

I'm curious. Presumably you think that the entropy from
/dev/random is *not* good enough? So in what specific ways are
your bits an improvement?

FYI:

https://codebrowser.dev/glibc/glibc/stdlib/random.c.html

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 08/03/2025 10:27, Stefan Claas wrote:

Richard Heathfield wrote:

On 08/03/2025 09:22, Stefan Claas wrote:

Well, the mouse coordinates are not the only entropy source.

Indeed.

Similarly, you can go to the trouble of travelling a hundred miles to
the coast to spit in the ocean to make it deeper.

But if you don't bother, fear not because the ocean has other sources of water.

Well, as another solution ... Have you checked out my latest thread:

I saw it.

Subject: lun - Lucky Number? Maybe this is something for you, or others, who prefer the command line, without using your mouse. It generates only strings of 20 random digits, but it's entropy should be good enough too.

I'm curious. Presumably you think that the entropy from /dev/random is
*not* good enough? So in what specific ways are your bits an
improvement?

No, not the case, but I like to explore new and other ways.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

Quidquid dixeris, mate.

Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Nulla quis pretium felis.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich wrote:

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

Well, why not as random? I think you can't generate the same mouse
movement twice, right? And how could we call that?

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 08:51, Stefan Claas wrote:

Rich wrote:

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

Well, why not as random? I think you can't generate the same mouse
movement twice, right?

Depends on the mouse, I'm afraid.

And how could we call that?

A good start, but you'll want to mix in some bits from somewhere
else.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 06/03/2025 08:51, Stefan Claas wrote:

Rich wrote:

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

Well, why not as random? I think you can't generate the same mouse
movement twice, right?

Depends on the mouse, I'm afraid.

And how could we call that?

A good start, but you'll want to mix in some bits from somewhere else.

Thanks. Done. You may check out the additional Linux code.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 06/03/2025 13:16, Stefan Claas wrote:

You may check out the additional Linux code.

Well, okay, I did.

I asked for 1 character, which took me maybe 2 or 3 seconds (should be command line args, by the way), and then I got a character back pretty
much immediately, as one would expect.

Then I ran it again, this time asking for 2 characters. For over 3
minutes I jiggled the mouse like crazy, to no avail. In the end I hit
^C.

Here's my output. Note the position of the interrupt at the end of the "Progress" line.

rjh@hero:~/alldata/dev/crypto/stefanclaas/entropy/mouse$ time ./scmouse
Enter desired number of hex bytes (default is 16, max 256): 2
Generate character-based password instead of hex? (1=yes, 0=no): 1
Using 2 bytes for entropy collection

Please move your mouse to collect entropy...
Take your time, each mouse movement is being recorded.
Progress: 50% [##########----------]^C

Entropy collection completed!

Random Password: Za
SHA256: ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

real 3m3.799s
user 0m0.834s
sys 0m2.252s

At 90+ seconds per byte, I can get entropy faster from my 20d16 --- 80
bits per chuck, at as fast a speed as I can type them in.

Why is it so slow?

I have tested it also under Linux (Ubuntu Mate) with my little GPD MicroPC
and it only takes milliseconds, with your example. I must admit I do not
know why it is so slow on your side. Hopefully others can comfirm my result.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 13:16, Stefan Claas wrote:

You may check out the additional Linux code.

Well, okay, I did.

I asked for 1 character, which took me maybe 2 or 3 seconds
(should be command line args, by the way), and then I got a
character back pretty much immediately, as one would expect.

Then I ran it again, this time asking for 2 characters. For over
3 minutes I jiggled the mouse like crazy, to no avail. In the end
I hit ^C.

Here's my output. Note the position of the interrupt at the end
of the "Progress" line.

rjh@hero:~/alldata/dev/crypto/stefanclaas/entropy/mouse$ time
./scmouse
Enter desired number of hex bytes (default is 16, max 256): 2
Generate character-based password instead of hex? (1=yes, 0=no): 1
Using 2 bytes for entropy collection

Please move your mouse to collect entropy...
Take your time, each mouse movement is being recorded.
Progress: 50% [##########----------]^C

Entropy collection completed!

Random Password: Za
SHA256:
ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

real 3m3.799s
user 0m0.834s
sys 0m2.252s


At 90+ seconds per byte, I can get entropy faster from my 20d16
--- 80 bits per chuck, at as fast a speed as I can type them in.

Why is it so slow?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Logen in sci.crypt:

Richard Heathfield in sci.crypt:

On 06/03/2025 13:16, Stefan Claas wrote:

Random Password: Za
SHA256: ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

| user15@o15:/tmp$ printf '%s' 'Za' | sha256sum
| 31b18bdf7a9ca945b76bacb2636b786af81cdc6fb226f9e6e804593e153eeddc -

| user15@o15:/tmp$ printf '%s\n' 'Za' | sha256sum
| a8d13f1b8e53d68ce35f119317881ed3b7ebf2569f1d50a909a455d072087bee -

| user15@o15:/tmp$ printf '%s\r\n' 'Za' | sha256sum
| cef67327fe1665c5d52b96977353607cfffd53ce5a6901a933f179926f75b59c -

Meanwhile, I have looked into the code (Linux version).
Ah, there is a function "bytes_to_chars" between.

Marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield in sci.crypt:

On 06/03/2025 13:16, Stefan Claas wrote:

[...]

Entropy collection completed!

Random Password: Za
SHA256: ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

| user15@o15:/tmp$ printf '%s' 'Za' | sha256sum
| 31b18bdf7a9ca945b76bacb2636b786af81cdc6fb226f9e6e804593e153eeddc -

| user15@o15:/tmp$ printf '%s\n' 'Za' | sha256sum
| a8d13f1b8e53d68ce35f119317881ed3b7ebf2569f1d50a909a455d072087bee -

| user15@o15:/tmp$ printf '%s\r\n' 'Za' | sha256sum
| cef67327fe1665c5d52b96977353607cfffd53ce5a6901a933f179926f75b59c -

(?)

Marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Logen wrote:

Richard Heathfield in sci.crypt:

On 06/03/2025 13:16, Stefan Claas wrote:

[...]

Entropy collection completed!

Random Password: Za
SHA256: ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

| user15@o15:/tmp$ printf '%s' 'Za' | sha256sum
| 31b18bdf7a9ca945b76bacb2636b786af81cdc6fb226f9e6e804593e153eeddc -

| user15@o15:/tmp$ printf '%s\n' 'Za' | sha256sum
| a8d13f1b8e53d68ce35f119317881ed3b7ebf2569f1d50a909a455d072087bee -

| user15@o15:/tmp$ printf '%s\r\n' 'Za' | sha256sum
| cef67327fe1665c5d52b96977353607cfffd53ce5a6901a933f179926f75b59c -

(?)

The SHA256 hash is from the collected entropy and not the displayed password.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 14:25, Marcel Logen wrote:

Richard Heathfield in sci.crypt:

On 06/03/2025 13:16, Stefan Claas wrote:

[...]

Entropy collection completed!

Random Password: Za
SHA256: ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

| user15@o15:/tmp$ printf '%s' 'Za' | sha256sum
| 31b18bdf7a9ca945b76bacb2636b786af81cdc6fb226f9e6e804593e153eeddc -

| user15@o15:/tmp$ printf '%s\n' 'Za' | sha256sum
| a8d13f1b8e53d68ce35f119317881ed3b7ebf2569f1d50a909a455d072087bee -

| user15@o15:/tmp$ printf '%s\r\n' 'Za' | sha256sum
| cef67327fe1665c5d52b96977353607cfffd53ce5a6901a933f179926f75b59c -

(?)

I wouldn't read too much into that; the program was interrupted,
after all, so there's no reason to assume that it didn't catch
the interrupt while in the process of moving from one consistent
state to another.

It would be nice to let it run to completion, but of course
there's a limit on how long I'm prepared to wait for nothing to
happen.


--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield in sci.crypt:

[...]

I wouldn't read too much into that; the program was interrupted,

ACK

after all, so there's no reason to assume that it didn't catch
the interrupt while in the process of moving from one consistent
state to another.

OK, that is an argument.

Marcel
--
Thu Mar 6 16:06:33 2025 CET (1741273593)
pc-731
87 ikom 19rx
Lines: 20

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 14:11, Stefan Claas wrote:

I have tested it also under Linux (Ubuntu Mate) with my little GPD MicroPC and it only takes milliseconds, with your example. I must admit I do not
know why it is so slow on your side.

I hacked out the usleep() call (and I can't believe a 10ms delay
is your problem!), and this time it came back:

Entropy collection completed!

Random Password: G~
SHA256:
6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988

real 0m16.387s
user 0m1.448s
sys 0m6.113s


8 seconds per byte. Hmm. Clearly something is afoot.

I'm also having the same issues as Marcel after a COMPLETED run.

I see that you are using a 32-byte array, so I hashed G~, G~\0, and:

47 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

and none of them came to 6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988

Sorry.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 15:06, Marcel Logen wrote:

Richard Heathfield in sci.crypt:

[...]

I wouldn't read too much into that; the program was interrupted,

ACK

after all, so there's no reason to assume that it didn't catch
the interrupt while in the process of moving from one consistent
state to another.

OK, that is an argument.

And we now have a better one straight from the OP, which is that
it ain't a SHA of that, but of internal state.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield in sci.crypt:

[...]

I'm also having the same issues as Marcel after a COMPLETED run.

I see that you are using a 32-byte array, so I hashed G~, G~\0, and:

47 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

and none of them came to >6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988

Sorry.

The problem is solvable. :-)

| $ echo 2050 | xxd -r -p | sha256sum
| 6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988 -

See this output ...

| $ ./mouse-entropy06.py
| abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!"$%^&*()_-+={}[]#~@;:/?.>,<|
| 0----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9
| length: 91
| 91
| ---
| 32 0x20
| 123 0x7b
| 214 0xd6
|
| 80 0x50
| 171 0xab

... from this Python3 code:

| $ cat mouse-entropy06.py
| #!/usr/bin/python3
| a1 ="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!\"$%^&*()_-+={}[]#~@;:/?.>,<|"
| j10='0----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9'
| print(a1)
| print(j10)
| print('length:',len(a1))
| # omitted: SPC, `, '
|
| b2=len(a1)
| print(b2)
| print('---')
|
| # Random Password: G~
| # SHA256: 6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988
|
| c3='G~'
| for d4 in range(len(c3)):
| e5=a1.index(c3[d4])
| f6=e5+91
| g7=f6+91
| h8=g7+91
| for i9 in [e5,f6,g7,h8]:
| if i9<=255:
| print(i9,hex(i9),end=' ')
| print()

Marcel
--
Thu Mar 6 16:54:55 2025 CET (1741276495)
pc-731
87 o6ye i2gg
Lines: 71

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Logen wrote:

Richard Heathfield in sci.crypt:

[...]

I'm also having the same issues as Marcel after a COMPLETED run.

I see that you are using a 32-byte array, so I hashed G~, G~\0, and:

47 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

and none of them came to 6249e6faa58831154f6df352c843a316a98c6b1eb57baa61a8bf4401e3726988

Sorry.

The problem is solvable. :-)

Sure, it only needs a slight change in the C code, but I do not want
to have the shasum of a password and prefer the shasum of the entropy,
so that the shasum can be used for a password as well! :-)

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas in sci.crypt:

Sure, it only needs a slight change in the C code, but I do not want
to have the shasum of a password and prefer the shasum of the entropy,
so that the shasum can be used for a password as well! :-)

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Marcel
--
Thu Mar 6 19:52:08 2025 CET (1741287128)
pc-731
87 v7sm 803e
Lines: 17

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 18:52, Marcel Logen wrote:

Stefan Claas in sci.crypt:

Sure, it only needs a slight change in the C code, but I do not want
to have the shasum of a password and prefer the shasum of the entropy,
so that the shasum can be used for a password as well! :-)

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Marcel

Yes.

He'd do better restricting his character set to 64 elements, and
then using his entropy 6 bits at a time without any need for the
mod. Practical upshot: slightly longer password at no extra cost
other than slightly awkward programming as you dance around the bits.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Logen wrote:

Stefan Claas in sci.crypt:

Sure, it only needs a slight change in the C code, but I do not want
to have the shasum of a password and prefer the shasum of the entropy,
so that the shasum can be used for a password as well! :-)

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Yes, but this can be fixed by doubling the entropy and then
using rejection sampling.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 19:28, Stefan Claas wrote:

Marcel Logen wrote:

<snip>

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Yes, but this can be fixed by doubling the entropy

Not all of us are prepared to wait that long.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 06/03/2025 19:28, Stefan Claas wrote:

Marcel Logen wrote:

<snip>

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Yes, but this can be fixed by doubling the entropy

Not all of us are prepared to wait that long.

Well, and old saying of mine: "privacy cost time and money" ... ;-)

Regards
Stefan



--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/03/2025 20:09, Stefan Claas wrote:

Richard Heathfield wrote:

On 06/03/2025 19:28, Stefan Claas wrote:

Marcel Logen wrote:

<snip>

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Yes, but this can be fixed by doubling the entropy

Not all of us are prepared to wait that long.

Well, and old saying of mine: "privacy cost time and money" ... ;-)

I can get quicker bits with dice.

I can see no reason why it takes so long on my system, which
generally trots along like Concorde on steroids. I've profiled
your code to no avail, and so, for me at least, it's simply not a
practical proposition.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

On 06/03/2025 20:09, Stefan Claas wrote:

Richard Heathfield wrote:

On 06/03/2025 19:28, Stefan Claas wrote:

Marcel Logen wrote:

<snip>

One question I ask myself:

Aren't you losing entropy when you use the modulo operation
in the "bytes_to_chars" function? I wonder.

Yes, but this can be fixed by doubling the entropy

Not all of us are prepared to wait that long.

Well, and old saying of mine: "privacy cost time and money" ... ;-)

I can get quicker bits with dice.

I can see no reason why it takes so long on my system, which generally
trots along like Concorde on steroids. I've profiled your code to no
avail, and so, for me at least, it's simply not a practical proposition.

It's a shame that it's running so slowly for you. As I said, I don't have
any problems with it on my little GPD MicroPC. Let's see how it is for other Linux users.

Pull requests are of course welcome if anyone here also uses GitHub.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas wrote:

https://github.com/706f6c6c7578/mouse_entropy

Impeccable (Y)

Regards

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/03/2025 08:45, Gabx wrote:

Stefan Claas wrote:

https://github.com/706f6c6c7578/mouse_entropy

Impeccable (Y)

Not only is it eminently peccable, but it has already been
thoroughly pecced.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield in sci.crypt:

[interrupted C program]

Entropy collection completed!

Random Password: Za
SHA256:
ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd

| $ echo 8e00 | xxd -r -p | sha256sum
| ccb4d4846d431717f5bad8aabbad7d2b7e07f1611f506964c5c0c1af8f9a07dd -
|
| $ echo 'ibase=16;8E' | bc
| 142
|
| $ echo '142-91' | bc
| 51
|
| abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!"$%^&*()_-+={}[]#~@;:/?.>,<|
| 0----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9

Marcel
--
Fri Mar 7 18:21:13 2025 CET (1741368073)
pc-731
87 ikok lq36
Lines: 27

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Rich wrote:

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

Well, why not as random?

Because humans are very decidely "not very random" (although we like to
think we are).

I think you can't generate the same mouse movement twice, right? And
how could we call that?

If you just 'monitor' the mouse while it's being moved, there will be
decidedly "non-random" aspects to the movement. I.e., for the same
task X, a very similar set of mouse movements will be involved. Will
there be some 'jitter' in the movements? Yes. But that jitter will
likely not be as much as you'd think to gain a truly 'random' output.

And if you specifically ask users to "move the mouse randomly" you'll
simply get side to side shaking, up/down shaking, or spinning in a
circle. None of which are terribly random movements.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Richard Heathfield wrote:

On 06/03/2025 08:51, Stefan Claas wrote:

Rich wrote:

Stefan Claas <fgrsna.pynnf@vagrearg.eh> wrote:

Hi all,

just for fun, or maybe for real usage. ;-)

A small Windows .exe

https://github.com/706f6c6c7578/mouse_entropy

Not likely as "random" as one would think. Better than nothing as
well.

Well, why not as random? I think you can't generate the same mouse
movement twice, right?

Depends on the mouse, I'm afraid.

And how could we call that?

A good start, but you'll want to mix in some bits from somewhere else.

Thanks. Done. You may check out the additional Linux code.

If you are on Linux, you already have a much better randomness
generator in /dev/urandom, which not only takes input from mouse, but
many other I/O devices as well, to 'mix up' the randomness.

You are unlikely to gain higher quality randomness on Linux with just
some code to watch the mouse.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/6/25 2:51 AM, Stefan Claas wrote:

why not as random?

The numbers are somewhat predictable.

If your mouse is at coordinates 5,5 then chances are much better that
the next coordinates are somewhere close to 5,5 than not; e.g.
[4-6],[4-6]. It is extremely unlikely that your next coordinate will
jump to 0,0, 9,0, 9,9, 0,9. Hence the predictability.

Yes, the numbers are better than nothing. But they aren't nearly as
random as we want.



--
Grant. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Taylor wrote:

On 3/6/25 2:51 AM, Stefan Claas wrote:

why not as random?

The numbers are somewhat predictable.

If your mouse is at coordinates 5,5 then chances are much better that
the next coordinates are somewhere close to 5,5 than not; e.g.
[4-6],[4-6]. It is extremely unlikely that your next coordinate will
jump to 0,0, 9,0, 9,9, 0,9. Hence the predictability.

Yes, the numbers are better than nothing. But they aren't nearly as
random as we want.

Well, the mouse coordinates are not the only entropy source.

Here is an explanation with debug output:

Debug: Using 16 bytes for entropy collection

Debug: Starting mouse movement collection
Sample 0: Mouse(x=773, y=467) Time=1400640 Random=0 Result=150
Sample 1: Mouse(x=774, y=468) Time=1400953 Random=77 Result=230
Sample 2: Mouse(x=776, y=478) Time=1401156 Random=25 Result=139
Sample 3: Mouse(x=575, y=319) Time=1401359 Random=244 Result=251
Sample 4: Mouse(x=686, y=320) Time=1401562 Random=113 Result=69
Sample 5: Mouse(x=853, y=407) Time=1401765 Random=202 Result=173
Sample 6: Mouse(x=817, y=542) Time=1401968 Random=148 Result=203
Sample 7: Mouse(x=525, y=491) Time=1402171 Random=215 Result=10
Sample 8: Mouse(x=431, y=320) Time=1402375 Random=59 Result=211
Sample 9: Mouse(x=742, y=360) Time=1402578 Random=236 Result=176
Sample 10: Mouse(x=857, y=275) Time=1402781 Random=95 Result=136
Sample 11: Mouse(x=714, y=249) Time=1402984 Random=6 Result=93
Sample 12: Mouse(x=580, y=503) Time=1403187 Random=230 Result=102
Sample 13: Mouse(x=278, y=506) Time=1403390 Random=16 Result=2
Sample 14: Mouse(x=33, y=391) Time=1403593 Random=238 Result=129
Sample 15: Mouse(x=227, y=306) Time=1403796 Random=158 Result=219
Sample 16: Mouse(x=325, y=405) Time=1404000 Random=3 Result=179
Sample 17: Mouse(x=534, y=572) Time=1404218 Random=193 Result=209
Sample 18: Mouse(x=929, y=387) Time=1404421 Random=33 Result=6
Sample 19: Mouse(x=740, y=448) Time=1404625 Random=133 Result=112
Sample 20: Mouse(x=608, y=619) Time=1404828 Random=241 Result=102
Sample 21: Mouse(x=586, y=454) Time=1405031 Random=230 Result=13
Sample 22: Mouse(x=985, y=378) Time=1405234 Random=76 Result=221
Sample 23: Mouse(x=830, y=256) Time=1405437 Random=156 Result=95
Sample 24: Mouse(x=586, y=535) Time=1405640 Random=50 Result=167
Sample 25: Mouse(x=299, y=529) Time=1405843 Random=47 Result=134
Sample 26: Mouse(x=343, y=313) Time=1406046 Random=227 Result=211
Sample 27: Mouse(x=547, y=367) Time=1406250 Random=40 Result=78
Sample 28: Mouse(x=902, y=455) Time=1406453 Random=229 Result=81
Sample 29: Mouse(x=794, y=296) Time=1406656 Random=79 Result=189
Sample 30: Mouse(x=584, y=526) Time=1406859 Random=30 Result=211
Sample 31: Mouse(x=342, y=569) Time=1407062 Random=44 Result=21

Debug: Raw entropy collection completed

Debug: Raw entropy bytes:
96 e6 8b fb 45 ad cb 0a d3 b0 88 5d 66 02 81 db
b3 d1 06 70 66 0d dd 5f a7 86 d3 4e 51 bd d3 15


Debug: Final SHA256: 142e525b13e4c72232840514e0d7731006c4989fa02f0370c00d3b0ac

Random: This is the raw random byte (0-255) generated by the cryptographic random number generator (CryptGenRandom on Windows, RAND_bytes on Linux)
for each mouse movement.

Result: This is the final entropy byte calculated by combining:

Mouse X coordinate
Mouse Y coordinate
Timestamp
Random byte using XOR operations (^) and limiting to 8 bits (&0xFF)

Example from debug line:

Sample 5: Mouse(x=853, y=407) Time=1401765 Random=202 Result=173
173 is the final byte used for entropy after combining all sources.

The "Result" values you see in the sample lines are the same bytes that
appear in the "Debug: Raw entropy bytes" section, just displayed in
hexadecimal format. These are the actual bytes used for generating either
your password or hex string, depending on which mode you selected.

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Heathfield wrote:

Not only is it eminently peccable, but it has already been thoroughly pecced.

L’anglais, qu’il soit américain ou australien, est une langue morte.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/03/2025 23:13, Gabx wrote:

Richard Heathfield wrote:

Not only is it eminently peccable, but it has already been
thoroughly pecced.

L’anglais, qu’il soit américain ou australien, est une langue morte.

Quidquid dixeris, mate.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Quidquid latine dictum sit altum videtur

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)