Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!ncar!mephisto!udel!mmdf
From: archer%segin4.segin.fr@prime.com (Vincent Archer)
Newsgroups: comp.os.minix
Subject: Here's a better crypt(3) function for Minix 2.0...
Message-ID: <23171@nigel.udel.EDU>
Date: 29 Jun 90 10:06:21 GMT
Sender: mmdf@udel.EDU
Lines: 86

I have implemented the little "scrambler" algorithm I spoke of a few days
ago. Below is a lib/other/crypt.c function (compressed-uuencoded) that does
the trick. As an example, here's a little comparison between Minix 1.5 crypt
and mine. Four crypted values are shown:

Salt Password		Minix crypt()	My crypt()
 --  -----------	-------------	-------------
 00  "password"		00|0WFy1B8Tz|	001dcsc5Sh3TQ
 00  "Password"		00|0WFy1B8Tv|	00rTQYCDHmeRY
 00  "password "	00|0WFy1B8Tz|	00pzqMhV9et9M
 03  "password"		03z||meFy1B8T	03nJJegU4/CEg

You (of course) immediately notice that using upper-lowercase does not
significatively change the password, nor changing the salt value, and that
characters after the 8th are entirely unsignificant. In mine, however,
everything is significant, even the 255th character of the password
(basically, the 637 first characters are significant and 512 more have the
potential of being used!!!). This is because of the CRC property of
"spreading" significantly bits over a large place; every bit in the result
depend of nearly every bit in the source in some complicated manner.

Thos Sumner pointed out two algorithms for crypting that were posted recently,
but since I do not have the full news (I get comp.os.minix thru the Bitnet
mailing list), I don't know what to do with them. Anyway, my crypt() is
perfectly compatible with Unix/Minix operation, so it's better in that respect.

He also suggested using a machine-dependant (by machine, I mean SITE-dependant)
info to discourage theft of /etc/passwd files for decryption at leisure. Is
there such an info available on Minix in a standard way? Anyway, you'll notice
that, even using mixs of chars, shorts, longs and 6-bits blocks the results
are the same on 68000 and xxx86, even with the different byte ordering (this
was not intended :-)


Btw, since there's a call for bug reports on c68, the crypt() gave me one.
Since I have problem with my mail paths, I've included the stuff after the
legal function. If you're not CvW, skip it... :-)

table
 !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 crypt.c.Z
M'YV-+U2 &",G#QPZ(%J @!-FSIP[;^20 5'&#4&#=-*\<0-"SILZ&=V429 @z
M"$@T$76 L)+&8D6$0>2,05-&#@@5+Q0HF!G&IHJ+!U' N<,"Q)PP;.BDV(FFy
MY\VA154<3;I#P1X%((S2"9-QS,"F-ADZA"AQ2PP:7:IF9;/Q#(@V7.6DP6-6x
M!HXN4=L4M5-F#)V(6V2DQ?K5:9BB8J+"B1I'+8B6"-/L15JGC.,Z;N:D.2-Rw
MXAR4<A 2'',Y\^;.(-BZ<4NG*N$T9D"@F$IG"XPN*4!<31 &1 ^C2&O?KIH v
MMFS:9G&#$.,;>-+DQ,NPF5-F>?,PCOM0G%Z]]V_FOT_ ..%8[,.(9&QWN5Z^u
MX?FR,=9_=VP<16\?($YH.9&[=XO?-M 7FWT@X'="#OR!X-]O-P@H&W,&[I<;t
M<_^!$.!K T*8'X(3)L2@8POFYP)YA%$8WHB.V4%9=;\1R,>#//!@0PJYF0 "s
M##?DV*!.68V655:_J<A&92FN",(*O\4 PY*.,?<CD#>6]R240SEV!QIIL%$=r
M"D)6UD(+N>U6GX\VPH '#DO"D)N/+?H8(P@QY.;%C7@H*4,,T7$WD$P@Q)@Dq
M<?6%($:8"I $'@@X$%?<@"&@D$9S*L"QP@HTZE8H27 T5^6EQ4$JZ0J*]E&Hp
MJ(O*]FB99ZJYIU=>_%GHHW["29P87V;'XUO-P46'7'@XIBNOZC4' XC-S2"#o
M8V9$)%N79?2 HXX[@,!L@;\-*^V*7Q*:@ IM],F#JZ6B0":=:"ZI[;;=\@%Nn
M FS*YB8/<,I)IYUXCKH==:MZ"VZ@@UIJ:'.)7AJHHYY.6NENF&IZAZ*=_A;Im
MI*&.^NJ IY*KJH^MROJJOAHG0&L+@#)J7[;G]O;C;\8JJL*DW59+G*A9B4H8l
M7WX!=INP*?;UEQS)X4Q8IE.>["Y8-Z5 \\[(*NNHL]&FP4.#CQG\V(!#;9&&k
M<@^OH+#5@R4@';YBR%%&&&NXEE6FOYE'%ADK'$N8R0#Z"N6O<SD6J<]9)6O3j
MTL\V[0/3CV7K+T(.MS$I"'-R>_B<1]N\'N,Z Q;?K#XG<&666RKE;[@(V1BGi
M=1G72Q)"/OS=,:EAU#KQ@[G=K2Z<,6*W.@HAA%'RDW%?NO(*:$<I<<RWZFUJh
M#\<^QD,,,S0M]6YJH\?UD2>2&&[S95U=X(8)4I^>]4B"L./T[JW]?(39A^\\g
7][D#?[;Y\,T@G^^$B4U''7)PI'U5H@)=f
 e
end


Ok, here's the report... The problem is located in the optimization of
some expressions, namely "var ^= constant;". The compiler allocates the
"var" to some register, then uses that register everywhere... EXCEPT in
the kind of expression above, where it erroneously references the memory
location where the variable was originally intended to be put...

Compile with -S, and check the lines:
103:eor.w	#1,-540(a6)		! should be: eor.w	#1,d6
152:eor.w	#1,-540(a6)		! same thing
215:eor.b	#1,-526(a6)		! should be: eor.b	#1,d4

it's possible that other similar expressions do this, I haven't checked
them...


	Vincent Archer


No .signature today. And no excuses either, I'm not good at finding any :-)