Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

"Stanislav V. Smyshlyaev" <> Sun, 24 November 2019 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E47671200D5 for <>; Sun, 24 Nov 2019 07:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BbcDPy2goEPi for <>; Sun, 24 Nov 2019 07:13:18 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 217331200C5 for <>; Sun, 24 Nov 2019 07:13:18 -0800 (PST)
Received: by with SMTP id d5so12777816ljl.4 for <>; Sun, 24 Nov 2019 07:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HtUGy+7kfH28F9D6IKNduH2t9oRrzUylUj83ixvQoQM=; b=MqYBE0bR/GXurhUh5osDjqXtCEm2U7/Pjc2ciGhKMhQuTwd8AakkEUTH1KfjphW9ou Hj7StjH/VuN0bc31+IpiA8hbDODnxJ7oe/DXKkHXGCdsaitbOVHIScskm6F/7IMcuZmT cVaZG+AaHoH2QOrQngH+F2e6uv0DibSqNiGCg1a6zCcgrI75q+yNctRyCK6wxndOfO2m BSHbSHGUBOx6vVD4iq9jWpNlOfKVuxMY7xbhraed9tsnxlNuCx1fwvQVjEIW8JjAVnIG m4FfbXwC7x9HHm5zAkHaoo+Z2r+7Pa5qewc3qqKQM1ONfb1mlQqW0XSLyfv4TnHC9JaK Warg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HtUGy+7kfH28F9D6IKNduH2t9oRrzUylUj83ixvQoQM=; b=djCqW6tYIF56Kgj9YLjNYU+yDvW302G9tkk1TDMR8/Oy3+KR/qmQbLqn3JiEVYGiLG DiVGNgm8MVrPqMesnH8qr7WZgADagkOswyLWnFEmKU1Sum5p68X0ZJR7D2AMDHYeMEDc NjPdLlqX4/wVAhoM6sNmmQvyzNV9J4cA9yI1QkTHnRhpOA5JWW8NL8qz2COFay17gx8v bTZSoNgMN9v06ZOKPjIgF7nHyvg6BEQ77paA53C1AKoAXqLEgZtjtgzIZfGvl3X0q5Gb /4ammK9BQsWansYsSc3oua2oLljYAh607OS1hyN9k88L+8o7+wbfaEQG2vduTdP/ztr0 A04g==
X-Gm-Message-State: APjAAAU12etDiobZ3FtloY/T3uQWzFlulN1lK7t1U1GTUL9zeMH9aLOz EiZOCPgqCfp6Cu+SaN7W6ymDAWiaUFYOlYb4jao=
X-Google-Smtp-Source: APXvYqwepi00Gqiqb1G/qMddZZLCRalj8rRAHsYD/UGwXkXC/vwNTNY4J0/pUhg9BaOBbcOqcRyiSS7QMaOMr4t4Lm0=
X-Received: by 2002:a2e:a0ce:: with SMTP id f14mr19566031ljm.241.1574608396034; Sun, 24 Nov 2019 07:13:16 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: "Stanislav V. Smyshlyaev" <>
Date: Sun, 24 Nov 2019 18:13:04 +0300
Message-ID: <>
To: "Riad S. Wahby" <>, Nick Sullivan <>, Christopher Wood <>, Christopher Wood <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000001b297105981916d0"
Archived-At: <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Nov 2019 15:13:20 -0000

Thanks, Riad!

The security analysis can be modified for HMAC instead of Signature without
significant problems, I suppose. And also several useful alternative
constructions can be proposed (based on HMAC or DH as an operation with a
But this makes the scope of the I-D (initially motivated by TLS servers)
wider - a "menu of choices" of good solutions instead of one good solution.
If we want to do this, then, as it seems to me, the current process with an
I-D, which has already passed the RGLC and has moved to Waiting for
Document Shepherd stage, should be stopped and returned to the previous
stage of a work item before RGLC.

Personally, I really like the task of providing several good constructions
for "improving randomness" using various constructions - but I'm not sure
that it should be done in this document and not in a new one (Nick, Chris,
could you please share your opinion on this?..).

Best regards,

пт, 22 нояб. 2019 г. в 19:28, Riad S. Wahby <>;:

> "Stanislav V. Smyshlyaev" <>; wrote:
> > Yes, I believe that it can be a great future direction of work, but this
> > will be another construction, requiring additional security analysis
> etc. I
> > think that the topic of improving randomness will be always a very
> > important one, so a lot of other good ideas and good constructions may
> > arise in the future.
> I looked at the security analysis a while ago and although it's not
> fresh in my mind now, at the time I was convinced that the analysis
> applied almost directly to HMAC rather than a signature. Maybe I'm
> crazy, incompetent, or mis-remembering, though! :)
> As a more general point: the document's intro hints at this, but
> maybe it should be made more explicit that this protocol is geared
> towards the case where one's key is stored in an HSM. Sure, it works
> in other cases, but the choice to use signatures appears to be directly
> motivated by HSMs---otherwise, why not use a cheaper construction?
> -=rsw