[Cfrg] draft-mcgrew-hash-sigs - Examples

Jim Schaad <ietf@augustcellars.com> Wed, 06 February 2019 06:45 UTC

Return-Path: <ietf@augustcellars.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 3622C128D0C for <cfrg@ietfa.amsl.com>; Tue, 5 Feb 2019 22:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.794
X-Spam-Level:
X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acReS_eUoQ3U for <cfrg@ietfa.amsl.com>; Tue, 5 Feb 2019 22:45:40 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA10124B0C for <cfrg@irtf.org>; Tue, 5 Feb 2019 22:45:39 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Feb 2019 22:45:33 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-mcgrew-hash-sigs@ietf.org>
CC: <cfrg@irtf.org>
Date: Tue, 5 Feb 2019 22:45:29 -0800
Message-ID: <049401d4bde7$8e736810$ab5a3830$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdS94hOliscjsFPoSNOe+8an2S/iwA==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/N0Vpl4szlY7mPX6Y1RhxnnZOUxY>
Subject: [Cfrg] draft-mcgrew-hash-sigs - Examples
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Wed, 06 Feb 2019 06:45:43 -0000

I guess that the first person to try and use any test cases in a document is
always the first person to get frustrated by them.

1.  It would be nice if there was a description for what each test case
allows one to do.  I think the answer is that Test Case 1 can only be used
to test the validation code and get either a success or a failure answer.
No intermediate values to help in the event of a fail.    I think that Test
Case 2 was supposed to allow for testing both creation and validation of the
example but important information seems to be missing from the test case.

2.  Test case #2 appears to have private seeds for generating of private
keys.  However there is only a single seed and a single identifier which I
assume is for the first HSS layer.  This does not have the needed seeds to
generate the second HSS layer and the LMS layer unless you have violated the
main document by chaining the key generation across the different LMS trees.

3.  I have a confusion that I think has been brought on by Russ as part of
his CMS draft where he is using the term standalone HSS tree and I am
getting more confused by that but I think I see where that is going and why
it is not mentioned in this document.  

4.  Having a couple more introductory or intermediate examples would have
been helpful.  Thus there is an example of getting an LMS public key, but
not a case of - here is the private key and message and this is the LMOTS
signature that results - completely standalone.  (Although it could be
inferred from the second test case if the extra intermediate values
existed.)  This makes it easier to test things from the bottom up rather
than from the top down.   Given a tree private key root value, the private
key of a node at Q, the public key and a signature computed from that would
allow for the best possible set of data for testing short of a complete set
of intermediate values.

Jim