Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:22
Wall, Kevin (Kevin.Wall@qwest.com)
Mon, 26 Apr 1999 21:13:04 -0400
In his latest Crypto-Gram newletter, Bruce Schneier had
an excellent article on "The Solitaire Encryption Algorithm".
In it (under a section called "Operational Notes"), he wrote:
"1. The first rule of an output-feedback mode stream cipher,
any of them, is that you should never use the same key to
encrypt two different messages. Repeat after me: NEVER USE
THE SAME KEY TO ENCRYPT TWO DIFFERENT MESSAGES. If you do,
you completely break the security of the system. Here's why:
if you have two ciphertext streams, A+K and B+K, and you
subtract one from the other, you get (A+K)-(B+K) = A+K-B-K
= A-B. That's two plaintext streams combined with each other
with no key involved, and is very easy to break. Trust me on
this one: you might not be able to recover A and B from A-B,
but a professional cryptanalyst can. This is vitally important:
never use the same key to encrypt two different messages."
Fortunately, this bit of timely information saved us from doing
exactly that. A colleague of mine had intended to use RC4,
a stream ciper that operates in OFB mode, with the SAME KEY each
time; he intended using the same secret key each time to eliminate
the key distribution problem. (This was suposed to be a quick
fix to a relatively minor problem; namely encrypting a new candidate
password between a servlet running in a web server and a back-end
RMI service. See below for more details.)
However, when I pointed out Bruce Schneier's above paragraph to my
supervisor (to justify additional time for my colleague to fix the
problem -- see below), I met with some resistance from my supervisor.
I think that part of the problem was not knowing how exactly to
correctly interpret the "+" and "-" operations mentioned above.
(We presume that the "+" is bitwise XOR, and "-" is bitwise
subtraction, but we aren't really sure.) But the biggest problem
is that my supervisor isn't convinced veracuty of the statement:
... you might not be able to recover A and B from A-B, but a
professional cryptanalyst can.
My supervisor cites that given A-B, there are "many differences
can produce that same result", so he is rather skeptical as to how
this can lead to an exploitable weakness. I agreed that for
our specific use (i.e., encrypting a new candidate password
that will typically only be 6 to 20 characters or so), that
the A and B plaintext streams might not be long enough and/or
might be obscure enough (i.e., not a statistically representative
of written language) so as to make standard cryptanalysis approaches
more difficult. However, I still thought that our original solution
(of encrypting multiple, independent new user passwords using RC4
and the SAME 128-bit key) was fraught with problems.
I reminded my supervisor that if one has the vantage point of
observing the ciphertext stream (between a web server and
back-end RMI services) to begin with, than one likely has already
penetrated the web server (where this all was going to be used).
Thus, it is fairly likely that if if is possible for someone to
observe the ciphertext stream at all, that the infiltrator also
has the ability at that point to mount a a chosen plaintext
attack, thus in effect, choosing either A or B plaintexts.
Eventually, we want to replace this shared secret key with
a real key distribution algorithm such as Diffie-Hellman,
but for now we needed something quick. (The problem with
shared secret's is that you have to get them from somewhere
or have them hard-coded and web server isn't secure....)
We plan on using something like DH next release (due in 3Q),
but right now, we have a deadline at the end of this month
and this is to temporarilly plug a really bad security hole
of passing candidate passwords in the clear over a public
network. I hate kludges, but I'm having trouble convincing
my boss that it's not acceptable to have user's passwords
be passed as cleartext over the public corporate intranet.
(Hey, telnet does it, right?) Sigh... :-(
Anyway, what I'm looking for is the answer to 3 questions.
1) Can someone explain in a bit more detail how
knowing A-B, the difference between two plaintext
streams, allows one to derive either A and/or B?
Also, if lengths of A and B are typically less than
20 characters (say) and are generally not words
that can be found in a dictionary, but rather a
combination of at least 1 alphabetic, 1 numeric,
and 1 special (non-alphanumeric) characters, are
these types of cryptoanalysis approaches still
feasible? (This is mostly to pass on to my
skeptical supervisor.)
2) Are we safe (safer?) in using the SAME key for
a block cipher in CFB mode and using it as a
stream cipher for the described use of passing
candidate passwords. (E.g., we were planning on using
128-bit Blowfish in 8-bit CFB mode, but using the
same "secret" 128-bit key each time.)
3) We can arrange it so that a random and very likely
(high probability) unique IV is used (probably based
on Java's java.security.SecureRandom class). (That
may be the default case, I don't know. We are using
the Cryptix Java implementation of Blowfish.) I know
that generally PSRNG usually repeat after an extremely
long period, so I presume that's true for SecureRandom
as well. Is it safe enough to assume that an IV
created using SecureRandom for Blowfish/CFB/128-bit
is "unique enough", of must I do something to ensure
absolute uniqueness for all time? Also, does anyone
know if Cryptix would already do this (pick a new
random IV each time) for Blowfish/CFB if no IV is
explicitly given, or does it reuse the same one each
time?
Thanks in advance,
-kevin wall
P.S.- If this e-mail message comes out munged (formatwise) blame it
on MS Exchange, I appologize. Exchange does some rather weird things.
--- Kevin W. Wall Light Source Software Labs, Inc. kwwall@acm.org Phone: 614.337.0395 (business) / 614.798.6371 (days) "It's easier to port a shell than a shell script." -- Larry (not my brother) Wall
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:22