[openssl.org #552] [Fwd: Bug#186490: libssl0.9.7: EVP_{En,De}cryptFinal() don't free ctx parameter]
[EMAIL PROTECTED] - Tue Apr 1 12:04:10 2003]: On Tue, Apr 01, 2003 at 09:32:33AM +0200, Christoph Martin wrote: So I can safely call EVP_*Init() on the same ctx without freeing inbetween? Why are there *_ex() functions which don't free stuff when the *() functions now don't free stuff either? Whatever you want the functions to do, please make sure the manpages contain correct information. No you can't completely reuse the same ctx. You can *only* reuse exactly the same key and IV the last context used by calling EVP_*Init() with all parameters NULL apart from the ctx. This is a little known feature of the EVP_*Init() functions but some code makes use of it so we have to retain compatibility. However this feature means that we can't free up the ctx automatically in EVP_*Final(). The problem with the old EVP_*Init() functions is that they were typically called like this: EVP_CIPHER_CTX ctx; EVP_CipherInit(ctx, ...); This means that EVP_CipherInit() cannot make *any* assumptions about the state of 'ctx' because it is completely uninitialized. So it has to complelely initialize the ctx. There is one exception to this rule: it is assumed that if EVP_*Init() is called with all parameters NULL apart from ctx that ctx *is* valid. The only difference between this behaviour and versions before 0.9.7 is that you now have to call EVP_CIPHER_CTX_cleanup() when you've finished with a ctx or it will leak memory. In 0.9.6 and earlier you didn't have to call EVP_CIPHER_CTX_cleanup() but this would leave a sensitive security context in memory which is a bad idea anyway. The _ex() functions serve two separate purposes. Firstly they have an extra 'engine' parameter which allows the use of none default ciphers in other ENGINEs. Secondly they remove this uncertaintly about the state of ctx. When an EVP_*Init_ex() function is called the ctx *must* be valid. As a result these functions can fully reuse an existing ctx without having to allocate and free up memory all the time. The new functions can be called like this: EVP_CIPHER_CTX ctx; EVP_CIPHER_CTX_init(ctx); EVP_CipherInit_ex(ctx, ...); /* Update and final calls */ EVP_CipherInit_ex(ctx, ...); /* Other Update and final calls */ /* Possibly more EVP_*Init_ex() calls ... */ EVP_CipherFinal(ctx, ...); /* No more calls ... */ EVP_CIPHER_CTX_cleanup(ctx); Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Compilation with -DOPENSSL_NO_SOCK
Hi! I'm trying to adapt openssl-0.9.7a for Amoeba distributed system. There is no BSD socket api, so I have just turned it off by compiling without sockets. OPENSSL_NO_SOCK option referes to bss_conn.c in crypto/bio. In my opinion there is some kind of inconsistence because libs are compiling fine and test are not ssltest in example. How will effect on libssl that I have compiled it without bss_conn.c? Greets, Lucas [EMAIL PROTECTED] http://www.lucastm.republika.pl __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
No patch should be required, not even AIX can be that weird. An official specification for select() is available at http://www.opengroup.org/onlinepubs/007908799/xsh/select.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom
[bodo - Tue Apr 1 16:58:47 2003]: No patch should be required, not even AIX can be that weird. An official specification for select() is available at http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm This was the wrong link, I meant the www.opengroup.org link that appears my other message ... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Blinding patch and a recent snapshot.
On Mon, Mar 31, 2003 at 03:01:27PM -0500, Greaney, Kevin wrote: I downloaded a snapshot recently, openssl-e-0.9.6-stable-SNAP-20030327.tar.gz, and was comparing the files [.crypto.rsa]rsa_eay.c AND [.crypto.rsa]rsa_lib.c. I noticed that in rsa_eay.c that the patch used the positive when comparing, RSA_FLAG_BLINDING, and the snapshot used the negative, RSA_FLAG_NO_BLINDING. Here is the macro BLINDING_HELPER, and it shows the differences: [...] As for RSA_LIB.C, it looks like only part of the patch has been applied to the snapshot. [...] The missing changes to rsa_lib.c have been obviated by the other changes. (The OPENSSL_NO_FORCE_RSA_BLINDING compilation flag found in the patch no longer exists, but blinding now works when the PRNG has insufficient seeding, and this avoids a severe problem with having blinding always enabled.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Doc. relative to BN functions ?
Hi, I'm trying to understand the code that is written in openssl/crypto/bn. I have found some old documentation at http://www.columbia.edu/~ariel/ssleay/cryptosupp_index.html, but this is incomplete. I'd like to find some developer level documentation explaining how to use the BN_xxx functions, and basically how they are implemented. For instance: - what's the use of the BN_CTX structure ? Is it to maintain sort of a pool of BIGNUMs instead of always allocating new BIGNUMs ? what do the tos,pos, depth and too_many fields mean ? what's the correct way of using the BN_CTX_ functions (declare a BN_CTX * pointer, do a BN_CTX_start on it, retrieve an available buffer with BN_CTX_get...) - is there some explanation step by step of the bn_mod_exp_mont function (in bn_exp.c) ? I've got the reference algorithms of Montgomery just next to me (in chap 14 of Handbook of Applied Cryptography), but I'm quite lost at matching the steps with the actual coding. - the bn_mod_exp_mont() function uses a window. Is there a link to the sliding window technique the Handbook of Applied Crypto talks about ? Thanks Axelle. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Doc. relative to BN functions ?
Axelle Apvrille (LMC) wrote: Hi, I'm trying to understand the code that is written in openssl/crypto/bn. I have found some old documentation at http://www.columbia.edu/~ariel/ssleay/cryptosupp_index.html, but this is incomplete. I'd like to find some developer level documentation explaining how to use the BN_xxx functions, and basically how they are implemented. If you install OpenSSL 0.9.7 then you install several manual pages too. They are placed in sections 3. You can also go to openssl-0.9.7a/doc/crypto/ and use perldoc -F BN_*. Michael -- --- Michael Bell Email: [EMAIL PROTECTED] ZE Computer- und MedienserviceTel.: +49 (0)30-2093 2482 (Computing Centre)Fax: +49 (0)30-2093 2704 Humboldt-University of Berlin Unter den Linden 6 10099 Berlin Email (private): [EMAIL PROTECTED] Germany http://www.openca.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #561] bug report
Sirs:
I am using openssl v. 0.9.7a. I have compiled static libraries and am
trying to create an application that links to those libraries. I am
developing with Visual Studio .NET on Windows 2000.
I have found that just the single line
SSL_library_init();
produces a list of memory leaks from the compiler:
Detected memory leaks!
Dumping objects -
{178} normal block at 0x00317940, 12 bytes long.
Data: x1 GF0 78 31 00 00 00 00 00 47 8D DC E3
{177} normal block at 0x003178F0, 16 bytes long.
Data: IK IK 01 00 00 00 00 80 00 00 00 49 4B 00 20 49 4B
00
{176} normal block at 0x003178A8, 12 bytes long.
Data: Xx1 2 58 78 31 00 00 00 00 00 FB 32 1C 8F
{175} normal block at 0x00317858, 16 bytes long.
Data: IK IK 01 00 00 00 00 80 00 00 08 49 4B 00 20 49 4B
00
{174} normal block at 0x00317810, 12 bytes long.
Data: w1 C0 77 31 00 00 00 00 00 DE 8B 0B E0
{173} normal block at 0x003177C0, 16 bytes long.
Data: IK IK 01 00 00 00 00 80 00 00 10 49 4B 00 20 49 4B
00
{172} normal block at 0x00317778, 12 bytes long.
Data: (w1 x1 N` w 28 77 31 00 10 78 31 00 4E 60 84 77
{171} normal block at 0x00317728, 16 bytes long.
Data: !L !L 01 00 00 00 00 80 00 00 F8 21 4C 00 CC 21 4C
00
{170} normal block at 0x003176E0, 12 bytes long.
Data: v1 a90 76 31 00 00 00 00 00 61 EC C2 14
{169} normal block at 0x00317690, 16 bytes long.
Data: IK !L 01 00 00 00 00 80 00 00 20 49 4B 00 CC 21 4C
00
{168} normal block at 0x00317648, 12 bytes long.
Data: u1 P= F8 75 31 00 00 00 00 00 8A 50 3D 92
{167} normal block at 0x003175F8, 16 bytes long.
Data: !L }K 01 00 00 00 00 00 00 00 BC 21 4C 00 80 7D 4B
00
{166} normal block at 0x003175B0, 12 bytes long.
Data: `u1 J 60 75 31 00 00 00 00 00 C8 4A 9A 01
{165} normal block at 0x00317560, 16 bytes long.
Data: !L }K 01 00 00 00 00 00 00 00 CC 21 4C 00 80 7D 4B
00
{164} normal block at 0x00317518, 12 bytes long.
Data: t1 x1 k3 C8 74 31 00 A8 78 31 00 6B 33 3C 86
{163} normal block at 0x003174C8, 16 bytes long.
Data: ,IK IK 01 00 00 00 00 80 00 00 2C 49 4B 00 3C 49 4B
00
{162} normal block at 0x003161A8, 12 bytes long.
Data: s1 Mf B8 73 31 00 00 00 00 00 B4 4D 66 A0
{161} normal block at 0x00317408, 128 bytes long.
Data: h1 j1 @r1 00 00 00 00 B8 68 31 00 80 6A 31 00 40 72 31
00
{160} normal block at 0x003173B8, 16 bytes long.
Data: HIK TIK 01 00 00 00 00 80 00 00 48 49 4B 00 54 49 4B
00
{159} normal block at 0x00317370, 12 bytes long.
Data: s1n 20 73 31 00 00 00 00 00 F5 82 CC 6E
{158} normal block at 0x00317320, 16 bytes long.
Data: 'L TIK 01 00 00 00 00 80 00 00 FC 27 4C 00 54 49 4B
00
{157} normal block at 0x003172D8, 12 bytes long.
Data: r1 u1 hH 88 72 31 00 18 75 31 00 EB 68 48 10
{156} normal block at 0x00317288, 16 bytes long.
Data: IK TIK 01 00 00 00 00 80 00 00 3C 49 4B 00 54 49 4B
00
{155} normal block at 0x00317240, 12 bytes long.
Data: q1 C IT F0 71 31 00 00 00 00 00 43 E6 49 54
{154} normal block at 0x003171F0, 16 bytes long.
Data: (L }K 01 00 00 00 00 00 00 00 18 28 4C 00 D8 7D 4B
00
{153} normal block at 0x003171A8, 12 bytes long.
Data: Xq1 q1 qF 58 71 31 00 10 71 31 00 71 46 D1 F6
{152} normal block at 0x00317158, 16 bytes long.
Data: TIK }K 01 00 00 00 00 00 00 00 54 49 4B 00 D8 7D 4B
00
{151} normal block at 0x00317110, 12 bytes long.
Data: p1 Pi1 1 IR C0 70 31 00 50 69 31 00 31 E7 49 52
{150} normal block at 0x003170C0, 16 bytes long.
Data: \IK tIK 01 00 00 00 00 80 00 00 5C 49 4B 00 74 49 4B
00
{149} normal block at 0x00317078, 12 bytes long.
Data: (p1 u1 X28 70 31 00 B0 75 31 00 58 9D 14 03
{148} normal block at 0x00317028, 16 bytes long.
Data: hIK tIK 01 00 00 00 00 80 00 00 68 49 4B 00 74 49 4B
00
{147} normal block at 0x00316FD8, 12 bytes long.
Data: o1 r1 A 88 6F 31 00 D8 72 31 00 0B D3 41 1C
{146} normal block at 0x00316F88, 16 bytes long.
Data: 8-L tIK 01 00 00 00 00 80 00 00 38 2D 4C 00 74 49 4B
00
{145} normal block at 0x00316F40, 12 bytes long.
Data: n1 Hv1 ( F0 6E 31 00 48 76 31 00 0A 9A 28 EF
{144} normal block at 0x00316EF0, 16 bytes long.
Data: T-L tIK 01 00 00 00 00 80 00 00 54 2D 4C 00 74 49 4B
00
{143} normal block at 0x00316EA8, 12 bytes long.
Data: Xn1 a1 $P 58 6E 31 00 A8 61 31 00 24 50 9D 08
{142} normal block at 0x00316E58, 16 bytes long.
Data: -L P~K 01 00 00 00 00 00 00 00 9C 2D 4C 00 50 7E 4B
00
{141} normal block at 0x00316E10, 12 bytes long.
Data: m1 ps1 K 3 C0 6D 31 00 70 73 31 00 F5 4B 0D 33
{140} normal block at 0x00316DC0, 16 bytes long.
Data: tIK P~K 01 00 00 00 00 00 00 00 74 49 4B 00 50 7E 4B
00
{139} normal block at 0x00316D78, 12 bytes long.
Data: (m1 c1 [ O 28 6D 31 00 F8 63 31 00 5B BE 3C 4F
{138} normal block at 0x00316D28, 16 bytes long.
Data: `-L -L 01 00 00 00 00
Re: [openssl.org #561] bug report
In message [EMAIL PROTECTED] on Wed, 2 Apr 2003 09:23:17 +0200 (METDST), Matthew Fleming via RT [EMAIL PROTECTED] said: rt I am using openssl v. 0.9.7a. I have compiled static libraries and am rt trying to create an application that links to those libraries. I am rt developing with Visual Studio .NET on Windows 2000. rt rt I have found that just the single line rt rt SSL_library_init(); rt rt produces a list of memory leaks from the compiler: That's normal. What happens is that a table of error information, an object database and a few other things are being built up. Since you're not calling any cleanup stuff, you end up with a leak. This is not a bug, at least not in OpenSSL. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #561] bug report
In message [EMAIL PROTECTED] on Wed, 2 Apr 2003 09:23:17 +0200 (METDST), Matthew Fleming via RT [EMAIL PROTECTED] said: rt I am using openssl v. 0.9.7a. I have compiled static libraries and am rt trying to create an application that links to those libraries. I am rt developing with Visual Studio .NET on Windows 2000. rt rt I have found that just the single line rt rt SSL_library_init(); rt rt produces a list of memory leaks from the compiler: That's normal. What happens is that a table of error information, an object database and a few other things are being built up. Since you're not calling any cleanup stuff, you end up with a leak. This is not a bug, at least not in OpenSSL. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
