The attached patch adds Configure script support for VxWorks for PowerPC
860, fixes a compile problem with VxWorks builds, and fixes build problems
with no-md2.
diff -ur openssl-orig/Configure openssl-work/Configure
--- openssl-orig/Configure 2003-04-09 22:46:55.0 -0700
+++ openssl-work/Co
In message <[EMAIL PROTECTED]> on Wed, 24 Sep 2003 14:35:14 +0200, CHOVANEC Vladimír
<[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
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
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.
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 lookin
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: SSL_new
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
>
>
>
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
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 PKC
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
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?
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 interoperability with the NIST S/MIME test center
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 ri
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 ?
14 matches
Mail list logo