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

[Joachim Strömbergson <[e-mail]>]

Aloha!

Sorry for a late answer.

On 2013-02-15 14:34 , David McGrew (mcgrew) wrote:
> 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 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

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