2010/7/28 Sergio Belkin <sebelk at gmail.com>: > 2010/7/28 Stephen Harris <lists at spuddy.org>: >> DFILE_OFFSET_BITS=64 > > I have installed both 32 and 64 bit versions of openssl, can that be > the cause of this problem? > > Thanks in advance > > -- > -- My fault, indeed, somewhat large files is a relative term, for example it can't decrypt files You can read full ouput on: http://pastebin.com/7yZeGEa4 I've tried using both "openssl bf -d -in $1 -out $FILE -k $KEY" and "cat $1 | openssl bf -debug -d -out $FILE -k $KEY > $1.unc" and failed either. For encrypting I use: # esta funcion reemplaza a guardapgsql, guardaldap, y guardamysql guardadump() { logstr "guardando $1-dump con blowfish" ARCH=$1.dump.all.$DATE.gz.bf case $1 in mysql) CMD='mysqldump -Q -l -F --add-locks --add-drop-table -A';; ldap) CMD='slapcat -c ';; pgsql) CMD='sudo -u postgres pg_dumpall -v -c';; esac $CMD | compress | openssl bf -out $ARCH -k "$key" 2>> $LOGFILE return $? } (Of course it's only a part of a file) I started to think that size is not the problem, for example I have files: -rw-r--r-- 1 root root 10264 Jul 29 00:24 usr.local.etc.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 4402600 Jul 29 00:23 dir.Thu-29-Jul-2010.gz -rw-r--r-- 1 root root 4853784 Jul 29 00:24 usr.lib.perl5.5.8.8.UP.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 12554264 Jul 29 00:24 etc.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 17302224 Jul 29 00:23 ldap.dump.all.Thu-29-Jul-2010.gz.bf -rw-r--r-- 1 root root 92241944 Jul 29 00:24 scripts.Thu-29-Jul-2010.tgz.bf -rw-r--r-- 1 root root 209591864 Jul 29 00:23 pgsql.dump.all.Thu-29-Jul-2010.gz.bf And scripts.Thu-29-Jul-2010.tgz.bf can be decrypted. May compress the "culprit"? I tried with a small database (544 K compressed with ncompress) and have no problem anyway, so I am rather puzzled :( Any idea? TIA -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com Sergio Belkin -