[Cfrg] Topics for hash-based signatures (draft-huelsing-cfrg-hash-sig-xmss) for Friday

"A. Huelsing" <ietf@huelsing.net> Thu, 07 April 2016 13:39 UTC

Return-Path: <ietf@huelsing.net>
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 1A4A412D1B9 for <cfrg@ietfa.amsl.com>; Thu, 7 Apr 2016 06:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 GXp3jqQzuRfi for <cfrg@ietfa.amsl.com>; Thu, 7 Apr 2016 06:39:41 -0700 (PDT)
Received: from www363.your-server.de (www363.your-server.de [78.46.179.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA0712D1AC for <cfrg@irtf.org>; Thu, 7 Apr 2016 06:39:39 -0700 (PDT)
Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by www363.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from <ietf@huelsing.net>) id 1aoA9o-00080S-Gv for cfrg@irtf.org; Thu, 07 Apr 2016 15:39:36 +0200
Received: from [131.155.70.178] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <ietf@huelsing.net>) id 1aoA9n-0003K9-Qt for cfrg@irtf.org; Thu, 07 Apr 2016 15:39:35 +0200
To: "cfrg@irtf.org" <cfrg@irtf.org>
From: "A. Huelsing" <ietf@huelsing.net>
Message-ID: <57066319.5050606@huelsing.net>
Date: Thu, 07 Apr 2016 15:39:37 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------020108030904010904040206"
X-Authenticated-Sender: ietf@huelsing.net
X-Virus-Scanned: Clear (ClamAV 0.99/21486/Tue Apr 5 22:19:10 2016)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/0BNfLUOBHaGcE_DxtHSWwwuUovM>
Subject: [Cfrg] Topics for hash-based signatures (draft-huelsing-cfrg-hash-sig-xmss) for Friday
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Thu, 07 Apr 2016 13:39:44 -0000

Hi,
in preparation for Friday we want to point you at the topics we'd like
to discuss.

1. Instantiation aka choice of hash function
-------------------------------------------------------
This was already briefly discussed on the list and we got some further
direct feedback on this.
We think the important parameter set is for 256 bit classical / 128 bit
quantum security.
Currently this is implemented using SHA2-256 for everything besides the
PRG which uses ChaCha20.
Besides, the draft proposes a 512 bit classical / 256 bit quantum secure
implementation using SHA2-512.

The main comments we got were
1. Why no SHA3
2. Why no plain SHA2 implementation (code size)

As we do not want to blow up the number of possibilities, our proposal
would be

1.) Plain SHA2-256 implementation as mandatory
2.) SHA2-512 optional
3.) SHA3-(256/512) optional


2. Addresses
------------------
We simplified the address format in the last version such that fields do
not cross byte boundaries.
However, this leaves not enough space for large tree indices. Currently,
the address format only
supports tree indices up to 40 bit. Preventing parameters with e.g. 12
layers of trees of height 5
as used in SPHINCS.

We suggest to increase the address size to 32 byte. This is another
motivation to remove the SHA2/ChaCha implementation
as this was not possible with ChaCha20 because nonce + counter just give
us 16 byte.


3. Randomness for message hash
---------------------------------------------
According to the current draft R = PRF(SK_PRF, M),
i.e. the randomness is obtained, applying a PRF to the message,
keyed with a dedicated secret key. The reason is that this is a common
way to derandomize this step.

However, as XMSS is stateful anyway, we could just do
R = PRF(SK_PRF, idx)
using the idx of the used one-time key pair. For long messages this prevents
processing the message twice.

--------------------------------------------

Any feedback also before the meeting tomorrow is welcome.

Andreas