Subject: Re: PEM WG Meeting Minutes
Date: Fri, 16 Jul 93 14:46:35 +0100
From: Mike Roe <Michael(_dot_)Roe(_at_)cl(_dot_)cam(_dot_)ac(_dot_)uk>
Message-Id: <"swan.cl.cam.:267590:930716134658"@cl.cam.ac.uk>
I didn't present any performance figures at the meeting. However, I've just
run some timings on a Sparc ELC, and the results are as follows:
Mode Throughput (Kbits/s)
==== ==========
ECB 164
CBC 156
EDE 92
EDE-CBC 90
CBC-EDE 51
Notice that 'CBC-EDE' mode (which we all agree is in principle faster
if you're using 3 DES chips in parallel) is the slowest with these
particular sofware implementations.
These results are *very* strange. They are opposite to the results which I
get with the Stratus DES code (which has a CBC function optimized to
operate over a block of inputs).
If it matters to anyone, I'll run throughput experiments on the Stratus
code and publish numbers, but this afternoon I have a design review to
attend (one of my designs, so I can't miss it).
These figures are somewhat unfair to CBC-EDE mode, as if I'd put more work
into optimising this mode it would run faster. With a few additional
implementation tricks, CBC-EDE mode would have comparable performance to
EDE-CBC.
For the Stratus code, CBC-EDE is clearly faster than EDE-CBC -- film at 11.
:-)
On the basis of the above numbers, CBC-EDE mode could be rejected as both
having doubtful security *and* having the worst performance.
The security is *not* doubtful -- merely not defended because nobody has
asked before. There is no case against it on technical grounds and I'm
willing to bet that there can never be.
Based on the numbers given above, there is a performance case, but those
numbers are very strange.
- Carl