bugtraq - Re: Packetstorm started a try2crack of A.R.C.S. Algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200309262104.RAA17801@Sparkle.Rodents.Montreal.QC.CA>
Date: Fri, 26 Sep 2003 16:31:53 -0400 (EDT)
From: der Mouse <mouse@...ents.Montreal.QC.CA>
To: bugtraq@...urityfocus.com
Subject: Re: Packetstorm started a try2crack of A.R.C.S. Algorithm

> 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@...ents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B