[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
- [Cfrg] Topics for hash-based signatures (draft-hu… A. Huelsing
- Re: [Cfrg] Topics for hash-based signatures (draf… Василий Долматов