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
Jim Gillogly (jim@acm.org)
Mon, 26 Apr 1999 18:44:16 -0700
Kevin Wall asked:
> Anyway, what I'm looking for is the answer to 3 questions.
I'll take the first question.
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?
The general problem is equivalent to solving a "running key
cipher", where one text is encrypted using another as a key,
e.g. by XORing the two of them together. The easiest way
to solve them is with a technique known as "crib-dragging".
That is, you pick a potential phrase, word, tetragraph, or
whatever is convenient from the space of likely samples
of either the key or the plaintext, and XOR it in each position
in the cipher. You then inspect the result to see whether it
also looks like plaintext and/or key. If it does, extend one or
the other piece of plaintext to either side, and repeat the
process. If you run out of likely extensions, pick another
"crib" and drag it through the ciphertext again, and repeat
until you're done. This sounds tedious, but has been quite
effective in real life as well as on toy problems.
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?
Probably they are still feasible. As system administrators
you are by now be aware that you must never underestimate the
lengths to which a user will go to subvert your attempts
to make him pick a strong password. There will undoubtedly
be legal trigraphs and tetragraphs in almost all passwords,
and almost certainly complete words as well, even if they're
capitalized oddly and interspersed with digits. If there are
digits, they will usually be a single '1', or they will be
four digits starting with '19' -- i.e. nothing that will
interfere with recognizing plaintext when you see it.
Worse, the way you described the system all the passwords
will be done the same way, so it's not just a question of
reversing A+B: the attacker can also try reversing A+C, B+C,
A+D and so on, so that if any two of your users have passwords
with recognizable chunks, that part of the stream is blown
and can be applied to every other password on the system,
allowing innumerable chances to extend them in each direction.
For a quick fix to your problem, consider using RC4 with
a nonce: an IV or "salt" that you select for each password
and pass in the clear with the encrypted password. See
http://ciphersaber.gurus.com for one way to do this. For
a longer-term solution you might want to consider SSH or
IPSec.
-- Jim Gillogly Sterday, 6 Thrimidge S.R. 1999, 01:22 12.19.6.2.11, 7 Chuen 19 Pop, Sixth Lord of Night
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:22