Re: [Cfrg] [irsg] IRSG review of draft-irtf-cfrg-xmss-hash-based-signatures-08

[Stephen Farrell <[e-mail]>]

Hi Andreas,

I took a look at the diff vs. -09 and all the changes
that I reckon were needed are covered nicely. I also
think that the set of changes as a whole are good
improvements, thanks.

So fwiw, I think this is ready for publication.

Cheers,
S.

PS: I'd still prefer fewer options, but we talked
about that already:-) That oughtn't delay publication
I reckon.

On 24/07/17 15:30, A. Huelsing wrote:
> 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
>