IETF Logo Mail Archive

Re: [Cfrg] RGLC on draft-irtf-cfrg-xmss-hash-based-signatures-03.txt

Gilles Van Assche <gilles.vanassche@st.com> Tue, 28 June 2016 13:25 UTC

Return-Path: <gilles.vanassche@st.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 2ADDF12DEA2 for <cfrg@ietfa.amsl.com>; Tue, 28 Jun 2016 06:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 G_tro4qhhbB8 for <cfrg@ietfa.amsl.com>; Tue, 28 Jun 2016 06:25:47 -0700 (PDT)
Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (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 BBC4A12D643 for <cfrg@irtf.org>; Tue, 28 Jun 2016 06:25:32 -0700 (PDT)
Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u5SDMPjB016124; Tue, 28 Jun 2016 15:25:21 +0200
Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 23sf359xx3-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2016 15:25:21 +0200
Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 5618538; Tue, 28 Jun 2016 13:25:19 +0000 (GMT)
Received: from Webmail-eu.st.com (safex1hubcas6.st.com [10.75.90.73]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 21718146F; Tue, 28 Jun 2016 13:25:19 +0000 (GMT)
Received: from [10.137.2.67] (10.137.2.67) by webmail-eu.st.com (10.75.90.73) with Microsoft SMTP Server id 8.3.444.0; Tue, 28 Jun 2016 15:25:18 +0200
To: Andreas Huelsing <ietf@huelsing.net>
References: <56E9B7E2.7050105@isode.com> <56EC2EAB.3080707@st.com> <3F156D2A-326B-4A05-90BF-86AD6F6278C2@vigilsec.com> <56EFCFF7.30405@huelsing.net>
From: Gilles Van Assche <gilles.vanassche@st.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <57727AC6.9090206@st.com>
Date: Tue, 28 Jun 2016 15:25:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56EFCFF7.30405@huelsing.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-28_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/tN_y3SM-jYBPi-t-VjuYuxKX1sk>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-xmss-hash-based-signatures-03.txt
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: Tue, 28 Jun 2016 13:25:49 -0000

Hi Andreas,

Thanks for adding the SHA-3 parameters to the XMSS draft.

Based on the cryptanalysis results we have seen so far, SHA-3 has a
thicker safety margin than SHA-2, so it may be an interesting option to
choose in a protocol that aims for long-term security.

Kind regards,
Gilles


On 21/03/16 11:41, A. Huelsing wrote:
> Our reasoning behind choosing SHA2 for the first parameter sets was
> based on the availability of implementations in the field. However,
> this selection is not exclusive! We even describe in the document what
> has to be done to define parameter sets based on other hash functions
> / block ciphers.
>
> I think it is a question for cfrg if we want to include parameters
> based on different hash functions in this state. I guess we can easily
> include SHA3 parameters as optional if someone provides us with a
> section describing how the different function families are
> instantiated using SHA3.
>
> Andreas
>
> […]

v2.23.0 | Report a Bug | By Email