From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.bugs Subject: bug#58472: [PATCH] Make `message-unique-id' less prone to collisions Date: Mon, 17 Oct 2022 11:40:54 -0700 Message-ID: <87ilki70p5.fsf@rfc20.org> References: <871qr794o2.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24579"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58472@debbugs.gnu.org To: Paul Eggert , Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 17 20:42:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1okV40-0006Ax-PO for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Oct 2022 20:42:12 +0200 Original-Received: from localhost ([::1]:50984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okV3z-0000iW-Jz for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Oct 2022 14:42:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okV3q-0000i9-SD for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 14:42:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50884) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1okV3q-0004ye-E7 for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 14:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1okV3q-0004w8-22 for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 14:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Matt Armstrong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Oct 2022 18:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58472 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 58472-submit@debbugs.gnu.org id=B58472.166603207118915 (code B ref 58472); Mon, 17 Oct 2022 18:42:02 +0000 Original-Received: (at 58472) by debbugs.gnu.org; 17 Oct 2022 18:41:11 +0000 Original-Received: from localhost ([127.0.0.1]:49962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okV31-0004v1-5v for submit@debbugs.gnu.org; Mon, 17 Oct 2022 14:41:11 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:55469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okV2w-0004uI-RN for 58472@debbugs.gnu.org; Mon, 17 Oct 2022 14:41:10 -0400 Original-Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id EDC4140007; Mon, 17 Oct 2022 18:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1666032060; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3QRu1wWeOtKcoG3dR+Q3nbH8t3gJ/lMqneam4Ba3WtU=; b=AO2FyFbGB3Kv7nze7nbt0ng5gGOBXvx2SEUUty6Ly0HZBCeeHP1QF5WoKQrVrdgj8rq5Oi +U4mGH4mZ3tyuvIWB+emfW3b/OtJjYws+KlmCvjgtXtbOf205zG55goiBaAyDSJaTFzDbF JnZZ2g2E+lWWAOv3+8fwy3F8HdMRWCL0xSjER9wvf3UDjXCGHM1CkqrZD1hR50i7SvBp8h PQqmLDiIZqKZCMORigL62Z1iUx8hPkFWOo6g8rJiEs1hTxYZn682+dg7Vr7a1KXmPe3I61 UEoJV67o1dqZmhDg/NfcmSCEgxwpOb8WPb/GjoKQ2elpdmMWRzpm+rCsrAYSew== Original-Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1okV2k-001ALg-0Z; Mon, 17 Oct 2022 11:40:54 -0700 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245749 Archived-At: Paul Eggert 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?