Re: Patch: cswift engine openssl-0.9.7c
Bonjour, En fait j'ai envoyé le patch sur [EMAIL PROTECTED] lundi dernier, mais ne voyant pas de ticket j'ai re-posté sur openssl-dev. Je dois vous avouer que je n'ai pas eu le temps d'étudier le code de votre engine. Cordialement, -- Frédéric Giudicelli http://www.newpki.org Frederic Donnat wrote: Bonjour, Je constate que vous avez pu resoudre le probleme! ;) J'espere que notre engine a pu vous aider. Belle analyse de votre part dans tous les cas! ;) Cependant cette restriction vient d'un probleme d'alignement 32bits du chip et donc driver, etc ... et je ne suis pas sur que votre patch reste valable sur platform 64bits (notamment avec les formata little et big endian) Cordialement, Donnat Frederic NetSecureOne http://www.netsecureone.com -Message d'origine- De : Frédéric Giudicelli [mailto:[EMAIL PROTECTED] Envoyé : Wednesday, February 11, 2004 2:31 PM À : [EMAIL PROTECTED] Objet : Patch: cswift engine openssl-0.9.7c Hi, There is a problem with the cswift engine: - in cswift_mod_exp_crt, it expects the length of dmp1 and dmq1 to be a multiple of 32, which is not always the case, the patch complements the datas with '\0' until the length is a multiple of 32. - in cswift_rand_bytes, it expects num to be a multiple of 32, which is not always the case, the patch make sure le length passed to p_CSwift_SimpleRequest is always a multiple of 32, by optionnaly using an intermetiade buffer. These problems have been notified to Rainbow, which has been able to reproduce the problem. The patch has been validated by their support service. Regards, __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: TLS session memory requirements
On Thu, Feb 12, 2004 at 08:42:39PM -0700, Sales, Randall S (Randall) wrote: Has anyone else had need to reduce TLS session memory footprint? When acting as server (Apache 2.0 running on Linux), I measure 57kB used after https session established, with peak memory use at 99kB (during establishment). A s_server/s_client TLS session shows slightly higher values. ./ssl/ssl3.h defines SSL3_RT_MAX_PLAIN_LENGTH as 16384. This #define is the basis of quite a few relatively large mallocs. Is 16384 a sacred number? What are the implications of reducing the value to 2048 or 4096? Would the change have any effect on functionality, stability, and/or performance? 16834 is part of the TLS standard: it is the largest chunk to be used for encrypted communication. You could reduce your chunk size for sending, but you have to reserve a buffer large enough for receival as your peer is still free to use the full chunk size. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #825] Patch: cswift engine openssl-0.9.7c
Hi, There is a problem with the cswift engine: - in cswift_mod_exp_crt, it expects the length of dmp1 and dmq1 to be a multiple of 32, which is not always the case, the patch complements the datas with '\0' until the length is a multiple of 32. - in cswift_rand_bytes, it expects num to be a multiple of 32, which is not always the case, the patch make sure le length passed to p_CSwift_SimpleRequest is always a multiple of 32, by optionnaly using an intermetiade buffer. These problems have been notified to Rainbow, which has been able to reproduce the problem. The patch has been validated by their support service. Regards, -- Frédéric Giudicelli [EMAIL PROTECTED] Tel : +33 (0)1 40 07 47 20 Fax : +33 (0)1 40 07 47 27 deny all - 5, rue Scribe - 75009 Paris - France www.deny-all.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #823] openssl 0.9.7c build fails
Thus saith Richard Levitte - VMS Whacker via RT: | | | In message [EMAIL PROTECTED] on Sun, 8 Feb 2004 18:31:16 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: | | rt fixed it by adding #include e_os.h to crypto/des/des_locl.h | rt and adding a link ../../e_os.h in include/openssl/ | | It's better if you add a '#include ../e_os.h' I just replicated what was done for #include openssl/e_os2.h in crypto/des/des_locl.h -- Bruce Becker+1 416 410 0879 GTS Network Administration Toronto, Ont. Email: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl smime -rand
On Thu, Feb 12, 2004 at 12:19:44PM +0100, Michael Bell wrote:
Hi,
I found a problem with openssl smime -rand filename. If I specify a
randfile then this file is not updated by apps/smime.c. The program
calls app_RAND_write_file with a NULL pointer even if a randfile was
specified. The result is that app_RAND_write_file in apps/app_rand.c
tries to get a filename via RAND_file_name from crypto/rand/randfile.c.
This function checks the environment variables RANDFILE and HOME or
falls back to the default position.
The problem is that this is a security issue because the randfile is
never updated. We (OpenCA) work on a batch system and for such systems
with high volumes of operations such a never changing random can be
really critical - or at minimum I believe this today. A fix could look
like this:
OLD:
if (need_rand)
app_RAND_write_file(NULL, bio_err);
NEW:
if (need_rand)
{
if (inrand != NULL)
app_RAND_write_file(inrand, bio_err);
else
app_RAND_write_file(NULL, bio_err);
}
If you agree that this is a bug then I forward it to rt.
I tend to disagree. The randfile can be the same thing as a .rnd file,
but it is actually intended to be used as a source only.
Consider the case of a process run by user root that will give
-rand /var/adm/syslog/syslog.log
as an option. This will give quite some entropy but...
Therefore ever changing entropy should be handled via .rnd file, which
_is_ updated.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #823] openssl 0.9.7c build fails
In message [EMAIL PROTECTED] on Sun, 8 Feb 2004 18:31:16 +0100 (MET), [EMAIL PROTECTED] via RT [EMAIL PROTECTED] said: rt fixed it by adding #include e_os.h to crypto/des/des_locl.h rt and adding a link ../../e_os.h in include/openssl/ It's better if you add a '#include ../e_os.h' - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 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]
