Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08
"A. Huelsing" <ietf@huelsing.net> Mon, 24 July 2017 14:30 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 80CF5131D69; Mon, 24 Jul 2017 07:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6NHrfZZ3aG-X; Mon, 24 Jul 2017 07:30:18 -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 200F3131D3D; Mon, 24 Jul 2017 07:30:17 -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 1dZeNB-0000Bv-Lb; Mon, 24 Jul 2017 16:30:13 +0200
Received: from [131.155.70.110] by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <ietf@huelsing.net>) id 1dZeNB-0004sE-4D; Mon, 24 Jul 2017 16:30:13 +0200
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Alexey Melnikov <alexey.melnikov@isode.com>, "irsg@irtf.org" <irsg@irtf.org>, "cfrg@irtf.org" <Cfrg@irtf.org>
Cc: "draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org" <draft-irtf-cfrg-xmss-hash-based-signatures@ietf.org>
References: <D4FDAF9D.8D586%kenny.paterson@rhul.ac.uk> <9a878527-5ab9-5429-7c5d-4f7e4ca4e8db@isode.com> <08944dc3-9086-ed47-cc1b-54248b3dac70@cs.tcd.ie> <D566ADE0.963E4%kenny.paterson@rhul.ac.uk> <9e6b6146-e376-86cb-70be-0127a3e72d16@cs.tcd.ie> <D56DBB2C.96A67%kenny.paterson@rhul.ac.uk> <6f90e485-01f4-5ad8-49ef-e51c52e01a46@cs.tcd.ie> <5e328e85-a8a1-67f1-3853-418309b04a17@huelsing.net> <27cc7000-7fd5-27dd-b8b5-9b9518a9f3ad@huelsing.net> <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie>
From: "A. Huelsing" <ietf@huelsing.net>
Message-ID: <4699f3d2-40ce-9c40-d29a-d24ecb3b6cab@huelsing.net>
Date: Mon, 24 Jul 2017 16:30:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1785b9ed-fb53-889a-9d34-311c7ea5c762@cs.tcd.ie>
Content-Type: multipart/mixed; boundary="------------EDA0ADC751965DA00E77AF10"
Content-Language: en-GB
X-Authenticated-Sender: ietf@huelsing.net
X-Virus-Scanned: Clear (ClamAV 0.99.2/23592/Mon Jul 24 10:18:33 2017)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/28D93ZZnznUixrj6c0aMGCyvhrk>
X-Mailman-Approved-At: Wed, 26 Jul 2017 08:07:38 -0700
Subject: Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
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: Mon, 24 Jul 2017 14:30:28 -0000
Dear Stephen, we tried to make the required changes. Please have a look if you are fine with the changes (especially regarding section 5 and the reference implementation). You find our answers to your review below and the new draft version attached. Thanks again for your time, Andreas, Aziz, Denis, Joost & Stefan ################# Answers #################### possible errors: ---------------- - 3.1.2: Algorithm 2: "if ( (i + s) > w - 1 )..." seems to be missing parenthesis around the "(w-1)" to me. Without those brackets I could interpret that test to always result in false. #Done - 4.1.9: should the call to setIdx in alg 12 be after treeSig? as-is you seem to have incremented the index too soon so that when alg 11 does getIdx it'd presumably get the incremented index and cause verification failure. I think the same is true of alg 16 as well, in section 4.2.4. #Done significant comments, but likely fixable: ----------------------------------------- - section 5: there are waaaay too many options defined here. As-is, this will damage potential deployment of xmss. I would strongly suggest deleting all of the options except the minimum, that being one (and only one) set of parameters for XMSS and one for XMSS^MT. If others are needed later, those can be defined later. (Note that the damage done here includes the hours of developer time that would be wasted debating which of these choices to implement/use. Consider the case of pre-hash variants of eddsa for an ongoing example.) #### # We significantly changed section 5, please check if this # satisfies your remarks #### - section 5 (or an appendix) should contain some test vectors (including intermediate values). Without those, implementers have a much harder time of getting their code right. # Added section on reference implementation nits, near-nits and other ignorable things: ------------------------------------------- - abstract: I'd suggest s/can withstand attacks/ can withstand so-far known attacks/ # Done - 1.1: You say if used >1 time "no cryptographic security guarantees remain." It might be clearer to give some examples of consequences, e.g. that the attacker can forge new signatures or whatever. # Done - 1.1: I think you might mention that XMSS and other OTS ideas require some new crypto APIs. I'm not aware if anyone has developed proposals for such, but would be interested if someone has. # Done - 2.3, 2nd last para: you might want to say what happens with e.g. B<<2 where B=0xf0. I assume the result is 0xc0 but someone might think it's 0x3c0 or even 0xc3. # Done: Removed the left shift as it is never used for single bytes - 2.5: having the "type word" as octet 15 of a 32 byte address seems odd. Is there a reason why? (Just wondering.) # Yes: We got the space and think that it simlifies implementation if one always has to manipulate whole words (and can treat the address as uint32_t[8]) - 2.6: It seems odd to given an example where the input and output of base_w() are the same. A different example may be more useful. (More examples generally would be great.) # Done - 3.1.3: maybe note that "/" means nothing? Which I assume it does? Better might be to just say that. # Done - 3.1.5: "a maximum value of len_1 * (w - 1) * 2^8" is missing units # Done: value -> Integer value - 3.1.5: "the variable" - which one? # Done: Added explanation - 3.1.5: "For the parameter sets given in Section 5 a 32-bit unsigned integer is sufficient." Sufficient for what? # Done: Added " to hold the checksum" - 3.1.5: The ascii art at the end of p16 doesn't help much. # while the art does not contain new information, we think it's a handy reminder. Would prefer to keep it like this. - 3.1.7: The "MUST match" statement doesn't seem enforceable nor testable so I'm not sure it's a good idea to include. OTOH, I do get the idea of using 2119 terms for emphasis. # Ok, so what should we do? I agree that key handling cannot be verified. Still, it seems necessary to emphasize this. If it is just about the use of the 2119 term, how about: "but it is crucial for security that the cryptographic strength matches that of the used WOTS+ parameters."? - 3.1.7: I think it might be useful to point out any specific problems associated with using a low entropy human memorable secret (password) for the value S. No matter what you say, people will do that, so better if you can say you told them specifically about downsides of doing that. # We adressed this in a new sentence at the end of the # paragraph. - 4.1.12: I'm not sure if the MAY there is correct or not. If it means "you MAY use a different algorithm to get the same output as alg 12" then that'd be fine. If something else is meant I'm not sure what you're saying, and it'd probably be better to not even mention it. # That is exactly what it means. There are far more efficient # algorithms to compute that output (but also far more complex) - section 5 should also spell out the signature and public key sizes in bytes and ideally, if you keep multiple options, (but please don't:-) describe relative or measured timings. # Done
- [Cfrg] IRSG review of draft-irtf-cfrg-xmss-hash-b… Paterson, Kenny
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paterson, Kenny
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Watson Ladd
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Allison Mankin
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Stephen Farrell
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paul Hoffman
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Paul Hoffman
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… Allison Mankin
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing
- Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-… A. Huelsing