[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Calling the question: derived vs. explicit IV
There were several inaccuracies in the summary, including the Subject
(above). Rather than arguing about them, since most of them are
attributed to me, I'll just repost them correctly.
In favor of Derived:
1) Saves 8 bytes for every datagram.
2) Maintains complete backward compatibility with RFCs 1829 and 1851.
All shipping implementations already support the derived IV.
3) Will reduce administrative and operational confusion. A change to
explicit IV would "obsolete" thousands of fielded units, and create
a user support nightmare.
4) Interoperable code will be more rapidly deployed.
5) Any change to explicit must show GREATER cryptographic strength.
Derived has been show to give somewhat stronger protection of the
first block than explicit. Estimates are from 2**7 to 2**16
depending on environment.
6) May avoid a "covert channel". This is mostly of interest to
cryptographers trying to "prove" the security of a protocol.
(This was actually mentioned by someone else on another list.)
Using an explicit IV, keying information could be leaked
deliberately -- either with the knowledge of the user in the case of
the "Clipper Chip", or without the knowledge of the user if you
believe that the U.S. government could suborn U.S. manufacturers to
leak keying information in the IV field; paranoia reigns....
7) Will allow us to move forward from Proposed to Draft Standard.
====
In favor of Explicit:
8) Having a separate field is less "complex" than deriving the field.
9) Some unknown hardware might require an explicit IV.
====
Arguments:
#1 Some argue that in some future Internet where most datagrams are
large and bandwidth is not an issue, 8 bytes is not much overhead.
But, this is not true of the current Internet. The vast majority of
datagrams are 40 bytes. The average size is 113 bytes. The median
size is smaller.
Also, since adding an Authenticator to ESP is not more secure than
using AH, the only argument in favor of the Authenticator field is
that it saves 8 bytes.
If 8 bytes isn't a compelling argument, then the Authenticator field
must be abandoned as well.
#2 Some argue that backward compatibility is not an issue.
RFCs 1829 and 1851 do not support an Authenticator. True, but the
Authenticator is optional. AH is still used for the same function
in those implementations. Support for AH is mandatory.
RFCs 1829 and 1851 also have an explicit IV. True, but that
explicit IV is _not_ compatible with the proposed explicit IV.
Removing unused features is common when going from Proposed to
Draft.
RFCs 1829 and 1851 do not require the counter value to start at 1.
True, but neither RFCs 1829 and 1851 nor the explicit drafts require
anti-replay for manually configured implementations. No problem.
#3 (no disagreement on list)
#4 compared to the complexity of implementing ISAKMP/Oakley, and the
rest of the IPSEC suite, the amount of effort to implement two
variants (old/deprecated and new/recommended) of ESP, one which was
RFC-1829 and the other implementing sequence numbers, explicit IV's,
and authenticators, really isn't all that hard. The bulk of the
code complexity is in the crypto algorithms anyway.
True, but why add that complexity and extra interoperability testing?
#5 Everyone agrees that there is an improvement in strength. Some do
not agree than an improvement in strength that protects only the
first block is worth extra effort. Others do not agree that such a
small number of bits strength is "significant".
The counter argument is that the first block is the weakest. Any
improvement in strength is useful.
And nobody has shown GREATER strength for explicit.
#6 (no disagreement on list)
#7 (no disagreement on list) Explicit will require the effort to cycle
at Proposed Standard.
#8 The differences in code have been posted to this list. The actual
code difference is two lines:
pullup(bpp,iv,4);
ip->length -= 4;
memcpy(iv+4,iv,4);
memxor(iv+4,One_bits,4);
versus:
pullup(bpp,iv,8);
ip->length -= 8;
The complexity can be easily judged.
#9 This raised its ugly head repeatedly over 4 years. No such hardware
vendor has been found. It is very unlikely that such a vendor would
appear in the future when they could not sell their wares for IPSec.
#10 Hugo Krawczyk mentions a well-known chosen plaintext attack, where
the first block is chosen. As far as I can tell, it does not apply
to any IP Protocol header in existance, and is thus entirely
theoretical and impractical.
When this was raised many years ago, I proposed encrypting the
SPI+SN in OFB mode, and using that as an IV. That would meet the
pseudorandomly selected, protected from disclosure, and
unpredictable criteria for "perfection" in cryptology nirvana. See
Voydock and Kent (1983). Unfortunately, this WG said that was too
slow and complex.
Using the sequence number was a compromise.
This theoretical attack cannot be prevented by using an explicit IV,
especially when the IV is the ciphertext from the previous last block,
as proposed by several on this list and as used in PPP.
This attack was well-known and completely and competently rejected
prior to publication of RFCs 1829 and 1851.
#11 There is no technical rationale supporting a change to an explicit IV.
====
Given the tenor of discussion on the list, it is clear that DERIVED has
the majority of proponents. Most folks just stated their preferences
once. I counted recent messages from:
Derived:
1) Me
2) "C. Harald Koch" <chk@utcc.utoronto.ca>
3) "ozan s. yigit" <oz@tor.securecomputing.com>
4) Norman Shulman <norm@tor.securecomputing.com>
5) "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
6) Karl Fox <karl@Ascend.COM>
Explicit:
1) Roy Pereira <rpereira@TimeStep.com>
2) Rodney Thayer <rodney@sabletech.com>
3) "Theodore Y. Ts'o" <tytso@MIT.EDU>
4) Derrell Piper <piper@cisco.com>
Fence-sitting:
1) mark@mentat.com (Marc Hasson)
Fine, I really don't care which it is.
2) Steven Bellovin <smb@research.att.com>
In other words, I don't care very much about explicit vs. implicit IVs
for DES. I don't think it makes any difference at all. It may matter
for other ciphers.
3) Stephen Kent <kent@bbn.com>
... The WG must decide on a
default, MUST implement encryption algorithm and mode and that decision
will weight space efficiency, confidentiality effectiveness, rekey
frequency, and existing implementations in some fashion. This is a fairly
complex set of factors to consider, so I don't assume it will be an easily
objectifiable (did I really type that word?) decision.
And since the overwhelming technical rationale is in favor of derived,
I'd have to say anyone wanting explicit should make a very careful
technical presentation.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: