From: rossum on
On Fri, 26 Mar 2010 13:43:58 -0700, Paul Rubin
<no.email(a)nospam.invalid> wrote:

>"Scott Fluhrer" <sfluhrer(a)ix.netcom.com> writes:
>> Actually, it's about performance, rather than to stop stupid people from
>> doing stupid things. We've come up with ways to do both encryption and
>> integrity that turn out to be cheaper than doing each one separately.
>
>Are any of those combined modes actually faster than something like
>CTR+UMAC?
GCM mode is designed to be parallelisable so it should be faster on
multi-core kit. I am not sure about other modes.

rossum

From: Scott Fluhrer on

"Paul Rubin" <no.email(a)nospam.invalid> wrote in message
news:7x39zmzucx.fsf(a)ruckus.brouhaha.com...
> "Scott Fluhrer" <sfluhrer(a)ix.netcom.com> writes:
>> Actually, it's about performance, rather than to stop stupid people from
>> doing stupid things. We've come up with ways to do both encryption and
>> integrity that turn out to be cheaper than doing each one separately.
>
> Are any of those combined modes actually faster than something like
> CTR+UMAC?

Well, it depends on the scenario (and the actual UMAC settings; it has a
number of parameters that affect performance).

In a software implementation, probably not, although it might depend on the
size of the message (CWC might come fairly close, and I believe that UMAC
doesn't do well with short messages, and so CWC might have the edge there in
some cases).

In a hardware implementation, probably (GCM is quite hardware friendly,
especially in an aggressive pipelined implementation).


In addition, these combined modes depend on one crypto primitive; CTR+UMAC
depends on two (the block cipher that CTR is based on, and the hash function
that UMAC uses); when we're using provable modes, reducing the number of
primitives we're using is a worthy goal.

--
poncho