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:23
Bill Stewart (bill.stewart@pobox.com)
Tue, 27 Apr 1999 01:47:30 -0700
Assuming you're doing this for the telecom company in your email address,
PLEASE don't build in broken stuff. Bad code never goes away -
one of the N ways to break PPTP is the compatibility code from
older Microsoft login/password protocols which are trivially broken
(even though they've been replaced in newer applications,
the backwards-compatibility mode is still there.)
If you need a really quick kluge for key exchange,
at least do 3DES instead of RC4 - you can get code for it anywhere,
and everybody knows and trusts it even if it's a bit slow.
Blowfish would also do, if you prefer it.
And put in a version number so your system can tell
when you've switched versions.
At 09:13 PM 4/26/99 -0400, Wall, Kevin 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."
For further reading, look at the work Schneier et al. did on PPTP -
the protocol is broken in six or seven ways, three or four of which
include violations of this. Really, don't _ever_ do this.
That includes not using the same key for both directions of communications
(Alice to Bob and Bob to Alice.) It's too broken to use,
which is frustrating because the tunneling capability makes it easy
to handle things like private address space and non-IP protocols.
>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.)
......
>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....)
Diffie-Hellman _is_ quick and easy to implement, as long as
you've got two-way communications in your protocol.
Preventing man-in-the-middle attacks is tougher, but if you
want a quick kluge followed by a better version later,
at least _start_ with DH key exchange, and do something like
exchanging your shared secret hashed with the session key
(inside the encrypted session) as an authenticator.
If you're in a client-server sort of environment,
you could also do something like wiring a master public key
into everything so the client can verify the server's keypart
and the session key.
If you need a really quick kluge for key exchange,
at least do 3DES instead of RC4 - you can get code for it anywhere,
and everybody knows and trusts it even if it's a bit slow.
If nothing else, use it to hand out session keys derived
from some decent source of randomness.
>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?
Jim Gillogly's described crib-dragging a bit - look in Schneier
for more information. (And yes, the - and the + are usually
both really XOR; it's just more obvious when you use the
two of them to differentiate.)
> generally not words that can be found in a dictionary,
"generally not" means "sometimes, when you least expect it".
> 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.)
Probably not - certainly not unless you've done more analysis
than you're going to do for a "quick kluge"...
>P.S.- If this e-mail message comes out munged (formatwise) blame it
>on MS Exchange, I appologize. Exchange does some rather weird things.
(Brought to you by the same folks who did PPTP :-)
Thanks!
Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:23