Sorry, but you're mistaking total latency for throughput by ignoring
the > pipelining of the (DES-CBC)**3 case. [The 3 DES chips, in this
case, are > operating simultaneously on 3 different 8-byte groups of
input. They can > not do so in the (DES**3)-CBC case.]
Sigh .. As in so much that passes across this board, its the unstated
assumptions that get you. Therefore I apologize for responding to a
statement in the thread without repeating all that had gone on before.
Assumptions:
1> Software is an adequate solution for privacy and for non-repudiation
if the PC it runs on is private and can be physically protected 24 hours
a day, both when operating and when off.
2> Many environments exist where viruses exist or where physical
security is inadequate to the job of protecting keys and other security
objects. In those situations, physical security of the keying material
is mandated. To prevent release of the security objects outside the
secure environment, encryption algorithms of various sorts are
implemented within the security environment.
3> Naked hardware encryption can speed up calculations, but cannot
improve security. (It may even make it worse!)
4> In order to build hardware security environments, it is necessary to
find large enuf markets to give a decent return on the investment in
engineering the product.
5> There are NO commercial markets today that will support products that
offer end-to-end (application layer) security outside of retail banking.
(And even that application only supports a single division of a single
company.) (Note that the Federal Reserve is not considered to be a
commercial market.) - I would love to hear this assumption refuted!!!
Conclusions:
If security products are to be designed today for the POTENTIAL markets
that are represented by PEM, EDI and other emergent applications, they
must be flexible enuf to handle any of the applications, not only as
practitioners view those applications today, but also as those markets
may develop in the future. This thread on EDE vs. CBC3 is a case in
point.
Single chips exist today which will do a EDE encryption IN A SINGLE
OPERATION. It turns out that this chip is also quite fast. I might
consider using such a chip in a product that I would design, due
primarily to its speed and flexibility.
Single chips exits today which will do a CBC encryption IN A SINGLE
OPERATION. I have repeatedly used such chips in multiple designs over
many years.
There are no single chips that could do a CBC*3 today, there is no
application that allows a CBC*3 today, and there is no reason to imagine
that such a three chip design for CBC*3 could be integrated into a
design that could do any other known security algorithm.
In this context, the I/O requirements of CBC*3 would three times worse
than possible with the existing EDE chip. In the case of single chip
ECB DES, then CBC*3 would be no better than EDE, assuming that the x-or
operation is nearly free.
- -
Sorry that this took so long, but I think it IS IMPORTANT that PEM (or
its derivatives) stay away from designs that are unlikely to be
implementable in real-world commercial systems.
I am designing commercial products which have PEM implementations as one
of their goals, and so have a vested interest in seeing these products'
continued value over time, I would hate to see PEM veer off in an
unexpected direction.
Peace Tom Jones - Lemcom