From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Julian Scheid Newsgroups: gmane.emacs.devel Subject: Re: New function: secure-random-bytes Date: Thu, 16 May 2019 00:09:41 +1200 Message-ID: References: <87liwrh7r2.fsf@lifelogs.com> <4E04CA7B.2020101@cs.ucla.edu> <51474549.2050005@cs.ucla.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f8a56f0588ec06c5" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="19946"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Leo Liu , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 15 14:10:07 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hQsjW-00051j-Fs for ged-emacs-devel@m.gmane.org; Wed, 15 May 2019 14:10:06 +0200 Original-Received: from localhost ([127.0.0.1]:36263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQsjV-0006m5-HM for ged-emacs-devel@m.gmane.org; Wed, 15 May 2019 08:10:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQsjN-0006kf-N7 for emacs-devel@gnu.org; Wed, 15 May 2019 08:09:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQsjM-0000qi-6b for emacs-devel@gnu.org; Wed, 15 May 2019 08:09:57 -0400 Original-Received: from mail-it1-x12a.google.com ([2607:f8b0:4864:20::12a]:33192) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQsjL-0000oK-VU for emacs-devel@gnu.org; Wed, 15 May 2019 08:09:56 -0400 Original-Received: by mail-it1-x12a.google.com with SMTP id u16so5340660itc.0 for ; Wed, 15 May 2019 05:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YZN3APKttnTFa165u6CCI0g+WXrpfo/JEFDBFo72paY=; b=CoZA80ykVQsl9lZfeWw0A5yiiHeJ22gwFwQbFqN+vR6lQ3/QuBtRkGge0Vtm96o2yz P3zLvBtbkitVX3q7VaoABIys2nkm550pvTWPsy/Z/hL+6IoqI6/emuRQaL5LN/JEXuvt L90Hg9+gNg1Nl8YHS28pBFQub7FVV7hjyrfoFsWgY8GmaqMvBTahfFreZPwbpeKBm/af KytIldPXTuxV/28RvJ8yDfyqg85mmP3cPua1AgEfqaRyLlMF6OoZ3C/+XglG1OoTK8lM rqICIVAS82NiRcbm2ziL0r+sh+IjNFPs9xczggsU3DuVKxpCT/6RvwYrZPRltvtPCU9F zP1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YZN3APKttnTFa165u6CCI0g+WXrpfo/JEFDBFo72paY=; b=jOcy4CWiZszhWAvGgA+HYfs2Zn1sEK50xFcTEoEfyoXINoNoAk+bHmy0NG5xDMCQVs 8nJccmStCtRcOVvxwpStDxb/eMxYugbky3piUxfSEDFFFBz3BIOpyenJR3KI6UdjXwoV 3IP20iqnNl9Ohq9BPINxRlh9rhGX3AGFPz0IqIgBHm++Z9liWqgUnKlCXLgLv2Zn1XMP 5DsVIjmFJGRVgZAo8Xldm8gFkjACstfxu2DncE/PDn9ZroK9+F3pPLQM6iCFZd50Gbwc PESUCbrNXFtTggVMXE4ZvlyQyG8qPyDrQwRhfIrWlQzTopX1s5WmoxSu4/qBU9vJkx7Y ohRQ== X-Gm-Message-State: APjAAAVN2dLOx1q+tk1Cw6YyE4cv9oDvYMCICQmfe0QVsp6SukHupANF GqUQTl9tQjORRjYaEkawel6AVyf3RIBaAh27OP0= X-Google-Smtp-Source: APXvYqy8iFlyq57XsMtQ5rp9HRYT/b/nFFBga0t6kmKj/8OBJDpuSA6LRKvAu8f8wR9AVztGualuKXIwOeslsfrzjP8= X-Received: by 2002:a24:29d4:: with SMTP id p203mr7887458itp.63.1557922194169; Wed, 15 May 2019 05:09:54 -0700 (PDT) In-Reply-To: <51474549.2050005@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::12a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236536 Archived-At: --000000000000f8a56f0588ec06c5 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 19, 2013 at 5:49 AM Paul Eggert wrote: > On 03/18/13 03:26, Leo Liu wrote: > > > From that discussion (almost two years ago) there was clearly interest > > in having a strongly random source. The solution you proposed looks > > excellent. Are there any progress on this matter? > > There's been no progress, alas. > Yours is the first sign of interest that I've seen since then. > I may be able to find a student or two > who might volunteer to work on this; we'll see. > > There's one extra wrinkle I'd like to add while we're at it: > if available we should use the random-number instructions > in recent implementations of x86 and x86-64 architectures > as this should yield even better performance. > > http://en.wikipedia.org/wiki/RdRand I'm working on an implementation of SASL authentication and for that I need to generate a reasonably secure nonce. Performance is not an issue in my application because it only needs to perform authentication every now and then, and each time only a single nonce is needed. I'm now using `(random t)' but that's brittle: I don't see a way to guarantee that the random data it produces is of sufficient quality. (There's a chance both /dev/urandom is unavailable (perhaps because Emacs is running in a chroot or a container) and GnuTLS initialization throws an error, in which case `random' would silently fall back to a non-secure source. I suppose it's good enough for my use case but it does highlight the absence of `secure-random-bytes'.) I wonder, is there anything speaking against adding a simple implementation now and worrying about maximal performance later? --000000000000f8a56f0588ec06c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 19, 2013 at = 5:49 AM Paul Eggert <eggert@cs.ucl= a.edu> wrote:
On 03/18/13 03:26, Leo Liu wrote:

> From that discussion (almost two years ago) there was clearly interest=
> in having a strongly random source. The solution you proposed looks > excellent. Are there any progress on this matter?

There's been no progress, alas.
Yours is the first sign of interest that I've seen since then.
I may be able to find a student or two
who might volunteer to work on this; we'll see.

There's one extra wrinkle I'd like to add while we're at it: if available we should use the random-number instructions
in recent implementations of x86 and x86-64 architectures
as this should yield even better performance.

http://en.wikipedia.org/wiki/RdRand

I'm working on an implementation of SASL authentication and fo= r that I
need to generate a reasonably secure nonce.
Performance is not an issue in my application because it only = needs to
perform authentication every now and then, and each time= only a single
nonce is needed.

I'm = now using `(random t)' but that's brittle: I don't see a way to=
guarantee that the random data it produces is of sufficient qual= ity.

(There's a chance both /dev/urandom is un= available (perhaps because
Emacs is running in a chroot or a cont= ainer) and GnuTLS initialization
throws an error, in which case `= random' would silently fall back to a
non-secure source.=C2= =A0 I suppose it's good enough for my use case but it
does hi= ghlight the absence of `secure-random-bytes'.)

I wonder, is there anything speaking against adding a simple
imp= lementation now and worrying about maximal performance later?
--000000000000f8a56f0588ec06c5--