John Gilmore cites NSA's desire for plaintext IVs as an argument in
favor of enciphering IVs:
Here is a non-technical argument against plaintext IV's:
a. Data encryption (either or both below):
(i) RC4; 40 bit key (which can vary with every message); with
key management as per (b) below or with no key
management.
NOTE: It shall be permissible to pre-fix an initialization vector
to any plain text message that is to be encrypted with RC4.
The initialization vector itself will appear in plain text in the
message itself and will be exclusive or'd [sic] with the RC4 key
prior to RC4 key set up.
(ii) RC2; 40 bit key; with key management as per (b) below or
with no key management
The NSA/SPA agreement, excerpted above, permits expedited export of
crypto gear but requires that the IV be in plain text. Since the
conditions for mass market export are widely believed to mean "NSA can
decrypt the traffic if you follow these conditions", the existence of
a plaintext IV may make a significant difference in cryptanalysis.
Whether or not we understand all the implications of why.
Let me turn this argument around a bit. It seems to me we're
inextricably stuck with having different levels of protection.
Exportable cryptography will be weaker than some threshold, and many
of us will demand stronger cryptorgraphy for non-exportable systems.
If we choose to encipher the IV, we may complicate or eliminate the
possibility of getting an export license even when weak, e.g. RC4/40,
cryptography is used. I'd rather see a framework which spans both
exportable and non-exportable cryptography. In the present framework,
with non-enciphered IVs, we are able to obtain exprt licenses for the
weak cryptography, and we can use storng cryptography for domestic
systems.
Even if we were starting from scratch, would we choose a framework
which foreclosed the possibility of exporting all versions of PEM?
Steve