archer%segin4.segin.fr@prime.com (Vincent Archer) (06/29/90)
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'&#=-*\<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 :-)