Hi Dave, Thank you for this description. It helps me to understand what's happen. So I'll check your suggestion and come back with results as soon as possible. Actually I'm working on other issues.
Maybe you could still help me for one thing; What do you mean with "d2i"? Please apologize, I'm not familiar with this acronym. Best regards, Marco From: [email protected] [mailto:[email protected]] On Behalf Of Dave Thompson Sent: Freitag, 22. November 2013 00:38 To: [email protected] Subject: RE: Malloc failure when decrypting files larger 1.48 GB with openssl smime There's a hardcoded limit of just under 1.5G (0x5ffffffc) on growing BUF_MEM, which is used to hold 'streamed' input DER in this case and others (but no other openssl ASN.1 data would be this big). Apparently this is to allow the data to be b64-ed (without linebreaks?) and measured in an int, which can be and usually is (signed) 32bit. This seems unnecessarily strict since many BUF_MEM's including this one won't be b64-ed, and those that are may not need to be measured in int. I guess you can get round this by a simple app that reads the DER into memory (converting from PEM or SMIME in the process if desired), then d2i's from that buffer which is already large enough. But I don't have a 64-bit build setup to try it. For me at least, using the ShiningLight win64 build of 1.0.1c, -encrypt without -stream truncates the data without any error indication at a bit less than 2GB (0x777c2000). Watch out for that. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marco Köllner Sent: Tuesday, November 19, 2013 05:14 To: [email protected]<mailto:[email protected]> Subject: *** Spam *** Malloc failure when decrypting files larger 1.48 GB with openssl smime Hi, For one of our customer I'm trying to test RSA public key encryption for file transfer. The common setup is windos7 & 8 as 64bit system & OpenSSL 0.9.8k (but 0.9.8y & 1.0.1e shows the same problem). Now I see a problem by decrypting large files with OpenSSL. Mainly we use openssl smime for encryption and decryption since it works fine for our purpose. - openssl.exe smime -encrypt -outform DER -des3 -binary -in LargeFile.dat -out LargeFile.dat.en Receip.cer - openssl.exe smime -decrypt -inform DER -in LargeFile.dat.en -binary -inkey PrivateKey.der -passin file:digest.key While encryption works, decryption seems to have problems with encrypted files larger 1.48 GB. Right after the start I got the following messages: Error reading S/MIME message 11992:error:07069041:memory buffer routines:BUF_MEM_grow_clean:malloc failure:.\crypto\buffer\buffer.c:169: 11992:error:0D06B041:asn1 encoding routines:ASN1_D2I_READ_BIO:malloc failure:.\crypto\asn1\a_d2i_fp.c:242: The used key has 4096 bits. I've seen on the News page in section "Major changes between OpenSSL 0.9.7g and OpenSSL 0.9.8" that files large 2GB might be supported now. Could you help me to solve the problem? Possibly smime is not the correct module. Thanks in advance. Best regards, Marco Marco Köllner Application Developer fon +49 (0) 7062.9565-17 TMN Systemberatung GmbH Unsere Blogs<http://blogs.tmn-net.com/> | Unsere Website<http://www.tmn-systemberatung.de/> [cid:[email protected]] TMN Systemberatung GmbH | Schwabstr. 7 | 74360 Ilsfeld | Germany | fon +49 (0) 7062.9565-0 | fax +49 (0) 7062.9565-19 Eingetragen am Amtsgericht Stuttgart, HRB 106526 | Geschäftsführer: Armin Neudert, Wolf-Michael Niethammer Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
<<inline: image001.png>>
<<inline: image002.png>>
