Subject: [Cfrg] IPR and algorithms (was Re: Results of the poll: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd))

From: Watson Ladd <[email-masked]>
Date: Thu, 5 Mar 2015 18:59:17 -0800

On Mar 5, 2015 3:55 PM, "Benjamin Black" <[email-masked]> wrote:
>
> As you say, it would be equally a problem for every curve, which was my argument repeatedly rejected by Alyssa and Robert. As they have never made a statement, public or private, of which I am aware withdrawing their assertions, I can only assume they still believe what they said. If they would like to pipe up and explain that they no longer hold those views that'd be swell.

The above ignores the substantial differences between original NUMS
and the proposals made last fall, and between curves and algorithms.
The original NUMS presentation placed a great deal of importance on
the specific algorithms discussed, and it was very clear that these
algorithms were the ones that the NUMS group wanted specified.

It's a moot point when deciding : there are plenty of comb variations
that are not patented. But were we to have turned the NUMS proposal
into an RFC containing the algorithms presented, it would have been a
problem. I really don't see why we're wasting words on this debate:
Ed448 won out for other reason.

Sincerely,
Watson Ladd

>
> I cannot comment on Microsoft as I am no longer there.
>
>
> On Thu, Mar 5, 2015 at 3:41 PM, Michael Hamburg <[email-masked]> wrote:
>>
>> Hi Benjamin,
>>
>> Robert Ransom was concerned about Microsoft’s paper and code release possibly containing material based on the patent US7602907.  This wasn’t particularly to do with the curve, but with the combs algorithm for fast fixed-point multiplications.  If this is a problem with any curve, it’s equally a problem for (implementations of) every curve.  I believe that Robert was motivated in this pursuit by a deep-seated conviction that Microsoft was trying to pull something shady, but Alyssa and I just want to make sure that the patent landscape is clear so that nobody infringes by accident.
>>
>> Since my code uses signed all-bits set combs, and if I understand correctly your patent specifically covers modified LSB-set combs, I don’t believe that my implementation has patent problems.  Again, this is a property of the implementation and not of the curve.
>>
>> I asked if you and/or the Microsoft legal team concurred with this analysis.  You said that your team was unaware of the patent and didn’t use it intentionally, but that you would ask legal if it happened to be covered, and whether they thought the Goldilocks code might be affected.  Nearly 6 months have passed and we haven’t heard anything from legal.  Do you have an update for us?
>>
>> Cheers,
>> — Mike
>>
>>> On Mar 5, 2015, at 3:22 PM, Benjamin Black <[email-masked]> wrote:
>>>
>>> What happened to the earlier, vigorous arguments by Robert Ransom, Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the curves based on large primes, would be covered by Microsoft IP?
>>>
>>> On Thu, Mar 5, 2015 at 3:11 PM, Alexey Melnikov <[email-masked]> wrote:
>>>>
>>>> On 25/02/2015 14:27, Alexey Melnikov wrote:
>>>>>
>>>>> CFRG chairs are starting another poll:
>>>>>
>>>>> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable" or "no") for each curve specified below:
>>>>>
>>>>> 1) 448 (Goldilocks)
>>>>> 2) 480
>>>>> 3) 521
>>>>> 4) other curve (please name another curve that you "prefer" or "accept", or state "no")
>>>>
>>>> Thank you for all responses.
>>>>
>>>> 521 - 6 preferred, 14 - acceptable
>>>> 448 - 16 preferred, 4 - acceptable
>>>>
>>>> Very few prefer others (512 NUMS, 480).
>>>>
>>>> So CFRG prefers curve 448.
>>>>>
>>>>>
>>>>> If you stated your curve preferences in the poll that ended on February 23rd (see the attachment), you don't need to reply to this poll, your opinion is already recorded. But please double check what chairs recorded (see the attachment).
>>>>>
>>>>> If you changed your mind or only answered the question about performance versa memory usage for curves 512 and 521, feel free to reply.
>>>>>
>>>>> Once this issues is settled, we will be discussing (in no particular order. Chairs reserve the right to add additional questions) implementation specifics and coordinate systems for Diffie-Hellman. We will then make decisions on signature schemes. Please don't discuss any of these future topics at this time.
>>>>
>>>>
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>>[email-masked]
>>>>http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>>[email-masked]
>>>http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>
>
> _______________________________________________
> Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg
>

As you say, it would be equally a problem for every curve, which was
my argument repeatedly rejected by Alyssa and Robert. As they have
never made a statement, public or private, of which I am aware
withdrawing their assertions, I can only assume they still believe
what they said. If they would like to pipe up and explain that they no
longer hold those views that'd be swell.

I cannot comment on Microsoft as I am no longer there.

As you say, it would be equally a problem for every curve, which was
my argument repeatedly rejected by Alyssa and Robert. As they have
never made a statement, public or private, of which I am aware
withdrawing their assertions, I can only assume they still believe
what they said. If they would like to pipe up and explain that they no
longer hold those views that'd be swell.

I cannot comment on Microsoft as I am no longer there.

On Thu, Mar 5, 2015 at 3:41 PM, Michael Hamburg <[email-masked]> wrote:
>
> Hi Benjamin,
>
> Robert Ransom was concerned about Microsoft’s paper and code release possibly containing material based on the patent US7602907.  This wasn’t particularly to do with the curve, but with the combs algorithm for fast fixed-point multiplications.  If this is a problem with any curve, it’s equally a problem for (implementations of) every curve.  I believe that Robert was motivated in this pursuit by a deep-seated conviction that Microsoft was trying to pull something shady, but Alyssa and I just want to make sure that the patent landscape is clear so that nobody infringes by accident.
>
> Since my code uses signed all-bits set combs, and if I understand correctly your patent specifically covers modified LSB-set combs, I don’t believe that my implementation has patent problems.  Again, this is a property of the implementation and not of the curve.
>
> I asked if you and/or the Microsoft legal team concurred with this analysis.  You said that your team was unaware of the patent and didn’t use it intentionally, but that you would ask legal if it happened to be covered, and whether they thought the Goldilocks code might be affected.  Nearly 6 months have passed and we haven’t heard anything from legal.  Do you have an update for us?
>
> Cheers,
> — Mike
>
> On Mar 5, 2015, at 3:22 PM, Benjamin Black <[email-masked]> wrote:
>
> What happened to the earlier, vigorous arguments by Robert Ransom, Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the curves based on large primes, would be covered by Microsoft IP?
>
> On Thu, Mar 5, 2015 at 3:11 PM, Alexey Melnikov <[email-masked]> wrote:
>>
>> On 25/02/2015 14:27, Alexey Melnikov wrote:
>>>
>>> CFRG chairs are starting another poll:
>>>
>>> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable" or "no") for each curve specified below:
>>>
>>> 1) 448 (Goldilocks)
>>> 2) 480
>>> 3) 521
>>> 4) other curve (please name another curve that you "prefer" or "accept", or state "no")
>>
>> Thank you for all responses.
>>
>> 521 - 6 preferred, 14 - acceptable
>> 448 - 16 preferred, 4 - acceptable
>>
>> Very few prefer others (512 NUMS, 480).
>>
>> So CFRG prefers curve 448.
>>>
>>>
>>> If you stated your curve preferences in the poll that ended on February 23rd (see the attachment), you don't need to reply to this poll, your opinion is already recorded. But please double check what chairs recorded (see the attachment).
>>>
>>> If you changed your mind or only answered the question about performance versa memory usage for curves 512 and 521, feel free to reply.
>>>
>>> Once this issues is settled, we will be discussing (in no particular order. Chairs reserve the right to add additional questions) implementation specifics and coordinate systems for Diffie-Hellman. We will then make decisions on signature schemes. Please don't discuss any of these future topics at this time.
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [email-masked]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>

_______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: Benjamin Black <[email-masked]>
Date: Thu, 5 Mar 2015 19:07:12 -0800

There were serious claims made against us based on the assertion that there
were techniques, specifically those described in the '907 patent, which
were _required_ for efficient implementation. These assertions were then
used to claim that we were attempting to bamboozle CFRG into some sort of
patent troll trap. I bring this up now exactly because Ed448 has been
selected. That selection makes clear the prior assertions about us were
false and those who made the false claims should own up.

On Thu, Mar 5, 2015 at 6:59 PM, Watson Ladd <[email-masked]> wrote:

> > As you say, it would be equally a problem for every curve, which was my
> argument repeatedly rejected by Alyssa and Robert. As they have never made
> a statement, public or private, of which I am aware withdrawing their
> assertions, I can only assume they still believe what they said. If they
> would like to pipe up and explain that they no longer hold those views
> that'd be swell.
>
> >> Robert Ransom was concerned about Microsoft’s paper and code release
> possibly containing material based on the patent US7602907.  This wasn’t
> particularly to do with the curve, but with the combs algorithm for fast
> fixed-point multiplications.  If this is a problem with any curve, it’s
> equally a problem for (implementations of) every curve.  I believe that
> Robert was motivated in this pursuit by a deep-seated conviction that
> Microsoft was trying to pull something shady, but Alyssa and I just want to
> make sure that the patent landscape is clear so that nobody infringes by
> accident.
> >>
> >> Since my code uses signed all-bits set combs, and if I understand
> correctly your patent specifically covers modified LSB-set combs, I don’t
> believe that my implementation has patent problems.  Again, this is a
> property of the implementation and not of the curve.
> >>
> >> I asked if you and/or the Microsoft legal team concurred with this
> analysis.  You said that your team was unaware of the patent and didn’t use
> it intentionally, but that you would ask legal if it happened to be
> covered, and whether they thought the Goldilocks code might be affected.
> Nearly 6 months have passed and we haven’t heard anything from legal.  Do
> you have an update for us?
> >>
> >> Cheers,
> >> — Mike
> >>
> >>> What happened to the earlier, vigorous arguments by Robert Ransom,
> Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the
> curves based on large primes, would be covered by Microsoft IP?
> >>>
> >>>>> Q3: This is a Quaker poll (please answer one of "preferred",
> "acceptable" or "no") for each curve specified below:
> >>>>>
> >>>>> 1) 448 (Goldilocks)
> >>>>> 2) 480
> >>>>> 3) 521
> >>>>> If you stated your curve preferences in the poll that ended on
> February 23rd (see the attachment), you don't need to reply to this poll,
> your opinion is already recorded. But please double check what chairs
> recorded (see the attachment).
> >>>>>
> >>>>> If you changed your mind or only answered the question about
> performance versa memory usage for curves 512 and 521, feel free to reply.
> >>>>>
> >>>>> Once this issues is settled, we will be discussing (in no particular
> order. Chairs reserve the right to add additional questions) implementation
> specifics and coordinate systems for Diffie-Hellman. We will then make
> decisions on signature schemes. Please don't discuss any of these future
> topics at this time.
> >>>>
> >>>>
> > Robert Ransom was concerned about Microsoft’s paper and code release
> possibly containing material based on the patent US7602907.  This wasn’t
> particularly to do with the curve, but with the combs algorithm for fast
> fixed-point multiplications.  If this is a problem with any curve, it’s
> equally a problem for (implementations of) every curve.  I believe that
> Robert was motivated in this pursuit by a deep-seated conviction that
> Microsoft was trying to pull something shady, but Alyssa and I just want to
> make sure that the patent landscape is clear so that nobody infringes by
> accident.
> >
> > Since my code uses signed all-bits set combs, and if I understand
> correctly your patent specifically covers modified LSB-set combs, I don’t
> believe that my implementation has patent problems.  Again, this is a
> property of the implementation and not of the curve.
> >
> > I asked if you and/or the Microsoft legal team concurred with this
> analysis.  You said that your team was unaware of the patent and didn’t use
> it intentionally, but that you would ask legal if it happened to be
> covered, and whether they thought the Goldilocks code might be affected.
> Nearly 6 months have passed and we haven’t heard anything from legal.  Do
> you have an update for us?
> >
> > Cheers,
> > — Mike
> >
> > What happened to the earlier, vigorous arguments by Robert Ransom,
> Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the
> curves based on large primes, would be covered by Microsoft IP?
> >
> >>> Q3: This is a Quaker poll (please answer one of "preferred",
> "acceptable" or "no") for each curve specified below:
> >>>
> >>> 1) 448 (Goldilocks)
> >>> 2) 480
> >>> 3) 521
> >>> If you stated your curve preferences in the poll that ended on
> February 23rd (see the attachment), you don't need to reply to this poll,
> your opinion is already recorded. But please double check what chairs
> recorded (see the attachment).
> >>>
> >>> If you changed your mind or only answered the question about
> performance versa memory usage for curves 512 and 521, feel free to reply.
> >>>
> >>> Once this issues is settled, we will be discussing (in no particular
> order. Chairs reserve the right to add additional questions) implementation
> specifics and coordinate systems for Diffie-Hellman. We will then make
> decisions on signature schemes. Please don't discuss any of these future
> topics at this time.
> >>
> >>

---

From: Harry Halpin <[email-masked]>
Date: Fri, 06 Mar 2015 04:33:57 +0100

> Ed448 won out for other reason.

Although I am not a lawyer, I think possible patents are an issue that
can be solved and should not prevent CFRG from making the *technically*
correct choice.

As stated before, *if* CFRG clearly recommends elliptic curves to IETF
TLS and W3C WebCrypto, the W3C WebCrypto WG will specify in either the
body of the main W3C WebCrypto Recommendation or (depending on timing of
CFRG recommendation) in other Recommendation-track drafts the curves
once the implementers decide they are mature.

Given patent agreements already exist from Microsoft, IBM, and many
other large companies in the W3C, we would believe that any patents on
the particular implementations of these curves would be available under
a W3C royalty-free license, and any challenges by patent trolls would
have to cope with W3C's patent policy.

    cheers,
       harry