Re: [CFRG] I-D Action: draft-irtf-cfrg-rsa-blind-signatures-06.txt

Franziskus Kiefer <franziskuskiefer@gmail.com> Tue, 29 November 2022 13:47 UTC

Return-Path: <franziskuskiefer@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AA2C1522D7 for <cfrg@ietfa.amsl.com>; Tue, 29 Nov 2022 05:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFmbJ61SpOZ3 for <cfrg@ietfa.amsl.com>; Tue, 29 Nov 2022 05:47:52 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B0BC14CE59 for <cfrg@ietf.org>; Tue, 29 Nov 2022 05:47:52 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id g10so13434564plo.11 for <cfrg@ietf.org>; Tue, 29 Nov 2022 05:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=fRdrESkm8IKbXgGSHvhFe4s7/H2vexwVbyphBxtx3tA=; b=K9MBNcyHIEHFRrqdJu3rqx0cpTW2kbU+ie7ThHqIBWzYnzK6241EpXz83Ps21cUj/X wv/Re7obcyqZFsLq3k7NEjZgb/ui/IxeOpWa2uSaZeGcPVRIwhmtBSMFrH54wUqLAZ64 z7I1mkpprO6ba7NQBhmjOz1lMqW8yRE2UJ6uKc/863YT4ateLX07HJlQSGwogePil2eV Lroz2MLtRVaEgNnFp4LpOI7GAX3hmt5dDe3cOWMypYnq83sViu8Xe5udtzClaKtUB4QF FOEfpdxFKjPQolaxR/gge1YcEoYAvYzqScb8E6LhnBgSxqjFOTy79UwYo/KN1lr3RecN bXUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fRdrESkm8IKbXgGSHvhFe4s7/H2vexwVbyphBxtx3tA=; b=oIlJMCk3daE7Nzb4msUrjsG7waSwpNu0ABZ/Vqu7bVK0FFzxcgwIX9kju/oolVCFNK M0mZFPHUENVK5sLkccC+1B6Zuluyp+hzeolM76YhQx3ODYbJw50YgqGKSqfRX7H2rvXJ eek03D+L5YxBNPQRPZa7KcdwZf66WN9MP1w8WseLKrReU/+AY5SBy3k7Q3mJHDYWRkgs 1q2AAODOmIUsFBUToW4bRUOTauO3L9e82VJaHho7scTBPQJZSULeob5ZZoM0gmEDgLkv y2Ba36vhhshEzTo+yeq8wI9hbuMn6SRIpnscdbdQxV45AyC1Y3qER/ucncPT0fHFO5Az jEyw==
X-Gm-Message-State: ANoB5pnxOKZRlo+RcI2h/Z6/23SG5zRlkxkht0ses1QNP0MjOvzQOibM mIn9tc9jsLRZIWJGTPLp67DN+bKlfLCDrHfUAVlnfMSKouw=
X-Google-Smtp-Source: AA0mqf4NxvH50lpqFUNK5vF4/1z4MaqqxJ50RpepuQdZ8giwTGBbbYVmSHjLfspDYqGATxXlEdIGh65A2HOUCmwEZ1g=
X-Received: by 2002:a17:902:cf4b:b0:186:7a1d:b6ee with SMTP id e11-20020a170902cf4b00b001867a1db6eemr42709147plg.67.1669729671559; Tue, 29 Nov 2022 05:47:51 -0800 (PST)
MIME-Version: 1.0
References: <166906886082.62494.8820552099363522855@ietfa.amsl.com> <6A1E08FD-09CF-4929-94DD-8B7A8E6CACBA@heapingbits.net> <CAMmp5CAt-A+qJTDbhwj14b24DUGD+xzxrbBpPGM2hCYfNVA4-w@mail.gmail.com>
In-Reply-To: <CAMmp5CAt-A+qJTDbhwj14b24DUGD+xzxrbBpPGM2hCYfNVA4-w@mail.gmail.com>
From: Franziskus Kiefer <franziskuskiefer@gmail.com>
Date: Tue, 29 Nov 2022 13:47:40 +0000
Message-ID: <CAJowLmN8CZRS9V0N5tW=XohC9QNYRE-FpMe=errGSETAq7WT1w@mail.gmail.com>
To: cfrg@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f1c0ca05ee9c3b8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/oX2ysosCkRihsAjfOFh_9Znt8XA>
Subject: Re: [CFRG] I-D Action: draft-irtf-cfrg-rsa-blind-signatures-06.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2022 13:47:56 -0000

Chris asked me to review the draft.
Apologies if some items were discussed already, I didn't follow the
discussion closely.

The draft looks good to me. I only found some minor editorial issues.
I also addressed a few issues here
https://github.com/cfrg/draft-irtf-cfrg-blind-signatures/pull/154.

Section 3.
random_integer_uniform: The use of boundaries M <= R < N confused me a
little. Not thoroughly reading this section and then generating r =
random_integer_uniform(1, n) I can see that someone might implement this
as  M <= R <= N. But maybe that's just me.

Section 4.1
Errors: The RSAVP1 can throw an error that is not mentioned here. It can't
actually be thrown because of the way the input (r) is defined. But
mentioning that the error can't be raised might be useful.

Section 4.2
I wonder if the error handling here makes sense. RSASP1 checks the
following: "If the message representative m is not between 0 and n - 1,
output "message representative out of range" and stop."
This makes steps 1 and 3 unnecessary unless I'm missing something.
Consistently raising errors from the functions called from RFC 8017 in all
these sections would be nice so implementers know how to handle them.

Section 5 comes a little out of the blue without explanation why this is
here and who should use it. Would it make sense to either have this as an
optional step in section 4 or move it to section 6 where it is used?

Section 8 (last paragraph)
The draft states that PSS with a zero salt is equivalent to FDH such that
the results from BNPS03 apply. But it doesn't say what security to expect
from the salted version. Is there anything that could be said here?

Appendix A
Most values are encoded as "hexadecimal string" but some are prefixed with
0x and others are not. To make it easier for applications to use the test
vectors a consistent encoding would be nice.

Best,
Franziskus

On Fri, 25 Nov 2022 at 18:16, Scott Hendrickson <scott@shendrickson.com>
wrote:

> As promised in the adoption call, I've reviewed the document. It looks
> good to me, with a few notes provided below.
>
> I've sent one editorial nit in
> https://github.com/cfrg/draft-irtf-cfrg-blind-signatures/pull/152
>
> Section 1
>  - Consider citing the voting [1] and authentication (maybe the g1vpn
> whitepaper [2] or private relay explainer [3] examples). It may feel like
> over-embellishment from our perspective, but someone reading this may not
> have the same context building systems like this as the authors do. I
> appreciate the review of other blind signing alternatives later on for the
> same reason.
>
> Section 3
>  - In the description of random_integer_uniform(M, N), cryptographic
> security isn't mentioned, but is mentioned for random(n). Should this
> mention that the random source needs to be cryptographically secure?
>
> Section 4.1
>  - All RSABSSA variants from Section 6 appear to use SHA-384 as the hash
> function, and MGF1. Should we indicate hash and mgf as parameters if they
> are held constant? I see that they are options in RFC8017, but if they are
> held constant in the RSABSSA uses, I'd avoid listing them as options until
> they need to vary.
>
> Section 4.2
>  -  [editorial pr] blinded_msg, encoded and blinded message to be signed,
> an byte string -> *a* byte string
>
> Section 4.3
>  - Same notes on hash and MGF1 from 4.1 feedback
>
> Section 5
>  - Should this section be placed before section 4, so this reads in order?
> Randomize, blind, etc
>  - Consider defining ||
>
> Best,
> Scott
>
> On Mon, Nov 21, 2022 at 6:06 PM Christopher Wood <caw@heapingbits.net>
> wrote:
>
>> This version of the document incorporates feedback received thus far in
>> the RGLC. The primary change is the introduction of named variants to
>> replace the old API guidance text. It’s our hope that these address the
>> concerns raised by others and would greatly appreciate confirmation one way
>> or another.
>>
>> Best,
>> Chris, for the editors
>>
>> > On Nov 21, 2022, at 5:14 PM, internet-drafts@ietf.org wrote:
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Crypto Forum RG of the IRTF.
>> >
>> >        Title           : RSA Blind Signatures
>> >        Authors         : Frank Denis
>> >                          Frederic Jacobs
>> >                          Christopher A. Wood
>> >  Filename        : draft-irtf-cfrg-rsa-blind-signatures-06.txt
>> >  Pages           : 31
>> >  Date            : 2022-11-21
>> >
>> > Abstract:
>> >   This document specifies an RSA-based blind signature protocol.  RSA
>> >   blind signatures were first introduced by Chaum for untraceable
>> >   payments [Chaum83].  It extends RSA-PSS encoding specified in
>> >   [RFC8017] to enable blind signature support.
>> >
>> > Discussion Venues
>> >
>> >   This note is to be removed before publishing as an RFC.
>> >
>> >   Source for this draft and an issue tracker can be found at
>> >   https://github.com/chris-wood/draft-wood-cfrg-blind-signatures.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-blind-signatures/
>> >
>> > There is also an HTML version available at:
>> >
>> https://www.ietf.org/archive/id/draft-irtf-cfrg-rsa-blind-signatures-06.html
>> >
>> > A diff from the previous version is available at:
>> >
>> https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-rsa-blind-signatures-06
>> >
>> >
>> > Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>> >
>> >
>> > _______________________________________________
>> > CFRG mailing list
>> > CFRG@irtf.org
>> > https://www.irtf.org/mailman/listinfo/cfrg
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>