Subject: Re: [Cfrg] RG Last Call - draft-irtf-cfrg-ocb-00

From: Phillip Rogaway <[email-masked]>
Date: Tue, 12 Feb 2013 23:27:36 -0800 (Pacific Standard Time)

Thanks everyone for comments already made on the OCB Internet Draft.

Ted asked me to answer some questions on the free licenses.  I’m not so sure that the CFRG is the ideal place for that (I’m happier when posts deal with more technical matters), but there’s been so much talk about this that I felt I better say something.

At the Real World Cryptography Workshop at Stanford last month I announced during a survey talk on authenticated encryption (AE) that my own IP in this domain would be freely licensed under broad circumstances: basically, (1) all open-source software, and (2)  any commercial, non-open-source software too, as long as it’s not for military use. See http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm for the text of these two licenses. They were drafted by volunteer legal aid kindly provided by Harvard’s Cyberlaw Clinic.  We did try to make these licenses as simple and clear as possible, but the number of reasonable questions and scenarios that can arise is enormous, I now see.

Uri asked about the situation where an entity A adds OCB to OpenSSL, and a company X comes along and drops this into their non-open-source system, which they proceed to sell to the DoD.   My answer is that company X has infringed, but OpenSSL has not, nor has company A, assuming they weren’t trying to “specifically induce” the infringing use by X.  Company X should buy a license (which is not half as big a deal as people seem to assume).

Ted mentioned to me scenarios (I think this was from a different mailing list) where Adobe adds OCB to their Reader, or where Google adds OCB to their search engine (and of course, the military use the Reader or the search engine). An attorney tells me that whether or not the vendor has infringed depends on whether or not the software or service is “in cooperation with” or “on behalf of” the military.  Allowing military use for free code or services (here, ‘free’ as in beer) is certainly possible, but I would need to explicitly expand things in that direction.

Next I heard a concern that the non-military restriction runs afoul with OSI’s “no discrimination against fields of endeavor” requirement.  This concern would seem to be misplaced for a couple of reasons. First, the license for open-source software doesn’t have the non-military language. Second, the licenses at opensource.org operate in the realm of copyright, not patents. As I understand it, the two things are independent.

Someone else on this list asked: why open-source SW but not open-source HW. The answer is that I know nothing about the latter domain. If needed, please make a specific request (by private email) and I’ll try to make sure you’re covered.

I know that some open-source projects won’t be comfortable with the IP situation surrounding AE regardless of anything I say or do.  Some other open-source projects -- eg, Mosh -- have already made the opposite decision and are using OCB (which I think is great).  Similarly, some companies will be satisfied with license 2; some may want a paid license; and some will want to avoid anything with patents.

That last thing can be hard to achieve with anything approaching certainty. Consider that, just a few weeks ago, Intel was granted a US patent (#8,340,280) for the tricks that enable their carryless multiply NI to efficiently realize GCM.  Where’s the guarantee that Intel won’t go after someone with a PCLMULDQ-based GCM implementation? Now I’m definitely not suggesting that OpenSSL rollback to a dumber GCM implementation. But troubling patent issues have become a part of our landscape. Somehow we get by.

Ted and I have worked hard to evolve the ID on OCB, this following a sequence of papers about the algorithm and its performance. We’ve made the required IP disclosures to the IETF, urged other parties to do so, and, for my part, I’ve arranged for free licenses within a large domain of practice. I do hope that all this is enough for OCB to get more widely standardized and used (and preferably without having to wait for every possible patent to expire).

Cheers,
Phillip Rogaway

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Wed, 13 Feb 2013 13:08:58 +0000

Hi Phil,

On 2/13/13 2:27 AM, "Phillip Rogaway" <[email-masked]> wrote:

>
>Consider that, just a few weeks ago, Intel was granted a US patent
>(#8,340,280) for the tricks that enable their carryless multiply NI to
>efficiently realize GCM.  Where¹s the guarantee that Intel won¹t go after
>someone with a PCLMULDQ-based GCM implementation? Now I¹m definitely not
>suggesting that OpenSSL rollback to a dumber GCM implementation. But
>troubling patent issues have become a part of our landscape. Somehow we
>get by.

Intel has released a GCM implementation that uses PCLMULDQ and granted its
use under a BSD-style license
<http://www.intel.com/p/en_US/embedded/hwsw/software/crc-license?id=6386>.
   It says:

<quote>
Copyright © 2012, Intel Corporation

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
Neither the name of the Intel Corporation nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
</quote>

Like you, I would rather be discussing technical issues, but I wanted to
pass along the relevant info to people who might be interested.

David

---

From: Ted Krovetz <[email-masked]>
Date: Wed, 13 Feb 2013 07:55:52 -0800

> use under a BSD-style license

I believe this style of license is saying that you have permission to use the code -- thus you are not violating copyright by using it. But there is no explicit patent grant from Intel in the license.

If you want to use a patented algorithm, you need both source code to execute and a grant to use the invention. This BSD-style license gives access to Intel's code, but is there a patent grant somewhere allowing us to use the invention too?

Phil's patent grant is giving lots and lots of people free use of his invention, and my OCB source code has a BSD-style license attached, allowing free use of an implementation. You really need both to use something patented.

-Ted

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 13 Feb 2013 15:33:29 -0500

Of course Intel has a ton of patents around their CPU and instruction set,
granted - including this one for doing those weird multiplications. But
who in the right mind can imagine Intel suing a software developer (not a
chip cloner!) for using an instruction from the CPU instruction set? Let's
not be ridiculous, OK?
 
The _license_ (not a copyright) quoted by David is both clear enough and
permissive enough. FUD aside, it seems painfully obvious that anybody can
write code using Intel AESNI instructions (and other IA64 instructions
too, if it matters) without legal repercussions. On top of that, Intel
allows unrestricted use of their ("highly optimized") assembly code that
implements GCM and uses AESNI instructions.

AESNI-assisted GCM is fast enough for at least some of us, and free enough
for all of us to use. OCB has legal restrictions. Call me back in 2021?

P.S. If you plan to start a company (say, Outtel :) and clone an Intel CPU
chip - then you would probably hear from Intel lawyers, and this patent
#8,340,280 could be one of the many thrown at you. :-)
--
Regards,
Uri Blumenthal
<Disclaimer>

On 2/13/13 10:55 , "Ted Krovetz" <[email-masked]> wrote:

>I believe this style of license is saying that you have permission to use
>the code -- thus you are not violating copyright by using it. But there
>is no explicit patent grant from Intel in the license.
>
>If you want to use a patented algorithm, you need both source code to
>execute and a grant to use the invention. This BSD-style license gives
>access to Intel's code, but is there a patent grant somewhere allowing us
>to use the invention too?
>
>Phil's patent grant is giving lots and lots of people free use of his
>invention, and my OCB source code has a BSD-style license attached,
>allowing free use of an implementation. You really need both to use
>something patented.
>
>-Ted
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Joachim Strömbergson <[email-masked]>
Date: Fri, 15 Feb 2013 09:01:19 +0100

Aloha!

On 2013-02-13 08:27 , Phillip Rogaway wrote:
> Someone else on this list asked: why open-source SW but not open-source
> HW. The answer is that I know nothing about the latter domain. If
> needed, please make a specific request (by private email) and I’ll try
> to make sure you’re covered.

Since I was the one asking about this: Why do you feel that you need to 
make the distinction, thereby infering a limitation? Esp if you don't 
know anything about the domain? (Fear of the unknown? ;-)

If you look at OpenCores for example you will find quite a lot of 
implementations of different cryptographic algoritms licensed under 
(L)GPL- and BSD-licenses

http://opencores.org/

OCB is IMHO very interesting for embedded systems, systems that often 
are implemented using FPGAs with soft microcontroller cores augumented 
with application specific cores for things like I/O, crypto etc. Being 
able to offload the mode processing would free the MCU to handle events 
or be less expensive. The latter being the driving force in embedded space.

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 15 Feb 2013 13:34:09 +0000

Hi Joachim,

On 2/15/13 3:01 AM, "Joachim Strömbergson" <[email-masked]>
wrote:

>> needed, please make a specific request (by private email) and I¹ll try
>> to make sure you¹re covered.
>

Thanks for providing the URL and the good suggestion to consider HW in
licensing terms.  

>or be less expensive. The latter being the driving force in embedded

What aspect of OCB do you see as interesting for embedded systems?   If an
implementation of AES encrypt and decrypt functions are available, then
the additional circuit or code size of OCB is small.   However, if you are
designing circuits (as seems to be what you are interested in) then there
are other modes that are more compact.

I'm not trying to start a debate on comparing modes, I just want to make
sure that I understand the issues that you see for embedded crypto.

Thanks,

David

---

From: Ted Krovetz <[email-masked]>
Date: Fri, 15 Feb 2013 07:11:15 -0800

> sure that I understand the issues that you see for embedded crypto.

While not addressing exactly what you're asking Joachim, a lot of system-on-a-chip implementations include an AES engine but pathetic multiplication. In such situations OCB and CCM have a big advantage over other modes because they do very little else besides AES calls.

I have one of these

  http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf

and have been meaning to implement OCB on it for a while.

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 20 Feb 2013 11:33:45 +0100

Aloha!

Sorry for a late answer.

> sure that I understand the issues that you see for embedded crypto.

Thanks for asking. There are several aspects to this and I'll try to 
explain my view.

For many embedded applications authentication and integrity protection 
is much more important than confidentiality. OCB is an interesting AEAD 
mode due to the low complexity. The cost (in HW) compared to HMAC is 
lower and gives better performance.

CCM requires about the same amount of hardware but with less 
performance. The stream cipher decoupling part (CTR) of GCM is very 
good, esp for systems with low power MCUs that communicate periodically 
and have extra RAM to spare (which quite often though is note the case). 
The Galois multiplier however is costly, and as Ted stated in his 
answer, even though your MCU contains a AES-128 engine (typically), 
multiplication is usually very weak.

When designing embedded systems, being able to choose what is 
implemented in HW and in SW respectively affects things like cost, cost, 
physical size, power consumption, cost, ability to update in the field, 
cost, time to market, cost, security, availability, cost, support, cost. 
And cost. You get the idea.

Sometimes the best solution is to build the solution around a MCU. 
Sometimes it is to use an ASIC or an FPGA and integrate a CPU core. The 
core itself might be extendable with new instructions to support, for 
example, a barrel shifter, a fast multiplier etc. Or the MCU is equipped 
with application specific hardware and coprocessors that offload the CPU 
from performing things like MAC calculations, protocol handling etc. 
This makes it possible to use a smaller CPU core, possibly removing the 
need for external RAM etc.

An example of such a CPU core is the Altera Nios II 32-bit CPU that can 
scale in performance from the size of a small 8-bit CPU to a pretty high 
perfomance CPU, all using the same ABI. And this core supports adding 
new instructions, coprocessors etc.

http://www.altera.com/devices/processor/nios2/ni2-index.html

The important thing is that if there are limits to how you partition the 
system into SW and HW, then some of the optimizations and trade offs are 
removed, which might lead to, for example, higher cost. Having an 
interesting algorithm such as OCB that for some reason only allows it to 
be implemented in SW makes the partitioning harder thereby driving cost 
and reducing the number of algorithms to choose from.

One recent algorithm that I find interesting both from a technical point 
of view and due to its non-discriminatory license is SipHash:

https://131002.net/siphash/

SipHash can be used as MAC, needs very little registers/memories which 
makes it compact to implement and use in a system. However the 64 bit 
operations requires iterative processing on a MCU, which reduces the 
performance. I have therefore developed a hardware implementation of 
SipHash and made it available under a BSD license:

https://gitorious.org/siphash_core

Using this core, even the smallest Nios II CPU core can easily do MAC 
processing on traffic at Gbps wire speed and still spend cycles on the 
local application.

What I'm getting at is that _why_ limit the use of you algorithms unless 
you really feel the need for it. Hifn, being a chip company in the RFC 
for the LZS compression and in the RFC Hifn specifically excludes 
hardware implementations:

https://tools.ietf.org/html/rfc2395

But why do this for OCB?

One other thing about algorithms and how to make them more attractive 
for system designers are how easy it is to follow the description and 
create a functionally correct implementation. Too often I see algorithm 
descriptions without examples or test vectors. Another common problem is 
that the reference code is poorly documented, don't conform to the 
written description, use variable names that are not the same as the 
written description and is generally hard to use.

It is my belief that if you are developing algorithms such as ciphers, 
MACs etc and really want your creation to be analyzed, adopted, used and 
implemented then limiting its usage with patents, licensing (including 
SW vs HW), making it hard to understand and implement is counter productive.

I therefore applaud the creators of SipHash - Jean-Philippe Aumasson and 
Daniel J. Bernstein for writing one of the algorithm descriptions I have 
read in a while.

https://131002.net/siphash/siphash.pdf

Ok, that was probably overly long.
-- 
Med vänlig hälsning, Yours