[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58472: [PATCH] Make `message-unique-id' less prone to collisions
From: |
Matt Armstrong |
Subject: |
bug#58472: [PATCH] Make `message-unique-id' less prone to collisions |
Date: |
Mon, 17 Oct 2022 11:40:54 -0700 |
Paul Eggert <eggert@cs.ucla.edu> writes:
> I've been looking into this and have several patches along these lines.
> None of them address message-unique-id directly yet (I plan to tackle
> this soon) but they do address the general problem area. The basic idea
> is to use a new make-nonce primitive.
I like it.
> ---
> doc/lispref/numbers.texi | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi
> index fdcda328d8..c1a1349d1a 100644
> --- a/doc/lispref/numbers.texi
> +++ b/doc/lispref/numbers.texi
>
> -If @var{limit} is a string, it means to choose a new seed based on the
> -string's contents.
> +If you need a random nonce for cryptographic purposes, @code{(random
> +t)} is typically not the best approach, as it can adversely affect other
> +parts of your program that benefit from reproducible results, and it can
> +leave information about the nonce scattered about Emacs's internal state.
Mention the new `make-nonce'?
With respect to "cryptographic purposes" how about mentioning that
`random' itself is potentially seeded from a cryptographically weak
source and makes no promise to use a PRNG suitable for cryptography? If
I'm right about those two assertions, I think they are important to
mention.
> diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi
> index cf961e9e7c..0f3e0ae213 100644
> --- a/doc/lispref/strings.texi
> +++ b/doc/lispref/strings.texi
> @@ -455,6 +455,18 @@ Creating Strings
> Remove the final newline, if any, from @var{string}.
> @end defun
>
> +@defun make-nonce length &optional function
> +Return a newly created random string of length @var{length}.
> +The string is unibyte, with bytes taken from system entropy,
> +and with each string value equally likely.
> +
> +If @var{function} is given, call it with the newly created string as
> +an argument and return the value that @var{function} returns.
> +When the function exits, overwrite the string's random contents with
> +unspecified bytes, to lessen information leakage in insecure code.
> +The string's contents are therefore valid only during the function call.
> +@end defun
First question I'll have as a reader: what happens if the system has low
entropy? Does this block? Signal an error?
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, (continued)
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Eli Zaretskii, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Lars Ingebrigtsen, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Eli Zaretskii, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Stefan Kangas, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Lars Ingebrigtsen, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Stefan Kangas, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions,
Matt Armstrong <=
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Paul Eggert, 2022/10/17
- bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Eli Zaretskii, 2022/10/18
bug#58472: [PATCH] Make `message-unique-id' less prone to collisions, Lars Ingebrigtsen, 2022/10/13