Re: [PATCH v2] Improve mutt's random data generator.

Alejandro Colomar via Mutt-dev <[email protected]>
Newsgroups gmane.mail.mutt.devel
Message-ID <aexO44YKEA0OtyWq@devuan>
Hi Kevin,

On 2026-04-25T10:27:36+0800, Kevin J. McCarthy wrote:
> On Fri, Apr 24, 2026 at 03:53:19PM +0200, Alejandro Colomar via Mutt-dev wrote:
[...]
> > And checking gnulib documentation, it seems that the only platform that
> > lacks this header file was MSVC 14.  Is mutt being built there?
> > If not, we could maybe remove that check in master everywhere.
> 
> I don't believe we target that platform.  I'll add a todo to remove the
> checks in master.  Thanks!

You're welcome!  :)

> > Should we prefer arc4random_buf(3) over getrandom(2) if it's available?
> > It's certainly simpler, and thus less prone to subtle bugs.
> 
> I thought about that, but I'm not sure if the Linux implementation also
> ported over to a more secure algorithm than RC4.

The commit that added it to glibc says 'based on scalar Chacha20':

	commit 6f4e0fcfa2d2b0915816a3a3a1d48b4763a7dee2
	Author: Adhemerval Zanella Netto <[email protected]>
	Date:   2022-07-21 10:04:59 -0300

	    stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417)
	    
	    The implementation is based on scalar Chacha20 with per-thread cache.
	    It uses getrandom or /dev/urandom as fallback to get the initial entropy,
	    and reseeds the internal state on every 16MB of consumed buffer.
	    
	    To improve performance and lower memory consumption the per-thread cache
	    is allocated lazily on first arc4random functions call, and if the
	    memory allocation fails getentropy or /dev/urandom is used as fallback.
	    The cache is also cleared on thread exit iff it was initialized (so if
	    arc4random is not called it is not touched).
	    
	    Although it is lock-free, arc4random is still not async-signal-safe
	    (the per thread state is not updated atomically).
	    
	    The ChaCha20 implementation is based on RFC8439 [1], omitting the final
	    XOR of the keystream with the plaintext because the plaintext is a
	    stream of zeros.  This strategy is similar to what OpenBSD arc4random
	    does.
	    
	    The arc4random_uniform is based on previous work by Florian Weimer,
	    where the algorithm is based on Jérémie Lumbroso paper Optimal Discrete
	    Uniform Generation from Coin Flips, and Applications (2013) [2], who
	    credits Donald E. Knuth and Andrew C. Yao, The complexity of nonuniform
	    random number generation (1976), for solving the general case.
	    
	    The main advantage of this method is the that the unit of randomness is not
	    the uniform random variable (uint32_t), but a random bit.  It optimizes the
	    internal buffer sampling by initially consuming a 32-bit random variable
	    and then sampling byte per byte.  Depending of the upper bound requested,
	    it might lead to better CPU utilization.
	    
	    Checked on x86_64-linux-gnu, aarch64-linux, and powerpc64le-linux-gnu.
	    
	    Co-authored-by: Florian Weimer <[email protected]>
	    Reviewed-by: Yann Droneaud <[email protected]>
	    
	    [1] https://datatracker.ietf.org/doc/html/rfc8439
	    [2] https://arxiv.org/pdf/1304.1916.pdf

> 
> I think we'd want to leave the getrandom in any case, so for now I'll put it
> first.

Ok.

> 
> > Anyway:
> > 
> > 	Reviewed-by: Alejandro Colomar <[email protected]>
> 
> Thanks!


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmnsT28ACgkQ64mZXMKQ
wqlmGxAAmH5h8ndE14i/ocflN86QMN21GMmAL49blcNsnYHu9eitLCQ4CH89umZV
rmiI5apksgJnfUItpH9PstXhxYcJHOQLHydvLfBVl7/NVCNOw7JVqVA52eV4utMC
Sx04OPaifwtR6rrcjlJYl390NIuF/7DBeQZLhUQ9IY+HI5KTzHgjehv6qGObGgku
duuBzY7/d4158aXxj5Zzbx4D4P4LSKNbnwfm0QDKHXITCKHS1QiTYHdSROogXGYf
ToTAZaMOGBaGgMfiGyzF/KTb1AFhPLIlFA7/tkjIJDZSmz0dx/5+73uO4Bufv1HY
F4x2XyA55BHjWmVyl8qCC4JRTvPQ17ZAoNEziuyMFJImWav2dUhF5LUgmcB+ng02
IUGdiFZmzpV4d1Gv28yJGAwg40HbEinUmUCKdTrnLO3+oNdG/au7oWCbX7BXftIY
pX8mS1x5GlBd8g/g8c28rIqkLvqz55wxY+5kknNMO2w3sekOldIAFEPBQ3y2wwei
JaK3I1D2inC6GM7rCS1bFBsOUUZxh0JznImb+5uRbz+3Dz8IHKF1szXND+q08I5E
UhPbuLDOyUTOJD0aHRNwJK5mZbzy6/j2LEYFp4Ta8PO4qxF+qjy0vvvS/GoGrbcB
BOD8keKJjBHH6Nf0Eo1saOAr3yLAIB8UcmqvZcbR62wNotc3Qb4=
=2x4z
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.