Hello all,
I've been tasked to internally investigate a system that utilizes
STunnel and OpenSSL to create a secure wrapper for a propietary
protocol. Additionally, this solution must eventually be FIPS 140-2
compliant.
So, using instructions outlined in the OpenSSL FIPS Security Policy
and on
If this needs to go to the dev list, let me know.
I am experiencing a SIGSEGV in BN_BLINDING_free because mt_blinding
appears to be 0x11 instead of a pointer to some memory.
I saw a reference to a similar problem back in 2003 [1], but I did not see a
resolution to it.
Any input would be greatly
Shabbir Bashir wrote:
Hi List,
Doing some research on http://nvd.nist.gov, I came across a "high"
vulnerability tagged CVE-2005-1797. I cannot seem to find out if this
is fixed in later versions after searching the net for an hour.
Summary of the above vulnerability is listed below, anyone has a
Hi List,
Doing some research on http://nvd.nist.gov, I came across a "high"
vulnerability tagged CVE-2005-1797. I cannot seem to find out if this
is fixed in later versions after searching the net for an hour.
Summary of the above vulnerability is listed below, anyone has any ideas ?
Summary:
"
Hello,
> It has several names: it is mentioned in PKCS#5 v1.5 section 6.2.
Yes, indeed. I must more carefully read documentation :-)
Best regards,
--
Marek Marcola <[EMAIL PROTECTED]>
__
OpenSSL Project
On Wed, 2006-06-07 at 14:59 +0530, Haridharan wrote:
> I built OpenSSL 0.9.7j with FIPS complaint in hp-ux IA64 architecture.
>
> For OpenSSL-fips-1.0.tar.gz, built options used is
>
> * ./Configure fips hpux64-ia64-cc
Not that according to the security policy, the only command allowed for
conf
On Wed, Jun 07, 2006, Marek Marcola wrote:
> Help,
>
> > The Openssl.org documentation states that ???all block ciphers normally
> > use PKCS#5 padding???.
> This must be some mistake, PKCS#5 is for Password Base key Derivation
> Functions (PBKDF) - not for padding.
>
It has several names: it i
Help,
> The Openssl.org documentation states that “all block ciphers normally
> use PKCS#5 padding”.
This must be some mistake, PKCS#5 is for Password Base key Derivation
Functions (PBKDF) - not for padding.
> The options
> that I have in C# are ANSIX923,ISO10126,NONE,PKCS7,ZEROS. Is this my
> pr
Help all,
I am trying to use an openssl script on an AIX box to
produce and encrypted packet. This packet will have to be
decrypted by a C# program. I am having any luck in getting
the C# program to decrypt the packet encrypted by
the AIX script.
The Openssl.org documentation stat
On Wed, Jun 07, 2006, Diarmuid Curtin wrote:
>
> You mention, Name constraints are not supported? So this means, if my
> certificate has Name constraints marked as Critical, OpenSSL will fail to
> validate the certificate ( as per RFC 3280 )
>
Not currently no. OpenSSL will reject such a certif
Hi Stephen,
You mention, Name constraints are not supported? So this means, if my certificate has Name constraints marked as Critical, OpenSSL will fail to validate the certificate ( as per RFC 3280 )
DC
On 6/7/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
On Wed, Jun 07, 2006, Diarmuid Cu
Thank you very much, it just slipped my mind.
It seems that another bug was triggering the wrong
OIDs in the certificates, and while I was testing my
encoding routine against openssl, I ran into this
false alarm.
Best Regards,
Enis
--- [EMAIL PROTECTED] wrote:
> Hi,
>
> Neither 3.3.3.33 or 5.5.
On Wed, Jun 07, 2006, Diarmuid Curtin wrote:
>
> Sorry to hi-jack this... Can I ask in what manner does it not support Bridge
> PKI's?
>
Well actually now I reread the message its path *validation* logic *may*
support bridge PKIs. That is where effectively a single path is presented to
OpenSSL
On Wed, Jun 07, 2006, [EMAIL PROTECTED] wrote:
> Hi,
>
> Neither 3.3.3.33 or 5.5.5.5.55 are valid OIDs, since
> the first component of an OID is always 0, 1, or 2.
> This restriction is built-in to BER/DER encoding.
>
and if you try to generate such a thing with OpenSSL it should reject the
at
Hi,
Neither 3.3.3.33 or 5.5.5.5.55 are valid OIDs, since
the first component of an OID is always 0, 1, or 2.
This restriction is built-in to BER/DER encoding.
Best regards,
Pasi
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of ext Enis Arif
> Sent
On 6/7/06, Enis Arif <[EMAIL PROTECTED]> wrote:
Hello,
I have a problem decoding certain OIDs with openssl. I
ran into this while parsing some certificates with
custom extensions. After some testing, I noticed that
OIDs like 3.3.3.33 or 5.5.5.5.55 are not correctly
decoded by asn1parse.
did yo
Hello,
I have a problem decoding certain OIDs with openssl. I
ran into this while parsing some certificates with
custom extensions. After some testing, I noticed that
OIDs like 3.3.3.33 or 5.5.5.5.55 are not correctly
decoded by asn1parse.
For example, OID:5.5.5.5.55 is der-encoded (not with
ope
Hi -
Sorry to hi-jack this... Can I ask in what manner does it not support Bridge PKI's?
Diarmuid
On 6/6/06, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote:
On Tue, Jun 06, 2006, Charlie Lenahan wrote:> Does OpenSSL's path validation logic support Bridge PKIs?
>Not at present, no.Steve.--Dr St
Hello,
zlib is not installed in HP-UX by default.
You can download zlib binary from
http://hpux.cs.utah.edu/hppd/hpux/Misc/zlib-1.2.3/ and install it.
or use Configure script with no-zlib option.
Best regard,
Yoshiki FUKUBA
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EM
Hi,
I built OpenSSL 0.9.7j with FIPS complaint in hp-ux IA64 architecture.
For OpenSSL-fips-1.0.tar.gz, built options used is
* ./Configure fips hpux64-ia64-cc
* make
* make install
For openssl-0.9.7j.tar.gz, built options used is
* ./Configure fips shared hpux64-ia64-cc
* make
I got this err
20 matches
Mail list logo
