INSTALL.W32
228c228
$ copy /b inc32\* c:\openssl\include\openssl
---
$ copy /b inc32\openssl\* c:\openssl\include\openssl
__
OpenSSL Project
DSA is unencumbered... I'm not sure about CAST
On Thu, 2003-09-25 at 23:43, Boehme, Alfred wrote:
Hello,
I've been asked, if there is any known patent risk in the encryption algorithm of
OpenSSL ?
Especially
DSA, CAST-128, and CAST-256
was asked for.
Can someone help me here ?
DSA is public domain, CAST is an Entrust algorithm but I'm not sure if their
patent is still active.
Chris Brook
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Boehme, Alfred
Sent: Friday, September 26, 2003 1:44 AM
To: '[EMAIL PROTECTED]'
Subject: patent
I have an application using the OpenSSL S/MIME interface. When
I generate an encryptred message using DES, the DES key generated does not have
odd parity. The key is generated in pk7_doit.c:PKCS7_dataInit by
callingRAND_bytes().
In testing interoperability with the NIST S/MIME test center,
I would like to be able to add some of my own S/MIME signed
attributes based on characteristics of the message.
Could a callback procedure be added to
pk7_smime.c:PKCS7_sign() to support such a feature?
On Fri, Sep 26, 2003, Robin Ehrlich wrote:
I have an application using the OpenSSL S/MIME interface. When I generate an
encryptred message using DES, the DES key generated does not have odd
parity. The key is generated in pk7_doit.c:PKCS7_dataInit by calling
RAND_bytes().
In testing
On Fri, Sep 26, 2003, Robin Ehrlich wrote:
I would like to be able to add some of my own S/MIME signed attributes based
on characteristics of the message.
Could a callback procedure be added to pk7_smime.c:PKCS7_sign() to support
such a feature?
PKCS7_sign() is meant to be a simple PKCS#7
Regarding CAST, see http://www.ietf.org/ietf/IPR//CAST-128-entrust. BTW, section 8 of
RFC 3280 points to http://www.ietf.org/ipr.html.
Frank
And additionally http://www.ietf.org/ietf/IPR/CAST-256-entrust says the
same for CAST-256.
-Nathan
Frank Balluffi wrote:
Regarding CAST, see http://www.ietf.org/ietf/IPR//CAST-128-entrust. BTW, section 8
of RFC 3280 points to http://www.ietf.org/ipr.html.
Frank
Running an app that uses OpenSSL here through valgrind:
==10427== 6400 bytes in 200 blocks are definitely lost in loss record 4 of 4
==10427==at 0x40029888: calloc (vg_replace_malloc.c:273)
==10427==by 0x403C61C7: kssl_ctx_new (in /lib/libssl.so.0.9.7a)
==10427==by 0x403B8AE7:
I noticed a small inconsistency in OpenSSL.
According to the OpenSSL documentation, applications that want to
resume sessions should call SSL_CTX_set_session_id_context() to
provide a unique identifier to be stored with their session caches.
However, observing the behavior of OpenSSL and looking
On Fri, Sep 26, 2003, Verdon Walker wrote:
I noticed a small inconsistency in OpenSSL.
According to the OpenSSL documentation, applications that want to
resume sessions should call SSL_CTX_set_session_id_context() to
provide a unique identifier to be stored with their session caches.
Thanks for the information.
Verdon
Verdon Walker
(801) 861-2633
[EMAIL PROTECTED]
Novell, Inc., the leading provider of information solutions
http://www.novell.com
[EMAIL PROTECTED] 09/26/03 7:08 PM
On Fri, Sep 26, 2003, Verdon Walker wrote:
I noticed a small inconsistency in OpenSSL.
In message [EMAIL PROTECTED] on Wed, 24 Sep 2003 14:35:14 +0200, CHOVANEC Vladimr
[EMAIL PROTECTED] said:
Vladimir.CHOVANEC I would like to ask if any action has been taken
Vladimir.CHOVANEC as a result of request #558. We have mentioned
Vladimir.CHOVANEC AIX patch already installed
14 matches
Mail list logo