RE: Disabling for FIPS mode, take 2

[Chris Brook]

Title: RE: Disabling for FIPS mode, take 2



I had 
heard that there were issues with the X9.31 implementation.  As I said we 
have got certs for both X9.31 and 186-2 so if you need anything let me 
know.  We could contribute the routines to OpenSSL if that would 
help.
Chris

  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On 
  Behalf Of Marquess, Steve Mr JMLFDCSent: Monday, July 12, 2004 
  10:34 AMTo: '[EMAIL PROTECTED]'Subject: RE: 
  Disabling for FIPS mode, take 2
  Chris Brook wrote: 
  >As far as I understand it, FIPS 140-2 requires that you 
  use a FIPS approved >RNG for generating keys (if 
  that's what you meant below).  This includes >ANSI X9.31 and FIPS 186-2, neither of which of course are supported 
  by >OpenSSL which has its own PRNG.  You might 
  want to look at adding these if >the FIPS effort is 
  the direction you're heading. We'd be happy to contribute >the routines, I think. 
  Actually the current FIPS PRNG is ANSI X9.31 (the comments 
  identify it as X9.17, but the actual algorithm 
  implementation is the same as for X.31).  I should also mention that we've had some thoughtful feedback pointing 
  out errors in the FIPS PRNG code with respect to 
  X9.17/X9.31, and are discussing the same with the test 
  lab; the final result will be X9.17/X9.31. 
  FIPS 186-2 would be nice, but at this point would require 
  testing which means $$$ (PRNG testing was not required 
  for our submission on 5-28, but new requirements have 
  since been imposed). 
  -Steve M. 
  Steve Marquess DMLSS Technical Manager 
  JMLFDC, 623 Porter Street, Ft. Detrick, MD  
  21702 DSN 343-3933, COM 301-619-3933, FAX 
  301-619-7831 [EMAIL PROTECTED] 
  

RE: Disabling for FIPS mode, take 2

[Chris Brook]

As far as I understand it, FIPS 140-2 requires that you use a FIPS approved
RNG for generating keys (if that's what you meant below).  This includes
ANSI X9.31 and FIPS 186-2, neither of which of course are supported by
OpenSSL which has its own PRNG.  You might want to look at adding these if
the FIPS effort is the direction you're heading. We'd be happy to contribute
the routines, I think.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dr. Stephen Henson
Sent: Friday, July 02, 2004 6:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Disabling for FIPS mode, take 2


On Fri, Jul 02, 2004, Jack Lloyd wrote:

> On Fri, Jul 02, 2004 at 10:51:52PM +0200, Dr. Stephen Henson wrote:
>
> [...]
> > OpenSSL already supports various private key formats which only use FIPS
> > approved algorithms, for example PKCS#8 with PKCS#5 v2.0. That means
that one
> > solution is to just change the behaviour of PEM_write_PrivateKey() and
friends
> > to call the PKCS#8 variants. The openssl pkcs8 utility can readily
convert
> > between the formats.
>
> I can't remember offhand, but doesn't OpenSSL also support RC2 with PKCS
#5
> v2.0? In theory you can use any algorithm you want with PKCS #5, as long
as you
> assign it an OID. Generally one uses 3DES with SHA-1, in which case you're
> clear (FIPS-wise), but RC2 or DES with MD5 is not uncommon.
>

Yes its possible to use just about anything with PKCS#5 v2.0 or more
specifically PBES2 provided the symmetric algorithm has an OID and an
appropriate AlgorithmIdentifier syntax defined.

There are a few cases which have an OID but OpenSSL doesn't support the
AlgID
such as RC4, RC5 and the feedback cipher modes.

PBES1 will only support a few modes specified by specific OIDs. PBES1 can't
generate enough keying material for algorithms with longer keys.

Its also possible to use PKCS#12 PBE algorithms with PKCS#8.

> Speaking of which, how does that work, in terms of the FIPS? When reading
in,
> say, a DSA key, if it happens to be encrypted with RC2, and you decrypt
the
> key, are you not FIPS-140 compliant anymore? Because it seems like if the
key
> was unencrypted you could still be FIPS compatible (for level 1, at
least).
>

Pass.

Another issue is whether FIPS-140 makes any restrictions on which key
derivation algorithms can be used. If it does then all bets are off.

> I do think this is a good idea in general. For one thing, PKCS #8 is
readable
> by pretty much everything (for some definitions of everything), while
OpenSSL's
> PEM-ish format is readable by OpenSSL and ...
>

Well I do know of a few things that read the traditional PEM encrypted
format,
Putty is one.

PKCS#8 is readable by many more applications but I'm not sure how many
support PBES2.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #904] Re: Segfault in speed measurements with aes ecb decrypt

[Chris Brook]

Changing the BUFSIZE had no effect on Solaris, it still crashed in
RSA_free().  It complained about insufficient seed size, so I added a
RAND_seed(). Now I don't need that any more.  Amazing how one small problem
can have so many side effects!
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte via
RT
Sent: Monday, June 28, 2004 12:34 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #904] Re: Segfault in speed measurements with aes
ecb decrypt



Good.  I also discovered that with this change, there was no need to
have an increased BUFSIZE any more.  The changes will be visible in
tomorrow's snapshot.

Ticket resolved.

[EMAIL PROTECTED] - Mon Jun 28 18:00:56 2004]:

> With your patch, the speed command now works fine on my Solaris build
of
> 0.9.7d (compiled using cc).
> Chris Brook
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte via
> RT
> Sent: Monday, June 28, 2004 8:51 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [openssl.org #904] Re: Segfault in speed measurements with
aes
> ecb decrypt
>
>
>
> A followup:
>
> [levitte - Mon Jun 28 14:33:57 2004]:
>
> > > At the end of the encryption process (in EVP_EncryptFinal_ex())
when
> > the last
> > > block is not fully used the rest of the buffer ctx->buf is filled
> > with
> > the
> > > number of remaining (unused) bytes.  This value is later on
> > extracted
> > during
> > > decryption in EVP_DecryptFinal_ex().  If only decryption is used,
> > then
> > the
> > > rest of the buffer is not filled with the padding value, hence the
> > error
> > > messages.
> > >
> > > This can be fixed as follows: buf_len is always = 0 when the
message
> > length is
> > > a multiple of the block size. Therefore we need to test when
> > decrypting the
> > > final block whether buf_len = 0. If so, we can not take the number
> > we
> > have
> > > left from the rest of the block as the block is full. The number
we
> > have left
> > > is zero then (See patch attached).
> >
> > Your patch is flawed.  At that point, there has been a test to check
> > if
> > ctx->buf_len is non-zero already, and an error is generated if it
is.
> > At the point of your patch, ctx->buf_len will *always* be zero.
> >
> > I think the real problem lies in apps/speed.c, which should set the
> > EVP_CIPH_NO_PADDING flag for the decrypt tests (at the very least).
> > The
> > speed difference will be very small.
>
> Please try the following patch, which did fix it for me:
>
> Index: apps/speed.c
> ===
> RCS file: /e/openssl/cvs/openssl/apps/speed.c,v
> retrieving revision 1.83.2.17
> diff -u -r1.83.2.17 speed.c
> --- apps/speed.c  28 Jun 2004 12:23:40 -  1.83.2.17
> +++ apps/speed.c  28 Jun 2004 12:49:24 -
> @@ -1399,6 +1399,7 @@
>   
> EVP_DecryptInit_ex(&ctx,evp_cipher,NULL,key16,iv);
>   else
>   
> EVP_EncryptInit_ex(&ctx,evp_cipher,NULL,key16,iv);
> + EVP_CIPHER_CTX_set_padding(&ctx, 0);
>
>   Time_F(START);
>   if(decrypt)
>
>
> --
> Richard Levitte
> [EMAIL PROTECTED]
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]
>
>
>
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]
>


--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #904] Re: Segfault in speed measurements with aes ecb decrypt

[Chris Brook]

With your patch, the speed command now works fine on my Solaris build of
0.9.7d (compiled using cc).
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte via
RT
Sent: Monday, June 28, 2004 8:51 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #904] Re: Segfault in speed measurements with aes
ecb decrypt



A followup:

[levitte - Mon Jun 28 14:33:57 2004]:

> > At the end of the encryption process (in EVP_EncryptFinal_ex()) when
> the last
> > block is not fully used the rest of the buffer ctx->buf is filled
> with
> the
> > number of remaining (unused) bytes.  This value is later on
> extracted
> during
> > decryption in EVP_DecryptFinal_ex().  If only decryption is used,
> then
> the
> > rest of the buffer is not filled with the padding value, hence the
> error
> > messages.
> >
> > This can be fixed as follows: buf_len is always = 0 when the message
> length is
> > a multiple of the block size. Therefore we need to test when
> decrypting the
> > final block whether buf_len = 0. If so, we can not take the number
> we
> have
> > left from the rest of the block as the block is full. The number we
> have left
> > is zero then (See patch attached).
>
> Your patch is flawed.  At that point, there has been a test to check
> if
> ctx->buf_len is non-zero already, and an error is generated if it is.
> At the point of your patch, ctx->buf_len will *always* be zero.
>
> I think the real problem lies in apps/speed.c, which should set the
> EVP_CIPH_NO_PADDING flag for the decrypt tests (at the very least).
> The
> speed difference will be very small.

Please try the following patch, which did fix it for me:

Index: apps/speed.c
===
RCS file: /e/openssl/cvs/openssl/apps/speed.c,v
retrieving revision 1.83.2.17
diff -u -r1.83.2.17 speed.c
--- apps/speed.c28 Jun 2004 12:23:40 -  1.83.2.17
+++ apps/speed.c28 Jun 2004 12:49:24 -
@@ -1399,6 +1399,7 @@

EVP_DecryptInit_ex(&ctx,evp_cipher,NULL,key16,iv);
else

EVP_EncryptInit_ex(&ctx,evp_cipher,NULL,key16,iv);
+   EVP_CIPHER_CTX_set_padding(&ctx, 0);

Time_F(START);
if(decrypt)


--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

FW: Segfault in speed measurements with aes ecb decrypt

[Chris Brook]

I tried it on a Solaris with cc and got the crash.  Changing the BUFSIZE did
not help (I tried doubling and quadrupling it).  The crash on Solaris
actually occurred in RSA_free() at the end and may be because error handling
is deficient in the earlier routines.
I was getting additional error messages that the PRNG had not been
adequately seeded.  I noticed that RAND_seed is called for DSA but not RSA
so added a RAND_seed() call at the start of MAIN() with a "fake" seed key
and the crash went away. I had seen this before in other areas: a SIGSEGV
fault if random seeding is not done (by the user app, obviously).
 I still got the EVP bad decrypt errors but you have explained that and I
will try your solution.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Roman Pletka
Sent: Wednesday, June 23, 2004 7:24 PM
To: Jack Lloyd
Cc: [EMAIL PROTECTED]
Subject: Re: Segfault in speed measurements with aes ecb decrypt




Jack Lloyd wrote:
> Hmm. If you increase BUFSIZE in speed.c, the segfaults go away, but it
still
> complains about bad decrypts.

Yes, increasing the buffer size fixes this.


> As for the bad decrypt errors - seems to be something else. If you modify
it to
> only test with 3 different buffer sizes, you get only three 'bad decrypt'
> errors. Suspicious.
>

At the end of the encryption process (in EVP_EncryptFinal_ex()) when the
last
block is not fully used the rest of the buffer ctx->buf is filled with the
number of remaining (unused) bytes.  This value is later on extracted during
decryption in EVP_DecryptFinal_ex().  If only decryption is used, then the
rest of the buffer is not filled with the padding value, hence the error
messages.

This can be fixed as follows: buf_len is always = 0 when the message length
is
a multiple of the block size. Therefore we need to test when decrypting the
final block whether buf_len = 0. If so, we can not take the number we have
left from the rest of the block as the block is full. The number we have
left
is zero then (See patch attached).

Thanks all of you guys who helped me on this!

-- Roman



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

FIPS 186-2

[Chris Brook]

Does the FIPS version of OpenSSL include either of the FIPS 186-2 PRNG's?
Or does it use ANSI X9.31's?
Chris Brook



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Inclusion of FIPS

[Chris Brook]

Title: RE: Inclusion of FIPS



I 
presume that running Known Answer Tests (KATs) on all crypto algorithms + PRNG 
is also required at startup, or is this included in 
FIPS-mode_set()?
Chris 
Brook

  -Original Message-From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On 
  Behalf Of Marquess, Steve Mr JMLFDCSent: Friday, May 14, 2004 
  8:44 AMTo: 'Richard Levitte - VMS Whacker'; 
  [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]; 
  [EMAIL PROTECTED]Subject: RE: Inclusion of 
  FIPS
  Richard Levitte wrote: 
  >So lets see, would libcrypto.so and libssl.so be 
  considered FIPS >certified or not?  Right now, 
  I can't really say...  Things like >"Catch 22" 
  come to mind... 
  It gets tediously complicated, so bear with me.  Along 
  with the FIPS 140 validation certificate, a document 
  called the "Security Policy" will be published.  
  This document describes the conditions under which an 
  application can claim to be "FIPS 140 validated". It 
  is over 50 pages long. 
  In *rough* summary, the conditions are: 
  1) The FIPS 140 validated source code (the 26 files with SHA1 
  HMAC digests as published in the Security Policy) must 
  be used to generate the libcrypto.a and/or 
  libcrypto.{so|sl}, using "./config fips ...".  A 
  SHA-1 HMAC of the library file is generated at this time. 
  2) The application must be linked against the 
  libcrypto.{a|so|sl} as generated above, and the SHA-1 
  HMAC of the library validated at build time.  For 
  static linking a SHA-1 HMAC of the entire application 
  executable is generated. 
  3) At runtime the application must call FIPS_mode_set() to 
  verify the SHA-1 HMAC of the entire application binary 
  (static linking) of the libcrypto.{so|sl} at the point 
  where the dlopen() with an explicit path occurs 
  (dynamic linking). 
  4) All cryptography is performed only using the FIPS mode 
  libcrypto library. 
  So, the application can claim FIPS 140 validation only if all 
  those conditions apply.  Link your application 
  without verifying the libcrypto.sha1 at build time, or 
  fail to call FIPS_mode_set(), and the result isn't 
  FIPS 140 validated even though essentially the same crypto code is executing.  
  Note libssl is considered by FIPS 140 to be "outside the cryptographic module boundary"; all the relevant 
  crypto code is in libcrypto.  The FIPS 140 
  validation, in fact, applies to only a subset of the 
  code in libcrypto -- the 26 files shown in the fingerprint.sha1 files in the openssl/fips/ tree. 
  -Steve M. 

RE: Security Hole - RSA 2?

[Chris Brook]

RSA keys are RSA keys regardless of how they are generated (assuming the key
gen code is correct).  You are asking the equivalent of: will Verisign-gen'd
keys work with Entrust-gen'd keys, for example?
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of C S
Sent: Tuesday, May 04, 2004 12:08 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Security Hole - RSA 2?


Is RSA ver 2 (SSH) compatiblity with SSL by design or
a given fact?  I haven't found any references anywhere
addressing this or any security concern.  In addition,
are there any downstream problems using a cert based
off of a ssh-keygen as opposed to an "openssl genrsa"?
 For example:


  ssh-keygen -trsa -b1024 -ftestid_rsa -N ""


  openssl req -new -key testid_rsa -out
testid_rsa.csr


Has anyone experimented with this?  It appears to work
and looks promising.


In other words would authenticate, encryption, digital
signatures, etc. certificate operations be normal
without an OpenSSL based key?  Just looking for a way
to "merge" the environments if possible on a single
key and not utilize a hole...


Thx,


cs





__
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #869] [FWD] [PATCH] OpenSSL patch for CRL Distribution Points for the X.509 Certificate Profile

[Chris Brook]

I incorporated these patches in 0.9.7d STABLE and compiled using the Solaris
native compiler instead of gcc.  There were several errors because variable
definitions were placed after allocation statements, e.g.
+   for (i = 0; i < sk_CONF_VALUE_num(nval); i++) {
+   cnf = sk_CONF_VALUE_value(nval, i);
+   STACK_OF(CONF_VALUE) *sk;
I can list the corrections (about 12) or, more appriately, the author can
re-issue the patch with the necessary corrections so that it follows
standard C rules rather than C++.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Stephen Henson via RT
Sent: Thursday, April 08, 2004 4:02 AM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #869] [FWD] [PATCH] OpenSSL patch for CRL
Distribution Points for the X.509 Certificate Profile



- Forwarded message from Abhijit Hayatnagarkar
<[EMAIL PROTECTED]> -

Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Date: Mon, 5 Apr 2004 16:38:13 -0400 (EDT)
From: Abhijit Hayatnagarkar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [PATCH] OpenSSL patch for CRL Distribution Points for the X.509
 Certificate Profile
Precedence: bulk
Reply-To: [EMAIL PROTECTED]

Description of the patch:

This patch provides the extended syntax for CRL Distribution Points as
specified in RFC 3280 Section 4.2.1.14.  It also tries to maintain
backward compatibility with the existing syntax.

Without this crld patch, the syntax for the X509 extension field "CRL
Distribution Points" recognized by openssl is either:

crlDistributionPoints=URI:http://uri.crl.com/crl1,URI:http://uri.crl.com/crl
2

or

[EMAIL PROTECTED]

[crlsection]
URI.1=http://uri.crl.com/crl1
URI.2=http://uri.crl.com/crl2

Thus, you can only specify the 'fullname' field of a single distribution
point.

With this crld patch, openssl will support a richer syntax for the "CRL
Distribution Points" extension field.  Apart from 'fullname', you will be
able to specify the 'relativename', 'reasons' and 'CRLissuer' fields.

This patch is backward compatible, so you will still be able to use the
old syntax.

The 'reasons' field is a bitmap of ReasonFlags.  The ReasonFlags are:
unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3),
superseded (4), cessationOfOperation (5), certificateHold (6),
privilegeWithdrawn (7) and aAcompromise (8).

Users can now specify CRL Distribution Points with a syntax as detailed as
the following:

[EMAIL PROTECTED],@distpoint2

[distpoint1]
fullname=URI:http://uri.crl.com/crl1,URI:http://uri.crl.com/crl2
reasons=keyCompromise,cACompromise

[distpoint2]
[EMAIL PROTECTED]
reasons=cessationOfOperation,privilegeWithdrawn
CRLissuer=email:[EMAIL PROTECTED]

[relnamesect]
C   = US
O   = Org, Inc.
0.OU= Org Unit 1
1.OU= Sub Org Unit 2
CN  = relative common name

Thanks,
Abhijit Hayatnagarkar
Sparta, Inc.

A copy of the TSU Notification sent to [EMAIL PROTECTED] is attached
below.  This notification also included the patches attached to this
email.

-- Forwarded message --
Date: Mon, 5 Apr 2004 16:21:57 -0400 (EDT)
From: Abhijit Hayatnagarkar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: TSU Notification

SUBMISSION TYPE : TSU
SUBMITTED BY: Abhijit Hayatnagarkar
SUBMITTED FOR   : Sparta, Inc.
POINT OF CONTACT: Abhijit Hayatnagarkar
PHONE and/or FAX: (410) 872-1515 Ext. 236
MANUFACTURER:
PRODUCT NAME/MODEL #: Patches for OpenSSL version 0.9.7c and SNAP-20040227
ECCN: 5D002
NOTIFICATION: Source code for the patch attached.

Short Description:
This patch provides the extended syntax for CRL Distribution
Points in the X.509 Certificate Profile as specified in RFC 3280 (See:
http://www.ietf.org/rfc/rfc3280.txt).

Content-Description: A patch to openssl 0.9.7c for the extended syntax for
CRL Distribution Points
diff -ur openssl-0.9.7c/crypto/x509v3/v3_crld.c
openssl-0.9.7c.modified/crypto/x509v3/v3_crld.c
--- openssl-0.9.7c/crypto/x509v3/v3_crld.c  2001-02-23
07:47:05.0 -0500
+++ openssl-0.9.7c.modified/crypto/x509v3/v3_crld.c 2004-04-05
15:55:24.0 -0400
@@ -63,8 +63,23 @@
 #include 
 #include 

-static STACK_OF(CONF_VALUE) *i2v_crld(X509V3_EXT_METHOD *method,
-   STACK_OF(DIST_POINT) *crld, STACK_OF(CONF_VALUE) *extlist);
+static ENUMERATED_NAMES crl_reasons[] = {
+{0, "Unused", "unused"},
+{1, "Key Compromise", "keyCompromise"},
+{2, "CA Compromise", "cACompromise"},
+{3, "Affiliation Changed", "affiliationChanged"},
+{4, "Superseded", "superseded"},
+{5, "Cessation Of Operation", "cessationOfOperation"},
+{6, "Certificate Hold", "certificateHold"},

RE: OpenSSL 0.9.7c Pocket PC 2003 Compile Error

[Chris Brook]

Following up on this Pocket PC2003 problem report for any other developers
who have encountered similar problems, we have contacted Microsoft and got a
workaround as listed below.
We applied the #pragma to "rs2_setkey.c" and everything now compiles and
runs correctly.

--
>From Microsoft tech support:

I am able to see the problem here. The problem is with the optimizer for
ARMV4. The specific optimizations that cause the problem are in the global
optimizations. This is being considered for a fix in a future release of the
compiler. For the current release, we have a workaround as follows.

Turn off the global optimizations for the specific block of code that is
suspected to throw up this compiler error. You can do this by placing the
block of "suspect" code within

#pragma optimize( "g", off )
.
. // suspect code here
.
#pragma optimize( "g", on )

If using the above concept, you can keep all optimizations turned on for the
rest of your project.

-----

Hopes this helps.
Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Steven Reddie
Sent: Thursday, March 18, 2004 7:49 PM
To: [EMAIL PROTECTED]
Subject: RE: OpenSSL 0.9.7c Pocket PC 2003 Compile Error


Hi Chris,

I haven't seen that particular error before, but I have seen reports of
problems with PPC2003.  Try removing the /Gs0 option from the makefile are
rebuild.  It will probably be somewhere under wcecompat or OpenSSL's util,
util/pl, or ms directories.

Regards,

Steven

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Chris Brook
Sent: Friday, 19 March 2004 8:00 AM
To: Openssl-Dev (E-mail)
Subject: OpenSSL 0.9.7c Pocket PC 2003 Compile Error


When compiling OpensSSL 0.9.7c for Pocket PC 2003 using Microsoft EVC 4.0
SP2 with ARMV4 CPU option, we got the following compilation error sequence:

clarm.exe /Fotmp32_ARMV4\rc2_skey.obj  -Iinc32 -Itmp32_ARMV4 /W3 /WX /Ox /O2
/Ob2 /Gs0 /GF /Gy /nologo -DWCEPLATFORM=MS_POCKET_PC_2003 -DARM
-DUNDER_CE=420 -D_WIN32_CE=420 -DUNICODE -D_UNICODE -DWIN32 -D_WIN32
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD
-Ic:\openssllib\openssl-0.9.7c-WinCE\wcecompat/include /Fdout32_ARMV4
-DOPENSSL_NO_KRB5  -c .\crypto\rc2\rc2_skey.c

Command line warning D4002 : ignoring unknown option '/Gs0' rc2_skey.c
c:\openssllib\openssl-0.9.7c-wince\crypto\rc2\rc2_skey.c(137) : fatal error
C1001: INTERNAL COMPILER ERROR (compiler file
'D:\vcmckendric\compiler\utc\src\P2\main.c', line 148) Please choose the
Technical Support command on the Visual C++ Help menu, or open the Technical
Support help file for more information NMAKE : fatal error U1077:
'clarm.exe' : return code '0x2' Stop.

Has anybody else tried compiling Pocket PC2003 with 0.9.7c?  Any problem
like this?  Any suggested solution?

Chris Brook
V-ONE



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL 097d compile error in WinCE build

[Chris Brook]

I did 
not see any RT posting for this bug report.  Did I just miss it?  If 
so, humble apologies.
Chris 
Brook
 Openssl 097d with WinCE build has syntax 
error.    clarm.exe 
/Fotmp32_ARM\apps.obj -DMONOLITH -Iinc32 -Itmp32_ARM /W3 /WX /Ox /O2 /Ob2 /Gs0 
/GF /Gy /nologo -DWCEPLATFORM=MS_POCKET_PC_2000 -DARM -D_ARM_ -DUNDER_CE=300 
-D_WIN32_CE=300 -DUNICODE -D_UNICODE -DWIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD 
-Ih:\wcecompat/include /Fdout32_ARM -DOPENSSL_NO_KRB5  -c 
.\apps\apps.capps.c.\apps\apps.c(1621) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1896) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1932) : error C2143: syntax error : 
missing ')' before 'goto'NMAKE : fatal error U1077: 'clarm.exe' : return 
code '0x2'Stop.OpenSSL 097d has 
   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR)#endif    
      goto err;It is supposed to 
be   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR#endif )         goto 
err;

RE: a bug in RSA_public_encrypt with RSA_NO_PADDING

[Chris Brook]

IMHO, this thread has got to the level of nits within nits within nits :-)
The issue was addressed very well by an earlier response.  At the most a
sentence or two in the man page is needed.  RSA is the way it is and the
implementation is correct.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Richard Levitte - VMS
Whacker
Sent: Thursday, March 25, 2004 11:21 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: a bug in RSA_public_encrypt with RSA_NO_PADDING


In message <[EMAIL PROTECTED]> on Thu, 25 Mar 2004
11:09:42 -0500, Geoff Thorpe <[EMAIL PROTECTED]> said:

geoff> On March 25, 2004 10:44 am, Richard Levitte - VMS Whacker wrote:
geoff> > To begin with, I think the correct interpretation is that the
output
geoff> > buffer is required to have the same size as the modulus, so
logically,
geoff> > an output size parameter isn't required except for checking
purposes.
geoff>
geoff> Well yes, my point had been that the output size is the only size
geoff> parameter in the prototype. That's perhaps indicative of the state of
geoff> affaires. :-)

Uhmm, say what?  Currently, the only size parameter is the input size
(flen).  We're still talking about the RSA_{public,private}_encrypt()
functions, right?

geoff> > I guess that allowing an input size that's smaller than the modulus
geoff> > size could be doable, but isn't adviceable for security reasons or
geoff> > something like that...
geoff>
geoff> Well it could all be handled relative to the padding
geoff> parameters, the issue again is that the API isn't exposed in
geoff> this form and changing it involves ... well, you know very well
geoff> what that involves. 

Actually, I don't, but give me some time to re-read the thread, 'cause
I've obviously missed something...

geoff> I think this is just one of those things that doesn't warrant
geoff> us messing with it right now - if someone cares enough, they
geoff> could clarify the relevant docs.

I've already made a small change that explains what's expected when
RSA_NO_PADDING is used...

-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

--
Richard Levitte   \ Tunnlandsvägen 52 \ [EMAIL PROTECTED]
[EMAIL PROTECTED]  \ S-168 36  BROMMA  \ T: +46-708-26 53 44
\  SWEDEN   \
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]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

FW: OpenSSL 097d compile error in WinCE build

[Chris Brook]

Sorry 
I hit send accidentally.  Let's try again.
We 
also tried compiling without the /Gs0 option as Steven Reddie suggested and that 
made no difference.
Chris 
BrookOpenssl 097d with WinCE build has syntax 
error.    clarm.exe 
/Fotmp32_ARM\apps.obj -DMONOLITH -Iinc32 -Itmp32_ARM /W3 /WX /Ox /O2 /Ob2 /Gs0 
/GF /Gy /nologo -DWCEPLATFORM=MS_POCKET_PC_2000 -DARM -D_ARM_ -DUNDER_CE=300 
-D_WIN32_CE=300 -DUNICODE -D_UNICODE -DWIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD 
-Ih:\wcecompat/include /Fdout32_ARM -DOPENSSL_NO_KRB5  -c 
.\apps\apps.capps.c.\apps\apps.c(1621) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1896) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1932) : error C2143: syntax error : 
missing ')' before 'goto'NMAKE : fatal error U1077: 'clarm.exe' : return 
code '0x2'Stop.OpenSSL 097d has 
   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR)#endif    
      goto err;It is supposed to 
be   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR#endif )         goto 
err;

OpenSSL 097d compile error in WinCE build

[Chris Brook]

 Openssl 097d with 
WinCE build has syntax error.    
clarm.exe /Fotmp32_ARM\apps.obj -DMONOLITH -Iinc32 [Chris 
Brook]  Itmp32_ARM /W3 /WX /Ox /O2 /Ob2 /Gs0 /GF /Gy 
/nologo -DWCEPLATFORM=MS_POCKET_PC_2000 -DARM -D_ARM_ -DUNDER_CE=300 
-D_WIN32_CE=300 -DUNICODE -D_UNICODE -DWIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD 
-Ih:\wcecompat/include /Fdout32_ARM -DOPENSSL_NO_KRB5  -c 
.\apps\apps.capps.c.\apps\apps.c(1621) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1896) : error C2143: syntax error : 
missing ')' before 'goto'.\apps\apps.c(1932) : error C2143: syntax error : 
missing ')' before 'goto'NMAKE : fatal error U1077: 'clarm.exe' : return 
code '0x2'Stop.OpenSSL 097d has 
   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR)#endif    
      goto err;It is supposed to 
be   if (errno != ENOENT#ifdef  
ENOTDIR          && errno != 
ENOTDIR#endif )         goto 
err;Thanks,Yunhee Cheong

OpenSSL 0.9.7c Pocket PC 2003 Compile Error

[Chris Brook]

When compiling OpensSSL 0.9.7c for Pocket PC 2003 using Microsoft EVC 4.0
SP2 with ARMV4 CPU option, we got the following compilation error sequence:

clarm.exe /Fotmp32_ARMV4\rc2_skey.obj  -Iinc32 -Itmp32_ARMV4 /W3
/WX /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DWCEPLATFORM=MS_POCKET_PC_2003
-DARM -DUNDER_CE=420 -D_WIN32_CE=420 -DUNICODE
-D_UNICODE -DWIN32 -D_WIN32 -DWIN32_LEAN_AND_MEAN
-DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD
-Ic:\openssllib\openssl-0.9.7c-WinCE\wcecompat/include /Fdout32_ARMV4
-DOPENSSL_NO_KRB5  -c .\crypto\rc2\rc2_skey.c

Command line warning D4002 : ignoring unknown option '/Gs0'
rc2_skey.c
c:\openssllib\openssl-0.9.7c-wince\crypto\rc2\rc2_skey.c(137) : fatal
error C1001: INTERNAL COMPILER ERROR
(compiler file 'D:\vcmckendric\compiler\utc\src\P2\main.c', line 148)
Please choose the Technical Support command on the Visual C++ Help menu,
or open the Technical Support help file for more information
NMAKE : fatal error U1077: 'clarm.exe' : return code '0x2'
Stop.

Has anybody else tried compiling Pocket PC2003 with 0.9.7c?  Any problem
like this?  Any suggested solution?

Chris Brook
V-ONE



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: openssl cert policy handling

[Chris Brook]

I suspect that there will shortly be plenty of interest, at least on the
U.S. side, as the US Gov and DoD in particular are pushing hard into the
world of PKI.  That means compliance testing of all the path processing
stuff which of course includes the policies and constraints aforementioned.
So if you are feeling motivated...
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Dr. Stephen Henson
Sent: Monday, February 23, 2004 5:23 PM
To: [EMAIL PROTECTED]
Subject: Re: openssl cert policy handling


On Mon, Feb 23, 2004, Chris Brook wrote:

> Is there any support in crypto->x509(v3) for certificate policy
> processing/checking as described in X.509 or PKIX?  I had a quick look
> through the code but did not see anything?  Or is it planned since it is
> required for some of the PKI compliance tests?
> This gets pretty complex with pathLengthConstraints, Name Constraints,
User
> and Authority Constrained policies.  Perhaps someone is planning a
> contribution.

Not that I know of. I was asked about the possibility of adding support by
someone last year. After lots of discussions nothing happened. I haven't
heard anything more for a couple of months.

I could resurrect it if there was sufficient interest.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

openssl cert policy handling

[Chris Brook]

Is there any support in crypto->x509(v3) for certificate policy
processing/checking as described in X.509 or PKIX?  I had a quick look
through the code but did not see anything?  Or is it planned since it is
required for some of the PKI compliance tests?
This gets pretty complex with pathLengthConstraints, Name Constraints, User
and Authority Constrained policies.  Perhaps someone is planning a
contribution.
Chris Brook



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: patent risk in encryption algotithm ?

[Chris Brook]

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 risk in encryption algotithm ?


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 ?

Thanks in advance

Alfred
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: FIPS mode

[Chris Brook]

Item #2: typically FIPS-140 certified code is delivered as a binary, tested
by a lab and checked at both source and binary level, so the opportunity to
modify is not there (DAC test will fail).  With OpenSSL source that's not
the case unless the developer of the product (who creates the binaries) gets
it checked/certified by a lab as part of their product.  Obviously if I lie
and say my product is certified and it's not, I can but that's pretty stupid
since the product will be listed on NIST's site as certified if it is.  Will
NIST list the OpenSSL crypto library on their site?
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ben Laurie
Sent: Friday, September 05, 2003 2:02 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: FIPS mode


Chris Brook wrote:

> If I read your reply right, responsibility for DAC and Known Answer Test
> checking is the responsibility of the app developer, though you will
provide
> the DAC checksum for the crypto module.  Have you also included the KATs,
> since they essentially exist the OpenSSL test modules?

_Everything_ is included.

> Since OpenSSL is providing source code (which presumably includes the DAC
> checksum generation code), what's to prevent a user modifying the crypto
> code and regenerating the checksum?

Nothing. What's to prevent you claiming you're using FIPS-140 certified
stuff and not doing so? Nothing. That's not the way it works.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: FIPS mode

[Chris Brook]

If I read your reply right, responsibility for DAC and Known Answer Test
checking is the responsibility of the app developer, though you will provide
the DAC checksum for the crypto module.  Have you also included the KATs,
since they essentially exist the OpenSSL test modules?
Since OpenSSL is providing source code (which presumably includes the DAC
checksum generation code), what's to prevent a user modifying the crypto
code and regenerating the checksum?
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ben Laurie
Sent: Friday, September 05, 2003 5:56 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: FIPS mode


Verdon Walker wrote:
> After reviewing the email archives for both the developer and user
> groups, I have a lot of questions:

Answers in quotes were written by someone else, answers not in quotes
are my own.

> - What platforms are being FIPS certified?

"The formal test platform is HP-9000/HP-UX 11i.  However, NIST/CSE are
certifying the software at the source code level (a first) and have
stated that when the certified source is merely recompiled for another
platform the FIPS-140 certification still applies."

> - Is it FIPS 140-2?

"Yes, FIPS-140-2 level 1"

> - What version of OpenSSL does it correspond to? 0.9.7b?

"Yes, and the FIPS specific routines will be carried forward in future
OpenSSL releases.  Only the "cryptographic module" containing the
relevant cryptographic module implementations is certified, not the
larger OpenSSL distribution which can change without affecting the
certification."

What I've done is to make copies of the code that constitute the
cryptographic module, and use those instead of the base versions. This
allows two things to be done. Firstly, the base distribution can be
changed without affecting FIPS certification. Secondly, it means changes
required by FIPS can be isolated in the certified code. For example,
FIPS requires an approved PRNG, but I am not up for replacing OpenSSL's
PRNG with X9.17 except in FIPS mode.

> - Are both the static libraries and dynamic libraries to be certified?
> If not, which?

"Both (or neither); the certification is at the source code level.  As
long as the "pedigree" of the certified source is tracked through the
process of generating and referencing build-time and run-time code the
FIPS-140 certification applies."

There are checksums for the certified source included. The build process
checks them, then generates a checksum for the resulting library. An
application wishing to use the FIPS version of OpenSSL should check the
library checksum before linking, then generate a checksum for itself
after linking. This checksum should then be checked at startup. I will
be adding more support for this process soon.

Applications do need minor modification to switch on FIPS mode (it is
optional, even in the FIPS build of OpenSSL, by design), and also
typically to avoid using unapproved algorithms (which in general don't
work in FIPS mode). I've been considering having it optionally (at build
time, of course) start out switched on, but given that very few apps can
actually run correctly in FIPS mode without some modification, the
motivation for that is not huge.

> - What is the strategy for introducing bug fixes into the FIPS
> OpenSSL?

"NIST permits some degree of modification without requiring a
re-certification, based on a vendor affirmation of the extent of
changes.  The "vendor" for this purpose for OpenSSL will be the Open
Source Software Institute (http://www.oss-institute.org/) which has
coordinated the FIPS-140 certification effort.  Extensive changes to the
cryptographic algorithms will require certification.  The "cryptographic
module" containing these algorithm implementations has been segregated
within the OpenSSL distribution in order to maximize the validity of the
FIPS-140 certification."

> Basically, I would like to know a lot more about what has happened so
> far, where the certification process is, etc. The threads in the email
> archives basically show that doing the work was discussed, but not
> really settled. Then suddenly a note that the code has been moved to its
> own branch and now this message saying it's almost too late to have any
> input. What happened to the discussion about the ongoing work?

The discussion about the ongoing work has been mostly amongst the team
doing the work, of which only I am involved in OpenSSL development.
Unfortunately, this is almost entirely conducted in conference calls.
There was also a desire on the part of the sponsors of the project to
keep its profile low until we were close to certification, for reasons
that I hope are obvious.

Nevertheless the code showing the approach was posted many weeks ago,
not sprung on you just now, with only a few weeks t

RE: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use /dev/urandom

[Chris Brook]

select() expects the first parameter to contain the number of fd's to be
checked in all flavours of Unix.
Andreas is confusing the number of fd's to be checked (n) with the numbering
of fd's (0 -(n-1)).
This may explain some bugs :-)
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Lutz Jaenicke via RT
Sent: Monday, March 31, 2003 1:56 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #558] Patch Openssl 0.9.7a for AIX 5.2 to use
/dev/urandom



On Mon, Mar 31, 2003 at 10:54:31AM +0200, [EMAIL PROTECTED] via
RT wrote:
> Since 5.2 AIX supports /dev/random and /dev/urandom. Openssl don't use it
> because the select
> system call works different on AIX than on linux.
>
> As described in the following URL, the select system call expects the
> number
> of file describtors as first parameter in AIX. Linux expects the highst
> numbered
> fd +1.
>
>
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select
..htm

Are you sure? select() is around since UNIX exists, that means the early
70s,
maybe longer. I am not that good when it comes to UNIX history :-)

I would not believe that IBM would break more or less all programs by
chaning the select() API in an incompatible way.

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 Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Debian Bug Tracker

[Chris Brook]

Can you please remove from the forwarding list whatever it is that is
causing a response to the whole list from "Debian Bug Tracker"?  I am
getting flooded !
Thanks
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

0.9.7 Beta 6 testing with WinCE

[Chris Brook]

We have built and tested 0.9.7 Beta 6 with the following WinCE devices:
HPC Pro 2.11
HPC 2000
PocketPC 2000
PocketPC 2002
All build, link and run fine except that, for HPC Pro 2.11, the WCE
Compatibility Library contains two functions that need to be deleted before
linking; currently we do this manually.  The functions are '_iswctype' and
'_towupper' which, in HPC Pro 2.11, are provided in the system libraries,
resulting in multiply defined errors when we link.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

0.9.7 Beta 6 testing

[Chris Brook]

Built and tested on RedHat 8 with gcc3.2 - no problems.
Chris Brook
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

OpenSSL 0.9.7 Beta 6

[Chris Brook]

Built and tested Beta 6 on Sun Ultra with Solaris, using Workshop 6 update
1, with no problems.
3 compilation warnings in crypto/ec:
ec.h:162, ec.h:165, ec_lcl.h:126  "warning: parameter has incomplete type"
Changed  EC_POINT *[] to  EC_POINT ** in those lines and warnings
disappeared.

Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #353] 0.9.7 B5 testssl with no-dh fails

[Chris Brook via RT]

These tests within "testssl" still fail with 0.9.7 Beta 5 if OPENSSL_NO_DH
is included in the Configure options, when "make tests" is run.
Suggested fix is attached (though this may be auto-created).
Chris Brook


###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1

  if ../apps/openssl no-dh; then
echo skipping RSA 1024bit DHE tests
  else
echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
  fi
fi
##



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #353] 0.9.7 B5 testssl with no-dh fails

[Chris Brook]

These tests within "testssl" still fail with 0.9.7 Beta 5 if OPENSSL_NO_DH
is included in the Configure options, when "make tests" is run.
Suggested fix is attached (though this may be auto-created).
Chris Brook


###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1

  if ../apps/openssl no-dh; then
echo skipping RSA 1024bit DHE tests
  else
echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
  fi
fi
##



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

[Chris Brook via RT]

Whoops! I sent a bad suggested fix for this.  This should be better.
Chris Brook


###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1

  if ../apps/openssl no-dh; then
echo skipping RSA 1024bit DHE tests
  else
echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
  fi
fi
##



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

[Chris Brook]

Whoops! I sent a bad suggested fix for this.  This should be better.
Chris Brook


###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1

  if ../apps/openssl no-dh; then
echo skipping RSA 1024bit DHE tests
  else
echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
  fi
fi
##



__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

[Chris Brook via RT]

I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion.  This is the last section of the script:

###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1
fi

if ../apps/openssl no-dh; then
  echo skipping 1024bit DHE tests
else
  echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
fi
##

Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook via RT
Sent: Wednesday, November 20, 2002 3:36 PM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails



I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but "ssltest" fails when trying to run the "-dhe1024*" tests.  A fix
was added in Beta 3 to handle the -dhe1024 & -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
"make test" does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails

[Chris Brook]

I played around with the testssl script in the tests directory and the
following change seems to take care of the no-dh issue so that the tests run
to completion.  This is the last section of the script:

###
if ../apps/openssl no-dh; then
  echo skipping anonymous DH tests
else
  echo test tls1 with 1024bit anonymous DH, multiple handshakes
  $ssltest -v -bio_pair -tls1 -cipher ADH -dhe1024dsa -num 10 -f -time
$extra || exit 1
fi

if ../apps/openssl no-rsa; then
  echo skipping RSA tests
else
  echo test tls1 with 1024bit RSA, no DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -no_dhe -num
10 -f -time $extra || exit 1
fi

if ../apps/openssl no-dh; then
  echo skipping 1024bit DHE tests
else
  echo test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes
  ./ssltest -v -bio_pair -tls1 -cert ../apps/server2.pem -dhe1024dsa -num
10 -f -time $extra || exit 1
fi
##

Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook via RT
Sent: Wednesday, November 20, 2002 3:36 PM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #353] 0.9.7 B4 testssl with no-dh fails



I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but "ssltest" fails when trying to run the "-dhe1024*" tests.  A fix
was added in Beta 3 to handle the -dhe1024 & -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
"make test" does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: DES CBC Error in 0.9.7 B4

[Chris Brook]

I set the plaintext and ciphertext strings to 32 characters as below and
test_evp is now OK, encrypt/decrypt.
Chris Brook

// DES CBC tests (from destest)
"DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F7720697320746
8652074696D6520666F72200031:ccd173ffab2039f4acd8aefddfd8a1eb468e91157888
ba68b706462c7a95ca8d",



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie
Sent: Tuesday, November 26, 2002 8:40 AM
To: [EMAIL PROTECTED]
Subject: Re: DES CBC Error in 0.9.7 B4


Chris Brook wrote:
> Forget my previous email.  destest is actually only passing 29 bytes I
see,
> so the predicted ciphertext will of course be wrong if I pass 32 bytes for
> encryption.

So what was the correct test entry in the end?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #357] Shared in 0.9.7 B4

[Chris Brook]

I have figured out why these are now being pulled in - a change was made
unknown to me in our code which triggered it.
Please close this bug report and accept my humble apologies.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook via RT
Sent: Friday, November 22, 2002 4:35 AM
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #357] Shared in 0.9.7 B4



Has something changed in the make process in beta 4 regarding shared
libraries?  I am building OpenSSL with the same shell script on my Solaris
(see below), using Workshop/Forte 6, as I did with Beta 3 versions and now I
get unreferenced symbols: dlclose, dlsym, dlopen, etc.  I can get around it
by including -ldl in my app makefiles but I never had to in the past.  I
have "shared" in my Configure command line and this, as usual, produces
libcrypto.a and libcrypto.so.  I only use libcrypto.a when building my apps,
so why is it suddenly needing the dso/dl stuff?  My last B3 build was the
20021025 snapshot.  My app makefiles have not changed.  My Configure command
line is:

/Configure threads shared no-asm no-hw no-ripemd no-idea no-bf no-cast
no-dh no
-mdc2 no-rc2 no-rc5 debug-solaris-sparcv9-cc

Any advice much appreciated.
Chris Brook


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #357] Shared in 0.9.7 B4

[Chris Brook via RT]

Has something changed in the make process in beta 4 regarding shared
libraries?  I am building OpenSSL with the same shell script on my Solaris
(see below), using Workshop/Forte 6, as I did with Beta 3 versions and now I
get unreferenced symbols: dlclose, dlsym, dlopen, etc.  I can get around it
by including -ldl in my app makefiles but I never had to in the past.  I
have "shared" in my Configure command line and this, as usual, produces
libcrypto.a and libcrypto.so.  I only use libcrypto.a when building my apps,
so why is it suddenly needing the dso/dl stuff?  My last B3 build was the
20021025 snapshot.  My app makefiles have not changed.  My Configure command
line is:

../Configure threads shared no-asm no-hw no-ripemd no-idea no-bf no-cast
no-dh no
-mdc2 no-rc2 no-rc5 debug-solaris-sparcv9-cc

Any advice much appreciated.
Chris Brook


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Shared in 0.9.7 B4

[Chris Brook]

Has something changed in the make process in beta 4 regarding shared
libraries?  I am building OpenSSL with the same shell script on my Solaris
(see below), using Workshop/Forte 6, as I did with Beta 3 versions and now I
get unreferenced symbols: dlclose, dlsym, dlopen, etc.  I can get around it
by including -ldl in my app makefiles but I never had to in the past.  I
have "shared" in my Configure command line and this, as usual, produces
libcrypto.a and libcrypto.so.  I only use libcrypto.a when building my apps,
so why is it suddenly needing the dso/dl stuff?  My last B3 build was the
20021025 snapshot.  My app makefiles have not changed.  My Configure command
line is:

../Configure threads shared no-asm no-hw no-ripemd no-idea no-bf no-cast
no-dh no
-mdc2 no-rc2 no-rc5 debug-solaris-sparcv9-cc

Any advice much appreciated.
Chris Brook


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

DES CBC Error in 0.9.7 B4

[Chris Brook]

Forget my previous email.  destest is actually only passing 29 bytes I see,
so the predicted ciphertext will of course be wrong if I pass 32 bytes for
encryption.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

DES CBC Error in 0.9.7 B4

[Chris Brook]

I added the DES CBC test vectors in destest.c to test/evptests.txt thus:

# DES CBC tests (from destest)
DES-CBC:0123456789abcdef:fedcba9876543210:37363534333231204E6F77206973207468
652074696D6520666F72200031:ccd173ffab2039f4acd8aefddfd8a1eb468e91157888b
a681d269397f7fe62b4

which corresponds to the C code format, except I changed the cbc_data string
length to 32 instead of 40.  Since destest actually passes 32 and cbc_ok is
32 in length, this should be fine.  When I run "make test_evp", it fails
with exit(9) on this entry ("Ciphertext mismatch", the last 8 bytes of
ciphertext are wrong).   If I change the size to 24, it works fine.  Yet 32
appears to work fine in destest.  What am I missing? I thought any multiple
of 8 bytes should work OK.
Oh, I see that destest actually passes 40 bytes (32 + 8 zero's) for
encryption and then checks 32 bytes of ciphertext.  Is this a padding thing?
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #353] 0.9.7 B4 testssl with no-dh fails

[Chris Brook via RT]

I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but "ssltest" fails when trying to run the "-dhe1024*" tests.  A fix
was added in Beta 3 to handle the -dhe1024 & -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
"make test" does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

0.9.7 B4 testssl with no-dh fails

[Chris Brook]

I have compiled OpenSSL 0.9.7 Beta 4 with the NO-DH option.  The compilation
is fine but "ssltest" fails when trying to run the "-dhe1024*" tests.  A fix
was added in Beta 3 to handle the -dhe1024 & -dhe1024dsa parameters when
NO-DH was used but ssltest still tries to run and fails with:

ERROR in CLIENT
22172:error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers
available:s3_clnt.c:569:

It would seem that the DH tests should be skipped altogether if the NO-DH
option is used, rather than trying to run and failing.  The result is that
"make test" does not complete.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [PATCH] Windows CE support for 0.9.7 (against 20021114 snapshot)

[Chris Brook]

We have built Steven's "patch" successfully for PocketPC and PocketPC 2002.
The issue is the many different hardware versions it needs to be compiled
for.  With the makefile approach (Steven's), a separate build has to be done
for each CPU type - a somewhat labour-intensive exercise :-) Martin
Erdrich's patch included an MS project file that let one build all N
versions at one time. Any suggestions on how this can be handled in OpenSSL?
If one is only building a specific CPU, the makefile is fine, but most
developers/vendors will build for a larger set of CPU's.
Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev@;openssl.org]On Behalf Of Richard Levitte - VMS
Whacker
Sent: Friday, November 15, 2002 2:41 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PATCH] Windows CE support for 0.9.7 (against 20021114
snapshot)


Thanks!  Looks good for the most part, the only thing that's just
"non-traditional" is the direct use of OPENSSL_SYSNAME_WINCE, but
that's easily taken care of.

Oh, yeah, is there any reason to keep VC-CE.pl (as opposed to
util/pl/VC-CE.pl)?

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: 0.9.7 B3 AES CFB Stream Encryption

[Chris Brook]

Here the URL that gives you the NIST AVS (Algorithm Validation Suite) for
AES.
http://csrc.nist.gov/cryptval/aes/AESAVS.pdf
I have a program that implements the tests that I can send you, along with
their test data, if that would help.
Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev@;openssl.org]On Behalf Of Richard Levitte - VMS
Whacker
Sent: Friday, November 15, 2002 9:54 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: 0.9.7 B3 AES CFB Stream Encryption


In message <001f01c28cb2$cbbd3fc0$[EMAIL PROTECTED]> on Fri, 15 Nov 2002
09:25:05 -0500, "Chris Brook" <[EMAIL PROTECTED]> said:

cbrook> I had reported earlier that using the 20021027 snapshot of
cbrook> 0.9.7, the NIST AESAVS Monte Carlo tests fail for AES-128 in
cbrook> CFB mode with 1 byte (8 bit) data blocks, but got no response.

Sorry, I thought I responded to you as well as everyone else that was
listening to the thread where this was discussed.

Could you point at the exact document that describes the test?  I'd
certainly like to fix that before the final beta if not before beta 4.

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

0.9.7 B3 AES CFB Stream Encryption

[Chris Brook]

I had reported earlier that using the 20021027 snapshot of 0.9.7, the NIST
AESAVS Monte Carlo tests fail for AES-128 in CFB mode with 1 byte (8 bit)
data blocks, but got no response.  My understanding from the previous
threads on this topic (data block sizes v. key block sizes) was that this
should encrypt/decrypt correctly now, after the padding bug was fixed.
Since it apparently doesn't, stream encryption against non-OpenSSL
implementations will fail.  Are there any plans to address this before Beta
4?
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

AES-128 CFB Mode with 8-bit data blocks

[Chris Brook]

I re-ran the NIST AES Validation Tests with 0.9.7 Beta3 Snapshot 20021027
which purports to have fixed the padding problem and so should handle 8-bit
(1 octet) data blocks with AES-128 (and AES-192 and AES-256) in CFB Mode.
The basic tests which all use 16 byte data blocks still work fine, but the
Monte Carlo tests which use 8-bit data blocks still fail, i.e. the OpenSSL
result does not match the predicted result, at even the first iteration.
Should I manually turn off padding?
I am using the sequence:
EVP_CipherInit() + EVP_Cipher()  for the first iteration,
then just EVP_Cipher() for the following ones of the 999 iterations.
Would it make any difference if I went down to EVP_CipherUpdate() instead of
EVP_Cipher() with an EVP_CipherFinal() after the last iteration?
I haven't seen any problems with stream encryption/decryption using AES CFB
mode but then I am talking between my own machines, all with the same code.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Windows CE Patch for OpenSSL 0.9.6g

[Chris Brook]

Great.  We'll give a thorough checkout before including it in our product.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev@;openssl.org]On Behalf Of Steven Reddie
Sent: Wednesday, November 06, 2002 7:43 AM
To: [EMAIL PROTECTED]
Subject: RE: Windows CE Patch for OpenSSL 0.9.6g


Sure, I've spent far, far too many hours on this so I'm not going to throw
it away.  I've just finished tying up the last loose ends with redirecting
stdin/stdout/stderr between the desktop and Windows CE device which is
needed for the automated tests.  I should be able to send something in the
next day or so.

Regards,

Steven

-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev@;openssl.org]On Behalf Of Richard Levitte - VMS
Whacker
Sent: Wednesday, 6 November 2002 2:06 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Windows CE Patch for OpenSSL 0.9.6g


In message <[EMAIL PROTECTED]> on Wed, 6 Nov
2002 01:45:57 +1100, "Steven Reddie" <[EMAIL PROTECTED]> said:

smr> I'm a few days away from submitting my patch.  It looks like
smr> we've done quite similar work which I guess isn't surprising
smr> since we've both had to plug the holes in the Windows CE CRT
smr> implementation.  My approach differs in that I've seperated out
smr> this compatibility layer into a seperate library since it will be
smr> generally useful to other Windows CE development projects.
[...]

I'd appreciate it if my response to Martin didn't discourage you from
contributing your patch.

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Open/Seal problem

[Chris Brook]

I am using EVP_Open, EVP_Seal to exchange information in several iterations,
i.e open message 1, seal response 1, open message 2, seal response 2 using
the same keys, etc (same EVP_CIPHER_CTX).  I can do EVP_OpenInit,
OpenUpdate,OpenFinal followed  EVP_SealUpdate, EVP_SealFinal which works
fine, but EVP_OpenUpdate,OpenFinal on the next message fails because the
ctx->encrypt flag is set to 1 by SealFinal.  Setting ctx->encrypt to 0
(decrypt) before doing OpenUpdate makes it all work nicely; I can also do
EVP_EncryptInit(ctx, NULL,NULL,NULL,0) which works fine.  So I thought to be
safe I had better do EVP_EncryptInit(,1) before the SealUpdate but it
doesn't like that at all!  Is the code set to do one Open/Seal pair
automatically (looks like it)?  Or did I just get lucky the first time?  Is
the response to a response regarded as illegal (works in RSA ref)?  Is there
a bug in here somewhere?
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl 0.9.7-beta3

[Chris Brook]

Is this now fixed for EVP_Encrypt() and EVP_Decrypt() or only the
xxInit,xxUpdate,xxFinal sequences?  Or must I set padding off?
If this is resolved, I can go back and rerun the NIST AES certification
tests for CFB with 8 bit block sizes.  Needless to say they failed before.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:owner-openssl-dev@;openssl.org]On Behalf Of John Viega via RT
Sent: Thursday, October 17, 2002 7:18 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #306] EVP_xxx_{cfb,ofb} problems in openssl
0.9.7-beta3



Yes, it does indeed seem to be fixed.  Seeing that OFB and CFB are
pretty fundamental, shouldn't a fix like that merit a b4 release,
particularly considering how long it's been since b3? :)

John

On Thursday, October 17, 2002, at 05:34 PM, Richard Levitte - VMS
Whacker wrote:

> In message <[EMAIL PROTECTED]>
> on Thu, 17 Oct 2002 16:34:55 -0400, John Viega
> <[EMAIL PROTECTED]> said:
>
> viega> Perhaps it would help to show you how things work differently
> in 0.9.6
> viega> and 0.9.7.  Try this code out in each one:
> viega>
> viega> #include 
> viega>
> viega> int main(int argc, char **argv) {
> viega>EVP_CIPHER_CTX c;
> viega>char key[128] = {0,};
> viega>char iv[128] = {0,};
> viega>char in[256]={0,};
> viega>char out[256];
> viega>int olen,i, o2;
> viega>
> viega> #define CIPHER() EVP_bf_cfb()
> viega> #define HOWMANY 148
> viega>EVP_EncryptInit(&c, CIPHER(), (char *)key, iv);
> viega>EVP_EncryptUpdate(&c, out, &olen, in, HOWMANY);
> viega>EVP_EncryptFinal(&c, out+olen,&o2);
> viega>olen += o2;
> viega>printf("Olen = %d\n", olen);
> viega>for(i=0;i viega>  printf("%02x ", (unsigned char)out[i]);
> viega>}
> viega>printf("\n");
> viega> }
> viega>
> viega> This returns 148 in 0.9.6, and it returns 152 in 0.9.7 (b3 at
> least).
> viega> The same thing happens in OFB mode.  What's going on is that
> PKCS
> viega> padding is getting added when it never was previously.
>
> Ah, yeah, right, that's a bug in beta3.  It has been fixed, however.
> Please try the latest 0.9.7 snapshot, and you'll see the difference.
>
> --
> Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken  \ 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]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: NIST AES Validation

[Chris Brook]

Sorry for the confusion.  To re-phrase my original question: should AES128,
in CFB mode, work OK with a block size of 1 octet (i.e. 8 bits of data)?
Chris

-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 6:28 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: NIST AES Validation


In message <002301c26e4f$6528ce40$[EMAIL PROTECTED]> on Mon, 7 Oct 2002
18:17:58 -0400, "Chris Brook" <[EMAIL PROTECTED]> said:

cbrook> No, I wasn't confusing block size with key size.  I did say
cbrook> plaintext size of 16 :-)

You wrote that, and you used the terms CFB128, CFB192 and CFB256,
which basically would mean CFB mode with 128, 192 and 256 bits
feedback blocks.  That's at least how I understand the terminology.
Basically, what you wrote was a little bit confusing.

Now that you've shown that what you meant was AES128, AES192 and
AES256, things get a bit clearer.  The block size of CFB mode, for any
algorithm, is independent of the key size.  That same goes for all the
other modes.  Therefore, one can safely say that all the modes will
work with any AES key size.

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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: NIST AES Validation

[Chris Brook]

No, I wasn't confusing block size with key size.  I did say plaintext size
of 16 :-)
Are you saying that AES192 and AES256 will not work in CFB mode?  Is the
same true for ECB, CBC and OFB?  I have been using CFB, ECB amd CBC with all
3 key sizes for some time and had no apparent problem.  Have I just been
lucky?
Chris Brook

-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 6:11 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: NIST AES Validation


In message <002201c26e4b$7d3568d0$[EMAIL PROTECTED]> on Mon, 7 Oct 2002
17:50:00 -0400, "Chris Brook" <[EMAIL PROTECTED]> said:

cbrook> I agree that CFB1 and CFB8 are not too useful.  But I presume
cbrook> that CFB128, CFB192 and CFB256 with plaintext sizes of 16
cbrook> octets or greater should be OK?

Only AES CFB-128 is implemented, as I said.  CFB-192 and CFB-256 makes
me think you're mixing up block size (which is *always* 128 bits for
AES) with key size (which can 128, 192 or 256 bits, as defined
currently, although the algorithm is allegedly designed for any size
key).  You're not the first to mix that up, and you will probably not
be the last either.

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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: NIST AES Validation

[Chris Brook]

I agree that CFB1 and CFB8 are not too useful.  But I presume that CFB128,
CFB192 and CFB256 with plaintext sizes of 16 octets or greater should be OK?
Chris Brook

-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 4:17 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: NIST AES Validation


In message <001101c26e28$d85e6f90$[EMAIL PROTECTED]> on Mon, 7 Oct 2002
13:42:01 -0400, "Chris Brook" <[EMAIL PROTECTED]> said:

cbrook> I have been running the NIST AES Algorithm Validation Suite
cbrook> (AVS) using the OpenSSL crypto library and all the results for
cbrook> all the modes come out as predicted, except for CFB 1-bit
cbrook> which is not supported by OpenSSL and CFB 8-bit which returns
cbrook> a "wrong" result.  CFB 128-bit is fine.

No surprise there, only CFB-128 is implemented.  If you look at other
algorithms that also implement a CFB mode, you will see that only the
CFB variant with the same feedback blocksize as the algorithm in
question is implemented.  That's how Eric Young did it, and honestly,
I didn't find any reason for doing it differently for AES, as it seem
like the existing implementations are all that are used in SSL (which
is basically what sets the first requirements).

If you can point out where there would be a practical use for 1-bit or
8-bit CFB, we might reconsider.

--
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken  \ 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]

NIST AES Validation

[Chris Brook]

I have been running the NIST AES Algorithm Validation Suite (AVS) using the
OpenSSL crypto library and all the results for all the modes come out as
predicted, except for CFB 1-bit which is not supported by OpenSSL and CFB
8-bit which returns a "wrong" result.  CFB 128-bit is fine.  The pertinent
tests here are the Monte Carlo Tests.  I was wondering if anyone else had
run these using OpenSSL and got the predicted result for CFB 8-bit.  Or is
this a problem in the OpenSSL implementation?  It's always possible that
there is a bug in my test vehicle but this is the only failing case.
Perhaps single octet values aren't handled correctly?  I am using
EVP_CipherInit() and EVP_cipher() for the actual encrypt/decrypt functions.
Any help/comments much appreciated.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: FIPS 140-2 certification

[Chris Brook]

We have got FIPS 140-1 certification using the OpenSSL crypto library and I
believe there are other VPN vendors who have done this. A lot of it is
documentation.  On the code side, you must use only approved encryption and
hash algorithms: 3DES (DES) and SHA-1 (not MD5).  AES obviously has been
added for FIPS 140-2.  Random number seeding must use ANSII X9.17; we have
added this outside the crypto library, I think our only addition.  There are
some procedural/self-checking requirements: all modules inside the "crypto
boundary" (you define that) must run a self-check code integrity test at
startup (typically running DES decryption to get a checksum and comparing
that to a known checksum that goes with the release), and a known answer
test at startup on all crypto algorithms to verify that they are working OK.
Hope this helps.  The cost in the US for Level 1 (software only)
certification testing is about $50,000.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie
Sent: Saturday, September 28, 2002 7:33 AM
To: [EMAIL PROTECTED]
Subject: Re: FIPS 140-2 certification


Nathan Bardsley wrote:
> Hello everyone!
>
> I work for a company that uses OpenSSH/OpenSSL to remotely support
> systems we've sold.  Since some of our clients are US Dept. of Defense
> hospitals, our access to these servers needs to comply with a whole
> range of requirements and standards.  At this point it's looking like
> the SSH daemon needs to be FIPS 140-2 compliant, and the only package
> that is certified is F-Secure.
>
> The other option is for CliniComp to sponser getting OpenSSH/OpenSSL
> through the certification process, and that's what I'm exploring.
>
> I'd really appreciate knowing what the core developers think about this,
> and how willing they would be to assisting in the process.  I know there
> will need to be a fair amount of documentation, and there is no
> subsitute for first-hand knowledge.  Also, it seems pretty clear that at
> least some code changes will be needed including self-tests, a new prng,
> and work in the key generation & validation modules.
>
> While we (CliniComp) do have some resources including technical writers
> and programmers, we certainly do not have the expertise in cryptography
> to just do it all ourselves.  And if this does happen, part of the point
> would be for the necessary changes to be rolled back into the standard
> package.
>
> Please understand that right now I'm just exploring possibilities, but
> the other option for us is to spend a lot of money on F-Secure licenses.
>
> I would very much appreciate hearing your thoughts and from anyone else
> interested in making this happen.

I'm interested, and would certainly support it. Of course, any changes
made would have to fit in with our general view of the world, but unless
FIPS 140-2 is completely broken I don't see why that would be a problem.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

ssltest.c

[Chris Brook]

In 0.9.7-stable ssltest.c, lines 408 & 416 need terminating brackets.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: PBEParams

[Chris Brook]

Thanks, much cleaner.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dr. Stephen Henson
Sent: Monday, September 23, 2002 6:13 PM
To: [EMAIL PROTECTED]
Subject: Re: PBEParams


On Mon, Sep 23, 2002, Chris Brook wrote:

> I am converting some code from BSAFE to OpenSSL, using 0.9.7 beta 3, and
> have an issue with the PKCS#5 PBEParameters encoding/decoding.  In BSAFE,
> the algorithm ObjId is included in the PBEParameters encoding with an
outer
> SEQUENCE.  In OpenSSL it is not.  I can manually add strip off the algo
> ObjId and Seqence to get at the real PBE Params but this is a pain.  Is
> there a d2i/id2 that will encode/decode the PBEParams Info Object with the
> algo in it?

Yes X509_ALGOR: its equivalent to AlgorithmIdentifier.

Steve.
--
Dr. Stephen Henson  [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

PBEParams

[Chris Brook]

I am converting some code from BSAFE to OpenSSL, using 0.9.7 beta 3, and
have an issue with the PKCS#5 PBEParameters encoding/decoding.  In BSAFE,
the algorithm ObjId is included in the PBEParameters encoding with an outer
SEQUENCE.  In OpenSSL it is not.  I can manually add strip off the algo
ObjId and Seqence to get at the real PBE Params but this is a pain.  Is
there a d2i/id2 that will encode/decode the PBEParams Info Object with the
algo in it?
Thanks,
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: SSL-0.9.7 RSA keys

[Chris Brook]

I have found the problem and fixed it in my code, so please ignore.
However, for general info, it seems that the i2d_ low-level functions modify
the data pointer passed in (it is an unsigned char **), so I could not see
the result.  Copying the pointer to another and passing the address of that
in solves the problem.  I had come across this with decoding so I guess it's
a global quirk in the code!
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Brook
Sent: Friday, September 20, 2002 10:08 AM
To: Openssl-Dev (E-mail)
Subject: SSL-0.9.7 RSA keys


Using 0.9.7 beta 3, I am attempting to output an RSA public/private key pair
created by RSA_generate_key() as ASN.1 encoded strings.
For the public key, I am using i2d_RSA_PUBKEY which calls i2d_PUBKEY ->
i2d_X509_PUBKEY.  i2d_X509_PUBKEY seems to execute though I can't find the
code anywhere in the source.  It returns a correct length but the result
string is empty - all zero's.
I am using i2d_PKCS8_PRIV_KEY_INFO() to get the ASN.1 encoded private key as
a PKCS8 PrivateKeyInfo.  This behaves the same way: returns length but empty
value.  In both cases the data structures were correctly set up with good
values.  Is the problem that these are phantom functions?  I get no error
during compiling or linking, so where are they
Is there a better way to do this?  The opposite functionality using d2i_
works just fine.
Chris Brook
V-ONE

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

SSL-0.9.7 RSA keys

[Chris Brook]

Using 0.9.7 beta 3, I am attempting to output an RSA public/private key pair
created by RSA_generate_key() as ASN.1 encoded strings.
For the public key, I am using i2d_RSA_PUBKEY which calls i2d_PUBKEY ->
i2d_X509_PUBKEY.  i2d_X509_PUBKEY seems to execute though I can't find the
code anywhere in the source.  It returns a correct length but the result
string is empty - all zero's.
I am using i2d_PKCS8_PRIV_KEY_INFO() to get the ASN.1 encoded private key as
a PKCS8 PrivateKeyInfo.  This behaves the same way: returns length but empty
value.  In both cases the data structures were correctly set up with good
values.  Is the problem that these are phantom functions?  I get no error
during compiling or linking, so where are they
Is there a better way to do this?  The opposite functionality using d2i_
works just fine.
Chris Brook
V-ONE

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Why does OpenSSL_add_all_algorithms() exist?

[Chris Brook]

Those of us who make heavy use of the crypto library, with a limited group
of algorithms and without SSL, would certainly not want this pulling in all
the algorithms every time we call EVP_PKEY_new.
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, September 19, 2002 10:16 AM
To: [EMAIL PROTECTED]
Subject: Why does OpenSSL_add_all_algorithms() exist?


Can anyone explain why this routine exists?  When would you *not* want
this?  Is there any reason not to, say, call those routines from within
EVP_PKEY_new ?
/r$
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

d2i_PUBKEY question

[Chris Brook]

I notice when using d2i_PUBKEY() to convert a string RSA
SubjectPublicKeyInfo to an EVP_PKEY struct that the string pointer ends up
pointing to random memory.  Is this deliberate (e.g. for security reasons)
or a bug?  I would like to have the public key string still available when
the function returns (without copying and restoring every time).
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #223] Length error in EVP_DecodeBlock

[Chris Brook]

How about adding a high-level function in 0.9.7 a la SHA1() and MD5(), for
example EVP_Decode() and EVP_Encode()?  I suspect that a majority if base 64
encodes/decodes are on a single chunk so the Init/Update/Final/defining EVP
context mechanism is overkill at the app level.
Chris Brook


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte via
RT
Sent: Thursday, August 15, 2002 5:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #223] Length error in EVP_DecodeBlock



[[EMAIL PROTECTED] - Wed Aug 14 22:36:47 2002]:

> EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of
the
> result
> of the base-64 decode.  However this length is not the true length
of
> the
> result but includes any trailing fills ('=') so it's always 0 mod
3.
> This
> obviously can cause errors in any processing on the result, e.g.
> decryption.
> I would suggest that adding something like:
>   while (*--f == '=')
>   --ret;
> immediately before the "return(ret);" would solve the problem.

Well, depends.  If you consider that EVP_DecodeBlock() really just
is a helper function for EVP_DecodeUpdate(), the implementation is
correct, and you're change would actually break EVP_DecodeUpdate()
as well as any call to EVP_DecodeBlock() that expects the current
behavior.  You see, EVP_DecodeUpdate() checks for the final '=' and
decreases the final length accordingly.  You need to do the same.

This ticket is resolved.

--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Length error in EVP_DecodeBlock

[Chris Brook]

EVP_DecodeBlock() [in crypto/evp/encode.c] returns the length of the result
of the base-64 decode.  However this length is not the true length of the
result but includes any trailing fills ('=') so it's always 0 mod 3.  This
obviously can cause errors in any processing on the result, e.g. decryption.
I would suggest that adding something like:
while (*--f == '=')
--ret;
immediately before the "return(ret);" would solve the problem.
Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #216] Bugs in OPENSSL-0.9.7 beta 3

[Chris Brook]

I understand the manual side. I was wondering if there is any way to make
the option conditional in testssl.com so you don't have to mod the code.  Or
should I just comment out the lines I don't want?
Sorry to be a nuisance.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte
via RT
Sent: Tuesday, August 13, 2002 2:21 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #216] Bugs in OPENSSL-0.9.7 beta 3



[[EMAIL PROTECTED] - Tue Aug 13 00:08:25 2002]:

> To see what would happen next, I added a
> #else
> else if (strcmp(*argv, "-dhe1024dsa") == 0) {}
> in the option test sequence.  It now runs all the tests quite
happily but
> crashes with several error lines in the cleanup code. Progress!
> Back to you :-)

Yes, of course.  However, the test commands are designed to be run
manually as well, and in that case, the behavior you complained
about is correct.

Perhaps one should have an extra option '-ignore-unknown-options' or
something like that, which would cancel the error reporting in cases
like this...

--
Richard Levitte
[EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: [openssl.org #216] Bugs in OPENSSL-0.9.7 beta 3

[Chris Brook]

To see what would happen next, I added a
#else
else if (strcmp(*argv, "-dhe1024dsa") == 0) {}
in the option test sequence.  It now runs all the tests quite happily but
crashes with several error lines in the cleanup code. Progress!
Back to you :-)
Chris Brook

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte via
RT
Sent: Monday, August 12, 2002 5:23 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [openssl.org #216] Bugs in OPENSSL-0.9.7 beta 3



I have solved problems 1 and 3.  Problem 2 was will take a little
bit of pondering.

[[EMAIL PROTECTED] - Mon Aug 12 18:34:58 2002]:

> 1. In rmdtest.c:
> If I build with OPENSSL_NO_RIPEMD and rmdtest.c fails to compile
because
> openssl/ripemd.h cannot be found.
> The line "#include "  needs to be moved AFTER
the "#else"
> of "#ifndef OPENSSL_NO_RIPEMD".
>
> 2. In ssltest.c:
> If I build with OPENSSL_NO_DH, I will get a failure message:
>   "unknown option -dhe1024dsa"
> when running
>   "test sslv2/sslv3 with 1024bit DHE via BIO pair" in
testssl.com.
>
> 3. bn won't compile in a Windows environment using VC++ 6.0/SP5
because of a
> problem with 'bn.h' which uses the VC++ 6.0/SP5 class template
name,
> 'modulus'.
>
> Chris Brook
>
>
__
> OpenSSL Project
http://www.openssl.org
> Development Mailing List
[EMAIL PROTECTED]
> Automated List Manager
[EMAIL PROTECTED]


--
Richard Levitte
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Bugs in OPENSSL-0.9.7 beta 3

[Chris Brook]

1. In rmdtest.c:
If I build with OPENSSL_NO_RIPEMD and rmdtest.c fails to compile because
openssl/ripemd.h cannot be found.
The line "#include "  needs to be moved AFTER the "#else"
of "#ifndef OPENSSL_NO_RIPEMD".

2. In ssltest.c:
If I build with OPENSSL_NO_DH, I will get a failure message:
"unknown option -dhe1024dsa"
when running
"test sslv2/sslv3 with 1024bit DHE via BIO pair" in testssl.com.

3. bn won't compile in a Windows environment using VC++ 6.0/SP5 because of a
problem with 'bn.h' which uses the VC++ 6.0/SP5 class template name,
'modulus'.

Chris Brook

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]