From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#58472: [PATCH] Make `message-unique-id' less prone to collisions Date: Sun, 16 Oct 2022 00:32:58 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2513"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58472@debbugs.gnu.org, Matt Armstrong To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 16 09:34:15 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 1ojyA3-0000SA-Bn for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Oct 2022 09:34:15 +0200 Original-Received: from localhost ([::1]:56916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojyA2-0003lq-0U for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Oct 2022 03:34:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojy9r-0003it-HH for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 03:34:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44150) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojy9q-0006rd-6o for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 03:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojy9q-0003dZ-18 for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 03:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Oct 2022 07:34:01 +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.166590558813899 (code B ref 58472); Sun, 16 Oct 2022 07:34:01 +0000 Original-Received: (at 58472) by debbugs.gnu.org; 16 Oct 2022 07:33:08 +0000 Original-Received: from localhost ([127.0.0.1]:43228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojy8y-0003c6-2P for submit@debbugs.gnu.org; Sun, 16 Oct 2022 03:33:08 -0400 Original-Received: from mail-oa1-f54.google.com ([209.85.160.54]:46933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojy8v-0003bU-7P for 58472@debbugs.gnu.org; Sun, 16 Oct 2022 03:33:07 -0400 Original-Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-1326637be6eso10391239fac.13 for <58472@debbugs.gnu.org>; Sun, 16 Oct 2022 00:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=LACH3a4wnRsldMaDYU4JnjFjA/SDcZ5U/OJe2SYpX10=; b=MutvcuUAVqgcLGGTdpaNO7fFpoocC4nUSYLnveNon4w+1/uvgaBKptyKWMLH8A96cg onhpPdy3ztZoZ2+F+gSWKUApoPcCRQIgOKfiRHR6PAh/w30D9hK5AUgPgVYdzmN544SM WxuF2YHEbZgOYLcG8DVPazZLlznBZW+PXlHRr3s4nynRlMFr+PD96PRaqomkEXyK3CBu 77aF4HGq6O2uTHFsbtv+n6hFMwSn/iK2jiG+7Dn+RpzyH6+5xu8beFTqX8+vYQAkp3py qTg6uWKqd/a5mhelvm3FXquWpIBPuWvGkzdU2jyMkqruVBmq4rY1vMZfYieaeRIYNTAt DcCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=LACH3a4wnRsldMaDYU4JnjFjA/SDcZ5U/OJe2SYpX10=; b=42VQfUiqyg9g3xLX35KanWr7US9pBj4hbvQGSMzRl+nbqYZWOrMs2ebuJ6Bemcndvi xXq1eaWreEeWiOWTur0d5oH7Cmf7SU2h1U7YI2xqT+a/yPL0WqkMfWGfzbwJs75JMILC yUMNrrZg/7KmWGXYaJej4oHHl9p+dGY0R1Cw89YD7yyc5VW9/sJvzu1gYcQIU9scZy3Y aFMjuXqFoZfIuJNtm1rzoZ6Ng+agOg+5khdcmPQLO5sXIQp7SfQF1+1wGzW4X5UVqwIL sxLtkczq8zFlcDNM9HfebuhZMu3Wvt1x9FoOldf9cd9JtioSWyRNQH+u2MdqafYPLdKl xS0A== X-Gm-Message-State: ACrzQf08oaqgp5UKdPf6eyKmKXk6BOrOLIwr6CCY/o83eGoAH2efAZAr Y+mAz3CWuwpAJ9XmIuAsb9qvQ5z2BSMfZkPQbZg= X-Google-Smtp-Source: AMsMyM4o6piECmWBoSShFEvSmB/wS5AYkq8LCTKK6KyVvm5BSWMul1FWs8zWJ51dfiRmrMtACWEW7Sefl7NcU2bZlhU= X-Received: by 2002:a05:6870:9126:b0:132:b724:e96c with SMTP id o38-20020a056870912600b00132b724e96cmr12667330oae.199.1665905579335; Sun, 16 Oct 2022 00:32:59 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 16 Oct 2022 00:32:58 -0700 In-Reply-To: X-Hashcash: 1:20:221015:58472@debbugs.gnu.org::h0sRKAilpfVUyGR3:5+mT 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:245602 Archived-At: Stefan Kangas writes: >> If that's a concern, we should be using more-random data, e.g., with >> >> (base64-encode-string >> (secure-hash 'md5 'iv-auto 128 nil t)) >> >> if we want 128 bits of randomness (this yields a string like >> "B8a3usyu5QSE/rTLu0nIHg=3D=3D"). > > Sounds good to me, but: Looking at the implementation of `secure-hash', doesn't this run the random number through the MD5 function? I guess that will reduce entropy, as AFAIU hash functions like MD5 are not really bijective functions f: =E2=84=95 =E2=86=92 =E2=84=95. (In other words, it does not g= ive you a permutation of the set of all natural numbers.) I don't think it matters for generating a Message-ID, but I thought it was worth pointing out. So if I'm right, you might not want to use this particular method for generating cryptographic keys, if anyone happens to be doing stuff like that in ELisp. In any case, I do think we should add an easy way of directly accessing the getrandom(2) syscall [or equivalent]. >> As an aside, it's weird that there's no easy way to ask Emacs for an >> N-bit random integer, where the randomness is taken from system entropy. >> Shouldn't we extend Emacs to support that? E.g., (make-string 128 >> 'iv-auto) could give you an N-byte entropy-derived random string, or >> (random -N) could give you an N-bit entropy-derived random nonnegative >> integer, or something like that. Then we could write something like this= : >> >> (base64-encode-string (make-string 16 'iv-auto)) >> >> to get a Message-ID component with 16 bytes (128 bits) of entropy. > > Yes, we should find a better interface here. How about `secure-random' (named in analogy with `secure-hash')? (secure-random 8) =3D> <8 byte number> This is the same interface as the Linux getrandom(2) system call, and the portable function in Gnulib, so it's easy enough to implement. BTW, we currently call getrandom with flags 0 in extract_data_from_object. Should we consider using GRND_RANDOM? The Linux kernel uses the same code path for /dev/random and /dev/urandom these days, IIUC, so maybe it doesn't matter.