The following is trivia related to the stringtokey function used in
AFS for passwords of eight characters or less. It is not something to
be concerned about, but is something people should be aware of.
For passwords P of eight characters or less, the following method
computes passwords P-alt which encrypt to the same key as P. The
implication is that a trivial many-to-one mapping exists. For the
unitiated, this basically means two different passwords could log into
the same account.
Let C be the cell name in upper case. I consider the cell name to be
upper case since this is how it is treated in the stringtokey
function.
let Cn be the nth character of C
let Pn be the nth character of P (the password in question)
let Tn be a character related to Pn and Cn through the mapping
("ef" is "else if")
as n ranges from 1 to 8
if (Pn-0x20 == Cn) {
Tn = undefined
if (Pn >= 0x60 && Pn <= 0x67)
Tn = Cn - 0x8
ef (Pn >= 0x68 && Pn <= 0x6f)
Tn = Cn - 0x18
ef (Pn >= 0x70 && Pn <= 0x77)
Tn = Cn - 0x28
ef (Pn >= 0x78 && Pn <= 0x7f)
Tn = Cn - 0x38
}
Note: this range neatly covers the lowercase alphabet (0x61 -> 0x7a).
Note: for characters of the alphabet, upcase+0x20 = lowcase. This
makes the condition (Pn-0x20 == Cn) interesting.
Tn is a character which may be substituted for Pn to form P-alt which
will encrypt to the same key. All subsets of possible Tn, given P and
C, applied to P, yield valid P-alt.
Examples: password "animal" in the cell andrew.cmu.edu is equivalent to
"9nimal" and "a6imal" and "96imal". "diane" is equivalent to
"dian=". "farrjami" is equivalent to "far*jami". And so forth.
The worst case result is that "andrew.c" is the same as "96<*=/.;" in
cell andrew.cmu.edu. (and "96<rew.c" and "9n<re/.c", etc).
This was derived empirically. I have made no attempt to determine the
"why" of the transformation. I have attempted to extend the
transformation below 0x60 without success and my suspicion is that it
doesn't.
And no, I don't do this all day :). During our latest crack run
(obplug: grab export.acs.cmu.edu:/pub/crack.tar.Z and USE IT) I added
rules which revealed this transformation - i.e. keys being cracked via
multiple strings.
dan lovinger
cmu comp services
[EMAIL PROTECTED]
The following is a table of the transposes.
[ bin dec hex oct char transpose ]
01100000 96 60 140 ` 8
01100001 97 61 141 a 9
01100010 98 62 142 b :
01100011 99 63 143 c ;
01100100 100 64 144 d <
01100101 101 65 145 e =
01100110 102 66 146 f >
01100111 103 67 147 g ?
01101000 104 68 150 h 0
01101001 105 69 151 i 1
01101010 106 6a 152 j 2
01101011 107 6b 153 k 3
01101100 108 6c 154 l 4
01101101 109 6d 155 m 5
01101110 110 6e 156 n 6
01101111 111 6f 157 o 7
01110000 112 70 160 p (
01110001 113 71 161 q )
01110010 114 72 162 r *
01110011 115 73 163 s +
01110100 116 74 164 t ,
01110101 117 75 165 u -
01110110 118 76 166 v .
01110111 119 77 167 w /
01111000 120 78 170 x SPC
01111001 121 79 171 y !
01111010 122 7a 172 z "
01111011 123 7b 173 { #
01111100 124 7c 174 | $
01111101 125 7d 175 } %
01111110 126 7e 176 ~ &
