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.
I don't understand this request. Could you be specific? EDE2 is
clearly a >subset of EDE3. If one user had EDE2 hardware and was
talking to an EDE3 >user, the EDE2 user could send (k1,k2,k1) as the
key. However, the EDE3 >user would still send (k1,k2,k3).
My request is not related to the syntax issues, which are, as you point
out, proper subset questions, but rather to the accompanying standard
which may require full (pseudo)random generation of all 168 bits of EDE3
as opposed to the 112 independent bits in EDE2.
- -
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.
Are you suggesting that someone may want to use those EDE chips rather
than software DES for PEM?
Right on! and for several reasons (eg. security perimeters)
- -
As I have stated before, most standards in business and banking insist
that the IV be sent encrypted.
What does any standard say about the number of IV's for chained DES
(EDE2 or EDE3)?
The EDE standards currently only address ECB mode and none of the
chained modes that are in discussion here. The chained modes that
required encrypted IV's are only used with single key DES. I know of no
chained EDE standard.
- -
If someone were to decrypt an EDE3 message through single-DES hardware
or >EDE2 in single-DES mode, it would be maximally convenient to have
the chip >run in CBC mode for each pass and therefore to have an
individual IV for >each pass.
I know of no hardware which will chain and triple encrypt.
- -
You've been a fan of encrypting Iv's in several messages. >Could you
provide an explanation of why this would be an important >feature, in
the context of PEM? The general "rules of thumb" under >which
cryptoalgorithms have been evaluated for some time (and which >Diffie
and Hellman described in publications about 15 years ago), >assume that
a good algorithm should be resistant to attack even in the >face of
known of chosen plaintext.
Please distinguish between an attempt by academics to evaluate good
algorithms by making simplifying assumptions, and the real-world
question of "Is one approach significantly more efficacious than some
other approach?" As you point out the question can only be answered in
the context of PEM (or some other real-world encryption problem.)
- -
Thus, the observation that data at >the beginning of an encrypted
message may be highly predictable is >generally regarded as not an
especially serious concern (relative to >recovery of the encryption
key). The thrust of the arguments being >made seems to be that we
should encrypt the IV to provide more >protection for the first block of
plaintext being enciphered vs. layer >blocks (since the IV for a later
block is just the preceding >ciphertext block). If one can identify
highly predictable data in the >second or third block, this argument for
enciphering the IV becomes >obviously silly. I would suggest that the
likelihood of such >predictable data in subsequent (8-byte) blocks is
increasing all the >time, e.g., as a result of PEM-MIME formats, and
thus any benefits of >associated with encrypting the IV are too minor to
warrant the effort.
Note that from a practical point (not from that of a theoretical
"how-good-is-this-algorithm" point), if the first 8 bytes of subsequent
messages were always identical, (and protected by good encrypted IV's)
then 1) if the next 8 bytes were also identical we would have a known-
plaintext attack on one block of data, but 2) if the next 8 bytes
differed by 1 bit between subsequent messages, the known-plaintext
attack would suffer a work factor increase of 100% and 3) if the next 8
bytes differed by 2 bits, the known-plaintext attack would increase in
work factor by 300% (and so on.)
This does not seem "too minor to warrant the effort."
Tom Jones - ViaCrypt div. of Lemcom Sys dockmaster.ncsc.mil