Hi,
I've encrypted some database dumps with
openssl bf -d -in dumpfile.bf -out dumpfile -k mykey
bad decrypt 14142:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:325:
The weird thing is if I do the same with smaller files it can decrypt with no problem. I use openssl-0.9.8e-12.el5 on Centos 5.4.
Please could you tell me what I am doing wrong?
Thanks in advance!
On Wed, Jul 28, 2010 at 04:04:26PM -0300, Sergio Belkin wrote:
I've encrypted some database dumps with
openssl bf -d -in dumpfile.bf -out dumpfile -k mykey
bad decrypt 14142:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:325:
The weird thing is if I do the same with smaller files it can decrypt with no problem. I use openssl-0.9.8e-12.el5 on Centos 5.4.
Is the file over 2Gb in size? A number of programs have 2Gb filesize limits (eg "unzip"). You could, perhaps, use it as a pipe: cat dumpfile.bf | openssl bf -d -k mykey > dumpfile
On 7/28/10 12:10 PM, "Stephen Harris" lists@spuddy.org wrote:
On Wed, Jul 28, 2010 at 04:04:26PM -0300, Sergio Belkin wrote:
I've encrypted some database dumps with
openssl bf -d -in dumpfile.bf -out dumpfile -k mykey
bad decrypt 14142:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:325:
The weird thing is if I do the same with smaller files it can decrypt with no problem. I use openssl-0.9.8e-12.el5 on Centos 5.4.
Is the file over 2Gb in size? A number of programs have 2Gb filesize limits (eg "unzip"). You could, perhaps, use it as a pipe: cat dumpfile.bf | openssl bf -d -k mykey > dumpfile
This only is caused by applications that either a) impose a 2GB limit directly (zip being one) or b) have not been built with large file support (-DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64).
On Wed, Jul 28, 2010 at 12:37:19PM -0700, Gary Greene wrote:
On 7/28/10 12:10 PM, "Stephen Harris" lists@spuddy.org wrote:
Is the file over 2Gb in size? A number of programs have 2Gb filesize limits (eg "unzip"). You could, perhaps, use it as a pipe: cat dumpfile.bf | openssl bf -d -k mykey > dumpfile
This only is caused by applications that either a) impose a 2GB limit directly (zip being one) or b) have not been built with large file support
Zip files can be over 2Gb in size, however. Windows handles them just fine, but infozip doesn't. I had to use "jar" to extract a massive zip file I had :-)
(-DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64).
Which is why I only suggested it ("perhaps").
2010/7/28 Stephen Harris lists@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
2010/7/28 Sergio Belkin sebelk@gmail.com:
2010/7/28 Stephen Harris lists@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
2010/7/29 Sergio Belkin sebelk@gmail.com:
2010/7/28 Sergio Belkin sebelk@gmail.com:
2010/7/28 Stephen Harris lists@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
I forgot to say that scripts.Thu-29-Jul-2010.tgz.bf it is generated in a different way of dump files:
guardassl() { if [ "$2" != "" ];then EXCLUDE="--exclude "$2"" fi logstr "guardando $1 con blowfish $EXCLUDE" ARCH=`echo "$1" | sed 's/^///'|sed 's///./g'`.$DATE.tgz.bf tar --create --preserve --gzip $EXCLUDE $1 | openssl bf -out $ARCH -k $KEY 2>> $LOGFILE return $? }
On largish files, on a CentOS 5, 64 bit arch, openssl seems to work fine here
[herrold@centos-5 SRPMS]$ time openssl bf -in \ freeswitch-0.0.20100729.git-1.src.rpm -out \ freeswitch-0.0.20100729.git-1.src.rpm.bf enter bf-cbc encryption password: Verifying - enter bf-cbc encryption password:
real 0m38.587s user 0m3.700s sys 0m0.568s [herrold@centos-5 SRPMS]$ time openssl bf -d -in \ freeswitch-0.0.20100729.git-1.src.rpm.bf -out \ new_freeswitch-0.0.20100729.git-1.src.rpm enter bf-cbc decryption password:
real 0m39.543s user 0m3.652s sys 0m0.792s [herrold@centos-5 SRPMS]$ md5sum freeswitch-0.0.20100729.git-1.src.rpm \ new_freeswitch-0.0.20100729.git-1.src.rpm b33eed78ec8fbccb7ef632c0c4bfe8ac freeswitch-0.0.20100729.git-1.src.rpm b33eed78ec8fbccb7ef632c0c4bfe8ac new_freeswitch-0.0.20100729.git-1.src.rpm [herrold@centos-5 SRPMS]$ ls -alh freeswitch-0.0.20100729.git-1.src.rpm \ new_freeswitch-0.0.20100729.git-1.src.rpm -rw-r--r-- 1 herrold herrold 320M Jul 29 11:00 freeswitch-0.0.20100729.git-1.src.rpm -rw-rw-r-- 1 herrold herrold 320M Jul 29 12:33 new_freeswitch-0.0.20100729.git-1.src.rpm [herrold@centos-5 SRPMS]$
As such perhaps you are overrunning a pipe, or have a problem elsewhere in the process
-- Russ herrold
2010/7/29 R P Herrold herrold@centos.org:
On largish files, on a CentOS 5, 64 bit arch, openssl seems to work fine here
[herrold@centos-5 SRPMS]$ time openssl bf -in \ freeswitch-0.0.20100729.git-1.src.rpm -out \ freeswitch-0.0.20100729.git-1.src.rpm.bf enter bf-cbc encryption password: Verifying - enter bf-cbc encryption password:
real 0m38.587s user 0m3.700s sys 0m0.568s [herrold@centos-5 SRPMS]$ time openssl bf -d -in \ freeswitch-0.0.20100729.git-1.src.rpm.bf -out \ new_freeswitch-0.0.20100729.git-1.src.rpm enter bf-cbc decryption password:
real 0m39.543s user 0m3.652s sys 0m0.792s [herrold@centos-5 SRPMS]$ md5sum freeswitch-0.0.20100729.git-1.src.rpm \ new_freeswitch-0.0.20100729.git-1.src.rpm b33eed78ec8fbccb7ef632c0c4bfe8ac freeswitch-0.0.20100729.git-1.src.rpm b33eed78ec8fbccb7ef632c0c4bfe8ac new_freeswitch-0.0.20100729.git-1.src.rpm [herrold@centos-5 SRPMS]$ ls -alh freeswitch-0.0.20100729.git-1.src.rpm \ new_freeswitch-0.0.20100729.git-1.src.rpm -rw-r--r-- 1 herrold herrold 320M Jul 29 11:00 freeswitch-0.0.20100729.git-1.src.rpm -rw-rw-r-- 1 herrold herrold 320M Jul 29 12:33 new_freeswitch-0.0.20100729.git-1.src.rpm [herrold@centos-5 SRPMS]$
As such perhaps you are overrunning a pipe, or have a problem elsewhere in the process
-- Russ herrold _______________________________________________
Thanks Russ,
Sadly I've tried the same process by hand on both ways and on different physical servers running Centos:
openssl bf -d -in $1 -out $ARCH -k $KEY
and
cat $1 | openssl bf -debug -d -out $ARCH -k $KEY > $1.unc
and either failed :(
I am taken aback...
2010/7/28 Gary Greene ggreene@minervanetworks.com:
On 7/28/10 12:10 PM, "Stephen Harris" lists@spuddy.org wrote:
On Wed, Jul 28, 2010 at 04:04:26PM -0300, Sergio Belkin wrote:
I've encrypted some database dumps with
openssl bf -d -in dumpfile.bf -out dumpfile -k mykey
bad decrypt 14142:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:325:
The weird thing is if I do the same with smaller files it can decrypt with no problem. I use openssl-0.9.8e-12.el5 on Centos 5.4.
Is the file over 2Gb in size? A number of programs have 2Gb filesize limits (eg "unzip"). You could, perhaps, use it as a pipe: cat dumpfile.bf | openssl bf -d -k mykey > dumpfile
This only is caused by applications that either a) impose a 2GB limit directly (zip being one) or b) have not been built with large file support (-DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64).
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
Do you mean that I should to recompile openssl?
I've tried Stephen solution's with no success :(
Debug ouput is:
BIO[00875EF0]:ctrl(106) - FILE pointer BIO[00875EF0]:ctrl return 1 BIO[00875F70]:ctrl(108) - FILE pointer BIO[00875F70]:ctrl return 1 BIO[00875F70]:write(0,8) - FILE pointer BIO[00875F70]:write return 8 BIO[00875F70]:write(0,8) - FILE pointer BIO[00875F70]:write return 8 BIO[00876230]:ctrl(6) - cipher BIO[00875F70]:ctrl(6) - FILE pointer BIO[00875F70]:ctrl return 0 BIO[00876230]:ctrl return 0 BIO[00875EF0]:read(0,8192) - FILE pointer BIO[00875EF0]:read return 8192 BIO[00876230]:write(0,8192) - cipher BIO[00875F70]:write(0,4096) - FILE pointer BIO[00875F70]:write return 4096 BIO[00875F70]:write(0,4096) - FILE pointer BIO[00875F70]:write return 4096 BIO[00876230]:write return 8192 BIO[00875EF0]:read(0,8192) - FILE pointer BIO[00875EF0]:read return 8192 BIO[00876230]:write(0,8192) - cipher BIO[00875F70]:write(0,4096) - FILE pointer BIO[00875F70]:write return 4096 BIO[00875F70]:write(0,4096) - FILE pointer BIO[00875F70]:write return 4096 BIO[00876230]:write return 8192 BIO[00875EF0]:read(0,8192) - FILE pointer BIO[00875EF0]:read return 8192 BIO[00876230]:write(0,8192) - cipher [...] BIO[00876230]:ctrl(11) - cipher BIO[00875F70]:write(0,8) - FILE pointer BIO[00875F70]:write return 8 BIO[00875F70]:ctrl(11) - FILE pointer BIO[00875F70]:ctrl return 1 BIO[00876230]:ctrl return 1 BIO[00875EF0]:Free - FILE pointer BIO[00875F70]:Free - FILE pointer BIO[00876230]:Free - cipher
Thanks in advance!!
-
Gary Greene -
R P Herrold -
Sergio Belkin -
Stephen Harris