Decrypt fails when the size of a decrypted file nears a
1k byte boundary. Extra
bytes appear to be written, and a SHA1 check failure
ensues.
The following script illustrates the problem.
uname -a
gcc --version
mcrypt --version
MCRYPT_KEY=X
export MCRYPT_KEY
while [ 0 -eq 0 ]; # use ctrl/c to kill
do
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17;
do j=1
# build a file with i characters
while [ $j -le $i ];
do echo -n "X" >>x$i
let j++;
done
# encrypt it
if !(mcrypt -q -a arcfour --mode stream x$i)
then read -p "Encrypt failed for x$i" ANSWER
exit;
fi;
# now test decrypt
rm x$i
if !(mdecrypt -q --nodelete x$i.nc);
then ls -l x$i*
fi rm x$i.nc
done;
done
On my system, produces:
tonyb@linux:~/tc> ./t.sh
Linux linux 2.4.20-4GB #1 Wed Jun 18 07:45:45 UTC 2003
i686 unknown unknown GNU/Linux
gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Mcrypt v.2.6.4 (i686-pc-linux-gnu)
Linked against libmcrypt v.2.5.5
Copyright (C) 1998-2002 Nikos Mavroyanopoulos
(nmav@gnutls.org)
SHA1 check failed
File x5.nc was NOT decrypted successfully.
-rw------- 1 tonyb users 1024 2003-10-19
14:08 x5
-rw------- 1 tonyb users 1084 2003-10-19
14:08 x5.nc
SHA1 check failed
File x15.nc was NOT decrypted successfully.
-rw------- 1 tonyb users 3072 2003-10-19
14:08 x15
-rw------- 1 tonyb users 3132 2003-10-19
14:08 x15.nc
SHA1 check failed
File x10.nc was NOT decrypted successfully.
-rw------- 1 tonyb users 2048 2003-10-19
14:08 x10
-rw------- 1 tonyb users 2113 2003-10-19
14:08 x10.nc
SHA1 check failed
File x14.nc was NOT decrypted successfully.
-rw------- 1 tonyb users 3072 2003-10-19
14:08 x14
-rw------- 1 tonyb users 3135 2003-10-19
14:08 x14.nc
SHA1 check failed
File x9.nc was NOT decrypted successfully.
etc, etc.
Cheers,
TonyB
Logged In: YES
user_id=890117
I just noticed that somehow I got mcrypt linked against an
old version of libmcrypt. I have just linked it against
2.5.7 and the same problem occurs.
Logged In: YES
user_id=1466
This suggests that the block algorithms are incorrectly
handling filler material. This is an urgent problem, as block
encryption is 99.9% of everything that libmcrypt is likely to be
used for. The problem right now is that there's a long list of
urgent problems! This will have to be fixed for the next
release, though, as the library is useless otherwise.