[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes to the ciph-des-explicit-iv draft
The following changes have been made to the "ciph-des-explicit-iv"
draft.
Special thanks go to Steve Bellovin and Carlisle Adams for fielding
a flurry of last-minute questions.
I will be submitting the draft to Cynthia today.
Thx - C
================
1. Bellovin has pointed out an attack based upon using low-Hamming
distance IV values. Based on this,
(a) In section 3, changed "The IV SHOULD be chosen at random."
to "The IV MUST be a random value."
(b) Added to the section 3 implementation note:
To avoid ECB encryption of very similar plaintext blocks in
different packets, implementations MUST NOT use a counter or other
low-Hamming distance source for IVs.
(c) Added to the Security Considerations section:
The case for using random values for IVs has been refined with the
following summary provided by Steve Bellovin. Refer to [Bell97] for
further information.
"The problem arises if you use a counter as an IV, or some other
source with a low Hamming distance between successive IVs, for
encryption in CBC mode. In CBC mode, the "effective plaintext"
for an encryption is the XOR of the actual plaintext and the
ciphertext of the preceeding block. Normally, that's a random
value, which means that the effective plaintext is quite random.
That's good, because many blocks of actual plaintext don't change
very much from packet to packet, either.
For the first block of plaintext, though, the IV takes the place
of the previous block of ciphertext. If the IV doesn't differ
much from the previous IV, and the actual plaintext block doesn't
differ much from the previous packet's, then the effective
plaintext won't differ much, either. This means that you have
pairs of ciphertext blocks combined with plaintext blocks that
differ in just a few bit positions. This can be a wedge for
assorted cryptanalytic attacks."
The discussion on IVs has been updated to require that an
implementation not use a low-Hamming distance source for IVs.
(d) Added a reference to his paper.
2. To clarify the points of key size/format, made the following
changes:
(a) In section 4, first paragraph, changed the text to:
DES-CBC is a symmetric secret key algorithm. The key size is 64 bits.
[It is commonly known as a 56-bit key as the key has 56 significant
bits; the least significant bit in every byte is the parity bit.]
(b) [ESP] doesn't describe the so-called slicing-and-dicing (which
algorithm gets which chunk of the base key); the information is
contained in [arch].
(c) To clarify the "56-vs-64 bits from key engine":
This mechanism MUST derive a 64-bit key value for use by this cipher.
The mechanism will derive raw key values, the derivation process
itself is not responsible for handling parity or weak key checks.
(d) w.r.t. parity -- as there is no technical reason for a
MUST (the parity bits are ignored during key transformation and
so are really a local implementation issue instead of an
interoperability issue), removed the "MUST set parity" and added
the following:
Implementation note:
If an implementation chooses to do weak key checking, it should
recognize that the known weak keys [FIPS74] have been adjusted for
parity. Otherwise the handling of parity is a local issue.
(e) Added a statement requiring a strong PRF for key generation,
aligning this draft with the other algorithm drafts.
3. Weak keys: the bulk of the feedback here said to simply refer to
the FIPS draft. Removed the list of weak keys (although the FIPS
draft does not identity "possibly weak" keys).
4. Key Lifetime. New text:
[Blaze96] discusses the costs and key recovery time for brute force
attacks. It presents various combinations of total cost/time to
recover a key/cost per key recovered for 40-bit and 56-bit DES keys,
based on late 1995 estimates.
While a brute force search of a 56-bit DES keyspace can be considered
infeasable for the so-called casual hacker, who is simply using spare
CPU cycles or other low-cost resources, it is within reach of someone
willing to spend a bit more money.
For example, for a cost of $300,000, a 56-bit DES key can be
recovered in an average of 19 days using off-the-shelf technology and
in only 3 hours using a custom developed chip.
It should be noted that there are other attacks which can recover the
key faster, that brute force attacks are considered the "worst case",
although the easiest to implement.
[Wiener94] also discusses a $1M machine which can break a DES key in
3.5 hours (1993 estimates), using a known-plaintext attack. As
discussed in the Security Considerations section, a known plaintext
attack is reasonably likely.
It should also be noted that over time, the total and average search
costs as well as the average key recovery time will continue to drop.
While the above does not provide specific recommendations for key
lifetime, it does reinforce the point that for a given application
the desired key lifetime is dependent upon the perceived threat (an
educated guess as to the amount of resources available to the
attacker) relative to the worth of the data to be protected.
While there are no recommendations for volume-based lifetimes
made here, it shoud be noted that given sufficient volume there is an
increased probabilty that known plaintext can be accumulated.
5. Fixed references:
(a) Fixed the inconsistent spelling of Mike Wiener's name.
(b) FIPS-46-2 has superceded both FIPS-46 and FIPS-46-1.
(c) Added URL references to HTTP versions of the relevant FIPS
documents. [No more watching the printer barf on a WP5 document!]
(d) Added:
[Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP
Security Protocols", Proceedings of the Symposium on Network and
Distributed System Security, San Diego, CA, pp. 155-160, February
1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}).
[Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B.,
Shimomura, T., Thompson, E., Wiener, M., "Minimal Key Lengths
for Symmetric Ciphers to Provide Adequate Commercial Security",
currently available at
http://www.bsa.org/policy/encryption/cryptographers.html.
(e) Additional locations to find [Wiener94]:
[Reprinted in
"Practical Cryptography for Data Internetworks", W.Stallings,
editor, IEEE Computer Society Press, pp.31-79 (1996). Currently
available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]
6. Changed the contact info for Bob ;-).
--
John Kelley johnk@tis.com
Director, Systems Administration
Trusted Information Systems, Inc. (A NASDAQ company: "TISX")
http://www.tis.com