However, I think Mark's question is more directed toward >finding what
is the "standard" way of doing triple encryption, >and there is no
standard, at least that I am aware of. If I >were implementing it, I
would probably do EDE since that >has been proposed as allowing easier
compatibility with >single encryption: merely set K1=K2=K3.
The Banking Industry (ABA & ANSI X9) do use EDE2 as a standard for key
distribution. If you decide to use EDE3, please write the standard such
that 112 bits only must be securely chosen, then the EDE2 will satisfy
the EDE3 proposal. Our company is writing an API which supports EDE2
and not EDE3. Also chips are now available which do EDE encryption
directly, so EEE is not a viable commercial option. If anyone here
cares about commercial products, they will opt for EDE2 over EDE3.
I would advocate having three feedback paths, three IVs and encrypting
them >along with the three keys. I know that current practice is to
give the >single IV in the clear (whose suggestion was this?) and that
after the 1st >8 bytes, the IV is immaterial -- but 3 IVs cover the
first 24 bytes of >message, enough to cover the low entropy start of the
output of a decent >compression algorithm. [I know that we're not
compressing today but that >doesn't mean we never will, I hope (on
performance grounds, not merely on >security grounds).]
As I have stated before, most standards in business and banking insist
that the IV be sent encrypted. Note that in the case where the start of
the message is most likely not to vary from one message to the next, but
variability starts prior to the sixteenth byte (not the eighth), that
security IS IMPROVED with encrypted IV's.
Tom Jones - Lemcom Systems, Inc dockmaster.ncsc.mil