Re: [Cfrg] Patents and the new elliptic curves

[Benjamin Black <[e-mail]>]

Mike,

Thanks for clarifying. I think there might be another misunderstanding,
though. I, personally, don't make a habit of reading patents. I,
personally, won't do a patent search to try to answer your concerns. That
is entirely reasonable and consistent for the reasons I, and others, have
explained. Those responsible for doing such reading and searching are doing
so in the context of '907, as you have known since that review started.
That is the opposite of steadfast refusal to help and why I take issue with
your comments.

However, that approach is cumbersome and slow. We are continuing to discuss
internally how best to eliminate IPR concerns in ways that are simple to
understand, simple to implement, and simple for all participants here to
apply equally. When we have something to propose on that front we will
share it here.


b


On Tue, Sep 16, 2014 at 4:30 PM, Michael Hamburg <[e-mail]> wrote:

> Hi b,
>
> I’m sorry that email.  I should have phrased this less aggressively, and I
> should also have mentioned that you have asked legal to review US7602907.
>  However, that review will answer at most one of the questions I asked, and
> you have resolutely refused to help with the others.
>
> Please understand that my goal here isn’t to bash Microsoft or its NUMS
> proposal, but to make sure that new curves can be efficiently implemented
> in a way that avoids the patent minefield.  To do that, we need to know
> where the mines are.
>
> I expect (though I am not sure) that any patents that may turn up will not
> affect which curves should be chosen, either because they can be worked
> around or because they apply equally to all curves.  However, it is likely
> that patents will influence protocols and internal algorithms, and perhaps
> also things coordinate choice or point encoding.  Conceivably the result
> could be relevant to the Montgomery vs Edwards discussion, particularly if
> there is no IPR-free version of the comb algorithm.
>
> To my knowledge, there are exactly two open-source implementations
> available of the newer (i.e. non-25519) curves: Goldilocks and NUMS.  It is
> likely that if one of those curves is chosen, those packages may be used as
> a starting point in TLS libraries.  It is therefore necessary to determine
> whether they are patent encumbered, and how.
>
> The Apache2 license grant is very helpful, but as you are aware it is not
> sufficient for this purpose; we need to be able to remove any code which
> may implement patented procedures.
>
> I admit to having the less helpful MIT license on my source code.  At the
> same time, I do not believe that it implements any patented algorithms, and
> I would like to be more sure that this is true.
>
> Your accusation of hypocrisy is, of course, inaccurate.  I have spent many
> hours searching for patents which may impact elliptic curve
> implementations, because I want to make sure I and other implementers can
> create unencumbered implementations.  This is why I know about US7602907.
>
> However, I cannot claim to have combed through all possibly relevant
> patents, and I cannot claim to know that any particular technique is OK.
>  This is why I hedged my statement about searches, and why I have asked the
> CFRG for help.
>
> It is not appropriate to compare my concern that I have missed something
> with a determined ignorance of even your own company’s patents.
>
> I have additional thoughts regarding BCP 79, but I will discuss them with
> you off list first to avoid causing more trouble.
>
> Cheers,
> — Mike
>
> On Sep 16, 2014, at 3:32 PM, Benjamin Black <[e-mail]> wrote:
>
> Mike,
>
> As I explained in that formerly private discussion, we have asked for an
> internal legal review on US7602907 as we were unaware of it at the time
> the code and drafts were written. I am not in a position to comment on
> whether it is a concern, and until that review is complete there is nothing
> for anyone to confirm or deny.
>
> Large companies work this way, including that avoidance of reading patents
> to limit exposure in the event of IP litigation. While bashing Microsoft
> and its employees seems to never go out of fashion, it is not merely
> unhelpful, but counterproductive and inappropriate here. We are
> participating in this process in good faith and assume everyone else is, as
> well, even if there are points of disagreement.
>
> It does strike me as odd you are criticizing us for not doing extensive
> patent searches when you haven't done so and BCP 79 does not require it. I
> hope everyone will be held to the same standard here, whatever it is.
>
>
> b
>
>
>
> On Tue, Sep 16, 2014 at 2:56 PM, Michael Hamburg <[e-mail]>
> wrote:
>
>> Hello CFRG,
>>
>> I’m concerned about patent issues which may affect the new elliptic curve
>> standards.
>>
>> There has been a side discussion involving several members of this list,
>> including some Microsoft researchers, on the subject of what patents may
>> apply to proposed curves and their implementations and in particular to the
>> NUMS curves.
>>
>> Microsoft has a policy of avoiding patent searches, not reading patents,
>> not commenting on patents etc, so they have not been particularly helpful.
>> However, I am concerned that the Microsoft-held US7602907 (and possibly
>> foreign equivalents) may apply to their implementation, covering the mLSB
>> combs algorithm.  Benjamin Black has refused to confirm or deny this.  The
>> NUMS code itself is still usable under the Apache2 license, but it has a
>> "mutually assured destruction” clause, and other implementations might
>> infringe.
>>
>> So I have a few questions for the list.  First, am I right to be
>> concerned that US7602907 reads against the NUMS code?  How does this
>> interact with the BCP, since the curve’s spec does not require the patent,
>> but the reference implementation does?
>>
>> Second, is anyone aware of other patents that may read on
>> SafeCurves-style Montgomery or (twisted) Edwards implementations,
>> especially of the proposed curves (\w+)25519, Curve41417, MS NUMS,
>> Ed448-Goldilocks or E-521?  It is required that new curves be efficiently
>> and securely implementable without stepping on such patents, so it is
>> critical to know what they are.
>>
>> Third, given that mLSB combs may be encumbered, does anyone have
>> information on the patent status of other state-of-the-art comb
>> algorithms?  I’m particularly hoping that the signed all bits set (SABS)
>> combs algorithm used in Goldilocks is patent-free, but I have only
>> conducted a limited search.
>>
>> Thanks,
>> — Mike Hamburg
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
>