> A.R.C.S., or the Angelo Rosiello and Roberto Carrrozzo Stream cipher, > is [...] > The authors hope that someone will try to break this cipher and > welcome all attempts and added research. It is a simple stream cipher, with the key data generation done with MD5; a 48-byte buffer is maintained, with each 16-byte subblock loaded differently, based on MD5s of the key string and one of its permutations. The MD5 of this buffer gives 16 bytes of data which is XORed with to encrypt or decrypt (I would call this the "key data" for the stream cipher, but there's already something I'm calling "key data", so this is the "XOR data"). Then the first 16 bytes of the 48-byte buffer are reloaded, with half the bits coming from the 16 bytes of XOR data and half from one of the hashes of the key material; the resulting 48-byte block is MD5ed to give 16 more bytes of XOR data. Lather, rinse, repeat, for each 16 bytes of en/decryption. I've left out details such as exactly how the key material is juggled for the various hashes and how the reloading is done; see the code for them. MD5ing 48 bytes for each 16 bytes of data strikes me as rather expensive. Other than that, and aside from all the weaknesses common to all stream ciphers (like, never use the same key for more than one cleartext), this is resting all its strength on MD5's strength. Probably good enough for low-security uses, though I'd want to make an intensive study of MD5's weaknesses with respect to this particular feedback mode before using it for anything major. If you do use this algorithm, I strongly recommend against using the supplied implementation. The code contains a buffer overrun if the key is longer than 49 bytes, and a buffer underrun (storing before the buffer) if it's shorter than 3 bytes; the supplied front-end checks for too-short (it actually checks for <6, rather than the <3 necessary to avoid the underrun), but not for too-long. And the ARCS() function checks for neither, is incapable of crypting anything but files (for no visible reason), opens its source file read/write even though it never tries to write to it, compares pointer variables to zero with <= (!!), has a number of minor inefficiencies and such that aren't really bugs, and quite probably has other problems I missed in my quick once-over. It badly needs to be reimplemented from the ground up, if it is to be used at all. I'm not going to try to break it myself; I give away enough unpaid consulting time as it is - and for the effort this would involve, one tee-shirt counts as "unpaid". (Also, I don't do contingency gigs unless I think the chance of success is quite good, or the job is fun enough that I don't really mind not getting paid.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
