On Wednesday 05 July 2006 17:16, Francisco Rosales wrote: Hello all,
> > Unfortunately I face a break with the new GPL'ed ARC4 implementation. The > > patch for that implementation for shc 3.7 along with some rc4 tests is > > found at: > > Please, do not use the shc 3.7 rc4 implementation. It has a > problem. In rc4, the global jndx = 0; is reset to 0 for each chuck of data > encrypted. It must not be done so, jndx = 0; must be set only at > initialization (in state_0). > > This bug was fixed in shc 3.8. Well we start off with 3.7 because it is currently in Debian. The main problem is the rc4 implementation which has no copyright attached. That's the reason we started replacing it with a clean-room GPL'ed implementation and finally make the program licensed free and consistent. Otherwise it will be removed from the archive because of legal issues. For the time being as for 3.7 version with the new GPL'ed rc4 implementation I forced intentionaly relax/redistributable binary to be created to overpass the above 'shell has changed'. I agree, it is far from being perfect. You can find more information at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335278 > As you have seen, I have implemented the initialization stage with > two functions, not one (stte_0 and key). The reason is that I want to be > able to apply more than one password, using key fuction several times. That was what puzzled me a lot in the first place, but seems is the right way to go. > /* 3.8.5 */ I failed to find 3.8.5 version at http://www.datsi.fi.upm.es/~frosal/sources/ and the rows listed below are not from the last version found 3.8.3. > 851 stte_0(); > 852 key(pswd, pswd_z); > ... > 862 key(chk1, chk1_z); > ... > 867 if (indx && key_with_file(kwsh)) { > ... > 875 key(chk2, chk2_z); > > One stte_0 but four key calls. One is key_with_file which makes > the rest of the encryption to depend on some signature of a given file. > This is the reason of the message (and the method to detect) > "shell has changed!". > > (( You cannot make the change: > -" key(control, sizeof(control));", > +" key(\"control\", sizeof(control));", > because it changes totally the pretended behaviour )) Oh, that is a forgotten temporal compiler shut-up which will be reverted. The first arg of the key function should be changed to void *str, but I rather go for const char *str as more safe one, which couse a little redesign though. > In shc-3.8.3.diff your implementation of key do not remember the > last index exchanged (kndx) and do not uses len to bound k[] indexing to > its real length. Well this comes as a consequence of the above misunderstanding. I have to look more closely to that one. > > http://crustytoothpaste.ath.cx/~bmc/files/free/crypto.pax.bz2 > > > > I still need to resolve why strcmp(TEXT_chk2, chk2) is put there, which > > succeeds causing the following break: > > As I have already stated, key_with_file (and the ability to use > key _incrementally_ several times) permits to make the encryption > dependent on some details of a given file. So the decryption of chk2 > will change if the signature of the given file changes, in other words > if the "shell has changed!". Hm, I'm a little bit confused by the message like "shell has changed", should it be more straightforward ... 'signature has changed' or 'decryption failed' ? > Perhaps my implementation of arc4 is more add-hoc than yours, but, > please, I see no reason to break the described behaviour. I agree with you. OTOH, in the light of having bits with clear license only we should replace the unknown-license cypherpunks code with a license-clear implementation. I'll try to have a look and try to achieve what you describe above. The best solution im my opinion will be a new upstream version of shc with license-clear arc4 implementation. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
