urandom number in Emacs

urandom number in Emacs

[Emanuel Berg via Emacs development discussions.]

This is a dynamic module with a function that reads from
/dev/urandom ... so more random numbers with `random-urandom'
than with `random' (since Lisp cannot read from /dev/urandom
because it's a non-regular file - IIUC?) - so instead this
uses the same C as in pwgen(1) to do it, pretty simple I
guess :P

So now one can do (random-urandom) ... like any other
Lisp function and be on everyone else's level. Only cooler B)

See a very long discussion on gmane.emacs.help ...

Anyway, one C file, one C header file, and one Makefile here:

  https://dataswamp.org/~incal/emacs-init/random-urandom/

Just do 'make run'.

Keep it real time ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: urandom number in Emacs

[Emanuel Berg via Emacs development discussions.]

> This is a dynamic module with a function that reads from
> /dev/urandom ... so more random numbers with
> `random-urandom' than with `random' (since Lisp cannot read
> from /dev/urandom because it's a non-regular file - IIUC?) -
> so instead this uses the same C as in pwgen(1) to do it,
> pretty simple I guess :P
>
> So now one can do (random-urandom) ... like any other Lisp
> function and be on everyone else's level. Only cooler B)
>
> See a very long discussion on gmane.emacs.help ...
>
> Anyway, one C file, one C header file, and one Makefile
> here:
>
>   https://dataswamp.org/~incal/emacs-init/random-urandom/
>
> Just do 'make run'.

... Hello?

Information theory guys? Practical guys writing it in Lisp?
Portable and without any external tools? Why, don't run away
all of a sudden?

Can anyone hear me?

I mean _this_ time around?

-- 
underground experts united
https://dataswamp.org/~incal

Re: urandom number in Emacs

[Omar Polo]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org> writes:

>> This is a dynamic module with a function that reads from
>> /dev/urandom ... so more random numbers with
>> `random-urandom' than with `random' (since Lisp cannot read
>> from /dev/urandom because it's a non-regular file - IIUC?) -
>> so instead this uses the same C as in pwgen(1) to do it,
>> pretty simple I guess :P
>>
>> So now one can do (random-urandom) ... like any other Lisp
>> function and be on everyone else's level. Only cooler B)
>>
>> See a very long discussion on gmane.emacs.help ...
>>
>> Anyway, one C file, one C header file, and one Makefile
>> here:
>>
>>   https://dataswamp.org/~incal/emacs-init/random-urandom/
>>
>> Just do 'make run'.
>
> ... Hello?
>
> Information theory guys? Practical guys writing it in Lisp?
> Portable and without any external tools? Why, don't run away
> all of a sudden?
>
> Can anyone hear me?
>
> I mean _this_ time around?

I mean, if you really need something like that and emacs doesn't already
provide it, why don't try cooking a diff to add it to base emacs instead
that an external module?

Also, the code is wrong:

>  if (nbytes == 0) {
>    return (rnd_num % max_num);
>  } else {
>    fprintf(stderr, "No entropy available!\n");
>    exit(1);
>  }

I don't think you want to quit emacs unconditionally if there's no
entropy.

Also, in some circumstances there could be better (and faster) ways to
obtain a random number, see for e.g. arc4random.

Cheers,

Omar Polo

P.S.: are you sure about checking for EAGAIN?  A read for a file
descriptor not marked as non-blocking shouldn't fail with EAGAIN, but
that's a minor nitpick.

Re: urandom number in Emacs

[Emanuel Berg via Emacs development discussions.]

Omar Polo wrote:

> I mean, if you really need something like that and emacs
> doesn't already provide it, why don't try cooking a diff to
> add it to base emacs instead that an external module?

`random' isn't good enough for passwords, it could since it is
a C built-in read from /dev/urandom but it doesn't, and you
can't do that from Lisp since /dev/urandom is a non-regular
file. head(1) and pwgen(1) can do it from C and so can Emacs,
but to have it as a Lisp primitive or a DM ... but isn't that
why you have DMs, you shouldn't have to recompile the whole
thing to get it? It is more ... modular?

> Also, the code is wrong:

>>  if (nbytes == 0) {
>>    return (rnd_num % max_num);
>>  } else {
>>    fprintf(stderr, "No entropy available!\n");
>>    exit(1);
>>  }
>
> I don't think you want to quit emacs unconditionally if
> there's no entropy.

OK ... I'll just return something to denote it didn't work.
Hm ...

> Also, in some circumstances there could be better (and
> faster) ways to obtain a random number, see for
> e.g. arc4random.

Doesn't that read from /dev/urandom as well?
What's better/faster about it? You need a DM/recompile for
that as well since it is in libc, or am I wrong?

Nah, if it was good enough for pwgen(1) I take it ...

> P.S.: are you sure about checking for EAGAIN? A read for
> a file descriptor not marked as non-blocking shouldn't fail
> with EAGAIN

I am not sure, again they had it in pwgen ...

> but that's a minor nitpick.

Indeed ... hehe

-- 
underground experts united
https://dataswamp.org/~incal

Re: urandom number in Emacs

[Omar Polo]

Emanuel Berg via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Omar Polo wrote:
>
>> I mean, if you really need something like that and emacs
>> doesn't already provide it, why don't try cooking a diff to
>> add it to base emacs instead that an external module?
>
> `random' isn't good enough for passwords, it could since it is
> a C built-in read from /dev/urandom but it doesn't, and you
> can't do that from Lisp since /dev/urandom is a non-regular
> file. head(1) and pwgen(1) can do it from C and so can Emacs,
> but to have it as a Lisp primitive or a DM ... but isn't that
> why you have DMs, you shouldn't have to recompile the whole
> thing to get it? It is more ... modular?

Recompiling Emacs from sources takes a couple of minutes, and it's a
trivial function that you can write and test apart before including it
to Emacs.  Also, I'm pretty sure that no distribution ships *by default*
Emacs modules.

Furthermore, it's an annoyance for the users: if I want to use it, I
have to compile it anyway, whether if it's an emacs built-in all I have
to do is install/update Emacs via my package manager and I'm happy ;-)

>> Also, the code is wrong:
>
>>>  if (nbytes == 0) {
>>>    return (rnd_num % max_num);
>>>  } else {
>>>    fprintf(stderr, "No entropy available!\n");
>>>    exit(1);
>>>  }
>>
>> I don't think you want to quit emacs unconditionally if
>> there's no entropy.
>
> OK ... I'll just return something to denote it didn't work.
> Hm ...

you could rewrite the function to return the value via a pointer, e.g.

int
get_random_number(uint32_t *n)
{
	/* do stuff */
	if (succeeded) {
		*n = the random number;
		return 0;
	}
	return -1;
}

/* later */

uint32_t n;
if (get_random_number(&n) == -1) {
	/* Ooops */
}

>> Also, in some circumstances there could be better (and
>> faster) ways to obtain a random number, see for
>> e.g. arc4random.
>
> Doesn't that read from /dev/urandom as well?
> What's better/faster about it? You need a DM/recompile for
> that as well since it is in libc, or am I wrong?

arc4random uses a per-process random stream that sometimes gets
re-initialized from /dev/urandom.  This means that most of the time you
have access to a good RNG without having to make a system call.

> Nah, if it was good enough for pwgen(1) I take it ...

You should also consider why that was good for pwgen.  If something is
good for program A, it may not be "good enough" for program B.  I don't
know pwgen, but given that's in the first section of the manual is
probably a program that generates a password, print it to stdout and
quits.  It doesn't have bottlenecks.

A program like Emacs on the other hand needs to call that function
possibly multiple times, so investigating a bit for a faster way to
obtain good random number is worth it IMHO.

>> P.S.: are you sure about checking for EAGAIN? A read for
>> a file descriptor not marked as non-blocking shouldn't fail
>> with EAGAIN
>
> I am not sure, again they had it in pwgen ...
>
>> but that's a minor nitpick.
>
> Indeed ... hehe

Re: urandom number in Emacs

[Emanuel Berg via Emacs development discussions.]

I've heard "Emacs don't need Elispers, Emacs needs
C programmers".

OK, so you have a list of things Emacs needs in C?

Or maybe a linked list I should say ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: urandom number in Emacs

[Emanuel Berg via Users list for the GNU Emacs text editor]

Omar Polo wrote:

> Recompiling Emacs from sources takes a couple of minutes,
> and it's a trivial function that you can write and test
> apart before including it to Emacs.

This is much better than recompiling Emacs. Why would you do
that? That's the idea with dynamic modules, then you can have
libraries in C as well as you now have them in .elc files and
use `require' one them and you compile them and only them.

> Also, I'm pretty sure that no distribution ships
> *by default* Emacs modules.

What do you mean?

> Furthermore, it's an annoyance for the users: if I want to
> use it, I have to compile it anyway, whether if it's an
> emacs built-in all I have to do is install/update Emacs via
> my package manager and I'm happy ;-)

Hm ... what Emacs do you run?

You typically get very old versions that way ... Emacs 27
seems to be in the Debian 11 repos ...

This works with Emacs 29 I think ... not sure but the
initialization should tell. Here is how I install Emacs [1]

But as for random-urandom feel free to - well, first tell me
what I should fix, then after that has been done God willing
if you want to use it wherever be my guest. Otherwise I'll
just put it on my web pile.

Hey! Is there a "CELPA" perhaps for Emacs C? Put it there <3

> you could rewrite the function to return the value via a pointer, e.g.
>
> int
> get_random_number(uint32_t *n)
> {
> 	/* do stuff */
> 	if (succeeded) {
> 		*n = the random number;
> 		return 0;
> 	}
> 	return -1;
> }
>
> /* later */
>
> uint32_t n;
> if (get_random_number(&n) == -1) {
> 	/* Ooops */
> }

Yeah, but what then? That's just moving the situation.
The random number is returned as an emacs_value, see the
source [2] - perhaps one can send a nil emacs_value
instead of using the make_integer ...

> You should also consider why that was good for pwgen.
> If something is good for program A, it may not be "good
> enough" for program B. I don't know pwgen, but given that's
> in the first section of the manual is probably a program
> that generates a password, print it to stdout and quits.
> It doesn't have bottlenecks.

It has _randomness_, and more so than `random'.

> A program like Emacs on the other hand needs to call that
> function possibly multiple times, so investigating a bit for
> a faster way to obtain good random number is worth it IMHO.

Yeah, every history need a bit of polishing, as does every
program ...

So TODO, don't exit(1), and see if there is a speed
disadvantage compared to `random' ... what else?

[1] https://dataswamp.org/~incal/conf/.zsh/install-emacs
[2] https://dataswamp.org/~incal/emacs-init/random-urandom/random-urandom.c

-- 
underground experts united
https://dataswamp.org/~incal

Re: urandom number in Emacs

[Emanuel Berg via Emacs development discussions.]

> I've heard "Emacs don't need Elispers, Emacs needs
> C programmers".
>
> OK, so you have a list of things Emacs needs in C?
>
> Or maybe a linked list I should say ...

Heh, but there are already built-ins (Lisp primitives) and
so-called special forms in C _everywhere_.

Elisp has C from behind (the above mention) but also from
straight ahead (the DMs), soon the Lisp part will be a syntax
and order-of-execution business, the rest will be C and is
already to a large extent!

Man, I knew it was common but not like this ... when did
this happen? Maybe I should pay more attention ...

Now I guess I'm not needed as an Elisper because it is on its
way out but also not as a C programmer since the revolution
has started without me *sob*

-- 
underground experts united
https://dataswamp.org/~incal