Re: new engine

[Geoff Thorpe]

Hey there,

I sense more clarification is needed, and as ENGINE stuff was only very
recently migrated from its own little development branch of CVS into the
main trunk, it's probably overdue for some general discussion anyway. So
here goes a first crack at it - feel free anyone to open this right up.
BTW: this'll probably be a bit of a marathon ...

On Wed, 1 Nov 2000, Ben Laurie wrote:

> Geoff Thorpe wrote:
> > 
> > BTW: Right now, all the existing engine implementations typically work
> > immediately without any "setup" beyond what they work out for themselves
> > before, during, or after initialisation.
> 
> This is true. But clearly there are other engines where this isn't the
> case. Anyway, I think the idea of driving ENGINE_ctrl()s from the
> configuration isn't so good, because it leads to obscure configuration.
> Probably its better to pass a configuration handle into the
> ENGINE_init() and let it pick up whatever it needs from there itself?

Well the point behind ENGINE, and I can say this on account of the fact
that I started the original hacking of it to solve a need I and others had
identified, was *not* to make it possible to switch one piece of hardware
for another and have things work transparently by changing OpenSSL's
ENGINE at run-time. That is *completely* unrealistic except for one very
specific use-case; namely acceleration-only. It just so happens that this
very case is the one where in theory no extra settings need to be
configured because the ENGINE specific to the accelerator only needs to
*find* the hardware using the accelerator's local installation details and
can start firing off operations immediately. Other cases simply do not so
readily gel with the idea of "switch the ENGINE and go", eg. hardware
key-management, distributed environments, or anything requiring run-time
setup or authorisation.

So, let me explain what the point behind it *was* (lest I sound too
negative :-) - it was so that software that supported the ENGINE API (and
I should qualify that they need to support it *properly*) would not need
to have vendor-specific support hard-coded in to make it possible to
support new or alternative devices. It doesn't remove the need for having
the locally installed device and support software properly configured -
including whatever its concept of "configuration" might be. This idea is
useful not just in apps that are distributed binary-only, but also in apps
that are shipped with source but don't want people having to needlessly
hack it. Eg. an SSL module in Apache should be able to pluck a directive
out of a config file and say "find me this 'ENGINE' and set it as my
default". If you later go in and add a new ENGINE implementation for a new
hardware (or software) unit, and recompile, and you ensure that the
environment of that "unit" is functioning OK in and of itself, then the
SSL module itself should not need to be upgraded or rewritten to get the
hooking to work. If settings are needed by that alternative ENGINE, they
presumably can be found inside the environment in which that new ENGINE
and its device operate - they just don't need to be hacked into OpenSSL or
applications any more.

Any attempt to assume some parameterisation of all ENGINEs in a generic
fashion runs straight up against the fact that it will fail when it
encounters a new kind of ENGINE that wants or needs to do things
differently. Hence me prattling off that hypothetical list of the types of
garbage any given engine might need to for it to "go". The idea was not to
somehow make the ENGINE API an all-singing all-dancing framework where
any/all devices might be supported transparently, and indeed trying to do
so would assume you can generalise the use-cases for all engines and cover
such things (which is simply a counter-intuitive thing to try). The point
was simply that if you add a device/unit and have that device/unit
configured and operating on your system, there's no need to go hunting for
upgrades to your applications for them to use this new device. That's all.
Every device and its ENGINE implementation will need different things for
it to be usable, just as each device itself needs to be installed and
configured on the host system independantly of OpenSSL anyway.

Now, anything new and cool that can be done to make the general class of
device-support slicker and less problematic is great. Particularly if it
centralises a lot of code that would otherwise be duplicated in lots of
ENGINEs. But as someone pointed out, you couldn't simply have a
software-only solution running with the ENGINE API, and expect to plug in
a new PKCS#11 device and have the application switch over transparently.
The ENGINE specific to that device (or PKCS#11) will need to know
addresses, usernames, and whatever else is required to deal with it, and
presumably private keys and what-not will have to be setup and exported in
some kind of PEM equivalent that will be specific to the device and its
support software. If you 

Re: possible bug in DH_generate_key()

[Lawrence MacIntyre]

Ulf:

But bin2bn is generating BNs from the static P and G which don't have
trailing 0s.  It is BN_num_bytes that reports 55 when it should be
saying 56.  Is there a better way to determine the length of the key? 
Do I just need to know the length of the key apriori?  I had allowed the
client to pick the key length, and the server just figured it out from
the output from BN_num_bytes().  Should BN_num_bytes() report 55 instead
of 56 just because the last byte is 0?  Maybe it should be renamed
BN_num_bytes_not_counting_trailing_zeroes() :-)  At the very least that
limitation should be documented.  DH_size() always seems to return the
correct answer, so I'll switch to that.

On the MGF1 thing (new to me, I'll admit), I assume I create the
blowfish key using

MGF1(*bfkey, length_of_blowfish_key, *dh_shared_secret,
length_of_dh_shared_secret);

on both nodes once they have generated the DH_shared_secret.  This
appears to be a hash function using SHA1?

Just curious, why is the DH shared key insecure before being run through
MGF1?

thanks for your help!
Ulf Moeller wrote:
> 
> On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:
> 
> > I use bin2bn to generate the BNs for P and G, and the char lengths are
> > correct AND statically defined in the .h file, so they are the same
> > every time.  Then I generate the key using DH_generate_key() and
> > BN_num_bytes() to determine the length of the key.  Is that incorrect?
> 
> No, it's just that the top byte can be zero, and bin2bn doesn't output
> trailing 0s.
> 
> > The reason I found the error is that I use the DH struct to provide a
> > key to the blowfish encryption function and it would fail sometimes.
> 
> That is potentially insecure anyway. You should use a key derivation
> function (for example MGF1) to generate a symmetric key from the DH
> shared secret.

-- 
 Lawrence
~

Lawrence MacIntyre  Center for Information Infrastructure Technology
[EMAIL PROTECTED]   http://www.ciit.y12.doe.gov/~lpz 865.574.8696
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: new engine

[Dr S N Henson]

Ben Laurie wrote:
> 
> Dr S N Henson wrote:
> > The idea behind this is that a simple engine aware application could
> > then just call ENGINE_load_config("filename.cnf") and forget about any
> > other details.
> 
> The reason I suggested a handle instead of a filename was so that the
> data could come from elsewhere.
> 

Well whatever... I was just using that as an example. The whole point is
that if an application writer doesn't want or have time to look into how
ENGINEs work they can make a simple call and some basic functionality
(crypto acceleration for example) is supported.

Arne Ansper wrote:
> 
> > The idea behind this is that a simple engine aware application could
> > then just call ENGINE_load_config("filename.cnf") and forget about any
> > other details.
> 
> or you can encode the parameters into string and pass this string around.
> file-based configuration is not always the best.
> 

No it isn't always the best but having a simple string could get very
messy if lots of information needs to be passed around. Maybe something
a bit like the extension code. You can pass a simple string but if that
isn't sufficient the engine can access other information from the CONF
pointer (which need not refer to a config file).

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

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

Re: openssl-0.9.6-1 gotcha vs openssh-2.2.0p1-5

[Richard Levitte - VMS Whacker]

Regarding the problem of binary incompatibility between versions of
shared libraries, I think the big problem is probably the way the
shared library is named.  Since the internal names (set with -soname)
normally are 'libcrypto.so.0' and 'libssl.so.0', I imagine it looks
like the same version of the library (that is, the API) all along.  On
some systems, the versioning and backward compatibility can be better
defined, like in OSF and possibly on Irix (although I'm quite unsure
about that one).

I'm aware that the current way things are done is a bit clumsy,
version-wise.  I might need some help getting it right, or at least
understanding the finer points in shared library versioning...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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]

Re: possible bug in DH_generate_key()

[Ulf Moeller]

On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:

> I use bin2bn to generate the BNs for P and G, and the char lengths are
> correct AND statically defined in the .h file, so they are the same
> every time.  Then I generate the key using DH_generate_key() and
> BN_num_bytes() to determine the length of the key.  Is that incorrect?

No, it's just that the top byte can be zero, and bin2bn doesn't output
trailing 0s.
 
> The reason I found the error is that I use the DH struct to provide a
> key to the blowfish encryption function and it would fail sometimes.

That is potentially insecure anyway. You should use a key derivation
function (for example MGF1) to generate a symmetric key from the DH
shared secret.

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

Re: possible bug in DH_generate_key()

[Lawrence MacIntyre]

Ulf:

I use bin2bn to generate the BNs for P and G, and the char lengths are
correct AND statically defined in the .h file, so they are the same
every time.  Then I generate the key using DH_generate_key() and
BN_num_bytes() to determine the length of the key.  Is that incorrect?

The reason I found the error is that I use the DH struct to provide a
key to the blowfish encryption function and it would fail sometimes.

Ulf Moeller wrote:
> 
> On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:
> 
> >   When you run the program 1000 times, somewhere between 3 and 9
> > times the length of the public key will be 55 bytes instead of 56, as it
> > should be.  This breaks my client:-(  Once, the key was actually 54
> > bytes.
> 
> You really should fix the client. The key is a random number, and you have
> to expect the top byte to be zero in about 1 out of 256 cases.

-- 
 Lawrence
~

Lawrence MacIntyre  Center for Information Infrastructure Technology
[EMAIL PROTECTED]   http://www.ciit.y12.doe.gov/~lpz 865.574.8696
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl-0.9.6-1 gotcha vs openssh-2.2.0p1-5

[Ulf Moeller]

On Wed, Nov 01, 2000, Ulf Moeller wrote:

> > The bottom line is there is no binary compatibility between these two
> > versions, and to make matters worse, there is no version checking that
> > I can see in the API.
> 
> That is correct.

I mean part one is correct, part two of course isn't.

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

Re: openssl-0.9.6-1 gotcha vs openssh-2.2.0p1-5

[ben h kram]

> So if you run an openssh that was compiled against version 0.9.5a of
> OpenSSL, the 0.9.5a version of the shared library is obligatory. You
> cannot use the 0.9.6 shared library instead.
> 
> Is this what the statement was about?

Yes it was - thank you for your time.

.b

-- 
"...human heads are opaque and there's no way to see inside except 
through those tiny little windows, the eyes."
-Yevgeny Zamyatin
  "We"
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl-0.9.6-1 gotcha vs openssh-2.2.0p1-5

[Ulf Moeller]

On Wed, Nov 01, 2000, ben h kram wrote:

> The bottom line is there is no binary compatibility between these two
> versions, and to make matters worse, there is no version checking that
> I can see in the API.

That is correct. Binary compatibility is planned from OpenSSL 1.0 upwards.

You must compile applications with the header files from the OpenSSL
release you are linking it to.

If you need a sanity check, do:

 if (OPENSSL_VERSION_NUMBER != SSLeay()) abort();

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

Re: openssl-0.9.6-1 gotcha vs openssh-2.2.0p1-5

[Lutz Jaenicke]

On Wed, Nov 01, 2000 at 10:49:00AM -0500, ben h kram wrote:
> Hi - I built an rpm of openssl-0.9.6 and contributed it to redhat's site a few weeks 
>ago;
> 
> I recently received communication from Dave Johnson <[EMAIL PROTECTED]> pointing 
>out some incompatability issuess he's having.

[Long discourse deleted]

I am not sure that I understand the statement correctly.

Between 0.9.5a and 0.9.6 there is no binary compatibility. This is a well
known fact that is also officially stated by the openssl developers team.
Binary compatibility between releases is not to be expected before version
1.0 of the OpenSSL library.

If you are using shared libraries, you either have to recompile your
application or must make sure, that the correct shared library is being
used. This is typically assured by including the version number into
the shared library name: "libssl.so.0.9.6" etc.

So if you run an openssh that was compiled against version 0.9.5a of
OpenSSL, the 0.9.5a version of the shared library is obligatory. You
cannot use the 0.9.6 shared library instead.

Is this what the statement was about?

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: possible bug in DH_generate_key()

[Ulf Moeller]

On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:

>   When you run the program 1000 times, somewhere between 3 and 9
> times the length of the public key will be 55 bytes instead of 56, as it
> should be.  This breaks my client:-(  Once, the key was actually 54
> bytes.

You really should fix the client. The key is a random number, and you have
to expect the top byte to be zero in about 1 out of 256 cases.

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

stdout problem on NT only

[Paul Kudlawiec]

We discovered a problem running openssl with our application on WinNT4.0 and
using Visual C++ 6.0.

When we run our application, it makes a call to SSL_write, then an access
violation occurs executing fwrite within the function file_write of openSSL.

Upon closer inspection, we found the culprit to be stdout. From within our
application, while initializing openSSL, b->ptr (b is type BIO) is set to
stdout. Just before the crash within openSSL, b->ptr is still pointing to
that
address; however, if a variable is set within openSSL to stdout, that
variable
points to a different address.

In other words: If a variable is set to stdout in our application, and a
variable is set to stdout within openSSL, the two point to different
addresses
in NT--in Unix, both point to the same address. In NT, if an attempt is
made to use the stdout address set in the calling from application within
openSSL, a crash occurs.

An earlier message on the listserv indicated a similar problem (see "App
crash
on NT"); the solution suggested using the multithreaded dll version of the
run-time libraries. We verified that the correct libraries are indeed being
used.

Has anyone else seen this, or knows why the stdouts would be different?
Thanks!

Paul

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

Re: new engine

[Ben Laurie]

Dr S N Henson wrote:
> The idea behind this is that a simple engine aware application could
> then just call ENGINE_load_config("filename.cnf") and forget about any
> other details.

The reason I suggested a handle instead of a filename was so that the
data could come from elsewhere.

Cheers,

Ben.

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

"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]

possible bug in DH_generate_key()

[Lawrence MacIntyre]

Hi:

I have been having spurious problems with one of my client server
programs.  It uses a DH Key exchange to generate a blowfish key and
encrypts the data using that key.  I believe I have isolated the problem
to the minimum of code.  I'm attaching the test program, Makefile, and a
bash script that runs the program 1000 times.  It uses BN_new() and
BN_hex2bn() to convert two strings to BIGNUMs, stuffs them into a DH,
and then calls DH_generate_key() to generate the private/public key
pair.  When you run the program 1000 times, somewhere between 3 and 9
times the length of the public key will be 55 bytes instead of 56, as it
should be.  This breaks my client:-(  Once, the key was actually 54
bytes.  My workaround is to test for the length and if it's wrong,
delete the DH struct, and regenerate (ugly but effective).  Simply
regenerating the key doesn't work.  Am I doing something dopey or is
this a bug?

-- 
 Lawrence
~

Lawrence MacIntyre  Center for Information Infrastructure Technology
[EMAIL PROTECTED]   http://www.ciit.y12.doe.gov/~lpz 865.574.8696

# $Id: Makefile,v 1.2 2000/10/04 19:25:19 lpz Exp $
#
# Changes:
#CC = kgcc  #for RH 7.0
CC = gcc
CFLAGS = -g -Wall
COMMONOBJS =
INCLUDES =
INCLUDEDIRS = -I/usr/local/ssl/include
OBJS = dhtst.o
LIBDIRS = -L/usr/local/ssl/lib
LIBS = -lcrypto
RM = rm -f
EXES = dhtst
TAR = tar
ZIP = zip
SRCS = Makefile.dhtst dhtst.c dh_crypto.h dhtstloop.sh

all:dhtst

dhtst:  dhtst.o
$(CC) $(CFLAGS) -o dhtst dhtst.o $(COMMONOBJS) $(LIBDIRS) $(LIBS)

.PHONY: clean tar zip

clean:
$(RM) $(OBJS) $(COMMONOBJS) $(EXES) *.tar *.zip

tar:
$(TAR) czvf dhtst.tgz $(SRCS)

zip:
$(ZIP) dhtst.zip $(SRCS)
  
dhtst.o:dhtst.c Makefile
$(CC) $(CFLAGS) -c $(INCLUDEDIRS) dhtst.c


/*
 * $Id: dh_crypto.h,v 1.2 2000/10/04 19:25:19 lpz Exp $
 *
 * Changes:
 *
 * 10/06/2000 - LPM - Remove DH pointer from dh_crypto struct
 * 10/13/2000 - LPM - Add P and G
 *remove dh_crypto struct (we only need the sock)
 */
#ifndef DH_CRYPTO_H
#define DH_CRYPTO_H

#define DH_GMAX 1
#define KEY_SIZE 448
#define DH_PMAX KEY_SIZE/8

struct pgpub {
short int psize;
short int gsize;
short int pubsize;
unsigned char buffer[2*DH_PMAX + DH_GMAX];
};

struct pubreply {
short int pubsize;
unsigned char pubk[DH_PMAX];
};

const char P[DH_PMAX] = {0xCA, 0x9C, 0x3C, 0xB3, 0xE2, 0x39, 0x84, 0x50, 0x76, 0xAC, 
0xC3, 0x96, 0x36, 0x34, 0xA0, 0x2F, \
0x1A, 
0x50, 0x03, 0x20, 0x9B, 0x29, 0xB1, 0xBF, 0x31, 0x7E, 0x18, 0xA0, 0xD2, 0x44, 0x0A, 
0x63, \
0x08, 
0x25, 0xC0, 0xC3, 0xE3, 0xF7, 0x22, 0x58, 0x59, 0x62, 0x91, 0x17, 0xC7, 0xDF, 0x28, 
0x99, \
0x49, 
0x3C, 0x7C, 0x49, 0xB1, 0x0F, 0x89, 0x37};

const char G = 0x05;
#endif


#include 
#include 

#include 
#include 
#include 

#include "dh_crypto.h"

int main(int argc, char **argv)
{
int status;
  int retries = 0;
DH *a = NULL;

  do {
a = DH_new();
if(a == NULL) {
perror("DH_new(a): ");
status = ERR_get_error();
goto err;
}

a->p = BN_new();
if(a->p == NULL) {
status = ERR_get_error();
goto err;
}

BN_bin2bn(P, sizeof(P), a->p);
  
a->g = BN_new();
if(a->g == NULL) {  
status = ERR_get_error();
goto err;
}

BN_bin2bn(&G, sizeof(G), a->g);
  
if(!DH_generate_key(a)) {
perror("DH_generate key: ");
status = ERR_get_error();
goto err;
}
  
status = BN_num_bytes(a->pub_key);
if(status != 56) {
  printf("pub key size: %d\n", status);
  printf("Retries: %d\n", ++retries);
}
BN_free(a->g);
a->g = NULL;
BN_free(a->p);
a->p = NULL;
DH_free(a);
  
} while(status != 56);

status = 0;
err:
if(status != 0) {
printf("Status: %d\n", status);
}
  return(status);
}

 dhtstloop.sh

Re: new engine

[Arne Ansper]

> The idea behind this is that a simple engine aware application could
> then just call ENGINE_load_config("filename.cnf") and forget about any
> other details.

or you can encode the parameters into string and pass this string around.
file-based configuration is not always the best.

every engine will have two APIs: common and private. private API is for
configuration. for example in case of pkcs#11 engine the private API
allows one to select pkcs#11 library to be loaded, enumerate slots, tokens
and keys. finally there is function which will encode the parameters into
string (like d:\program files\smart card vendor\pkcs11\api.dll,0,0,"the
key"). this string is then passed to application which will use it to
access private key in uniform fashion by passing the string through common
API to engine, which will decode it and act appropriately.

the private API is useful for GUI applications which may want to allow
browsing through your keys and it is optional. if the selector-string
encoding is documented then you can create this string manualy.

arne


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

Rijndael Patches for OpenSSL 0.9.6: Act 2

[Robert Sandilands]

Attached is the patches for OpenSSL 0.9.6 to enable the AES
winner:Rijndael. Also attached is the files that is not included in the
patch and is new.

Nine files: 

1. rijndael.diff - The diff file to use with "patch -p3 -u"
2. cmd - The command executed to create the diff file.
3. exclude - The files that were excluded.
4. rijndael.c - crypt/rijndael/rijndael.c
5. rijndael.h - crypt/rijndael/rijndael.h
6. Makefile.ssl - crypt/rijndael/Makefile.ssl
7. e_rijndael.c - crypt/evp/rijndael/e_rijndael.c
8. rijntest.c - crypt/rijndael/rijntest.c
9. boxes-fst.dat - crypt/rijndael/boxes-fst.dat

Procedure for using patch:

1. tar zxf openssl-0.9.6.tgz
2. patch -p3 -u < rijndael.diff
3. Copy attaches source files into specified directories.
4. cd openssl-0.9.6
5. Configure 
6. make update
7. Configure 
8. make
9. make test

Tested on:

1. RedHat Linux 7.0 under Intel and Borland C++ Builder 4.0 under
Windoze 98.
2. It should work on most 32-bit architectures and I have no idea
whether it would work on 64-bit architectures and have no access to be
able to test it.

Features and Limitations:

1. It defaults to a 256-bit key but can be configured for 128 and
192-bit keys too. 
2. The block length have been left at 128-bit's but according to the
specifications it is trivial to adjust upwards in 32-bit increments. 
3. Only CBC and ECB modes have been implimented. 

License:

1. I just took the code from the original Rijndael example code from the
author's web-site at http://www.esat.kuleuven.ac.be/~rijmen/rijndael/. 
2. He made it freely available so I'm uncertain what to do with the
license. 
3. I personally wouldn't mind putting the OpenSSL license in it but
maybe we can't. 

Comments:
1. The patch fails with openssl-0.9.6/Makefile.ssl but this is not
important as this file is recreated when you run "Configure". 
2. Any feedback would be appreciated.
3. I don't seem to be receiving any of the replies on my postings so
please CC me on any comments you have please.

Robert Sandilands

diff -u -p -r -b -d -I .o: .. --exclude-from=/home/robert/ftp/openssl/exclude 
./Makefile.org /source/openssl/openssl-0.9.6/Makefile.org
--- ./Makefile.org  Thu Sep 21 11:23:13 2000
+++ /source/openssl/openssl-0.9.6/Makefile.org  Mon Oct 16 13:38:00 2000
@@ -165,7 +165,7 @@ SDIRS=  \
des rc2 rc4 rc5 idea bf cast \
bn rsa dsa dh dso \
buffer bio stack lhash rand err objects \
-   evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp
+   evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp rijndael
 
 MAKEFILE= Makefile.ssl
 MAKE= make -f Makefile.ssl
diff -u -p -r -b -d -I .o: .. --exclude-from=/home/robert/ftp/openssl/exclude 
./Makefile.ssl /source/openssl/openssl-0.9.6/Makefile.ssl
--- ./Makefile.ssl  Tue Oct 24 11:31:30 2000
+++ /source/openssl/openssl-0.9.6/Makefile.ssl  Fri Oct 20 15:19:55 2000
@@ -11,9 +11,9 @@ SHLIB_VERSION_NUMBER=0.9.6
 SHLIB_VERSION_HISTORY=
 SHLIB_MAJOR=0
 SHLIB_MINOR=9.6
-PLATFORM=debug-linux-elf-noefence
+PLATFORM=BC-32
 OPTIONS=
-CONFIGURE_ARGS=debug-linux-elf-noefence
+CONFIGURE_ARGS=BC-32
 SHLIB_TARGET=
 
 # INSTALL_PREFIX is for package builders so that they can configure
@@ -54,20 +54,20 @@ OPENSSLDIR=/usr/local/ssl
 # equal 4.
 # PKCS1_CHECK - pkcs1 tests.
 
-CC= gcc
+CC= bcc32
 #CFLAG= -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -Wuninitialized 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM
-CFLAG= -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DBN_DEBUG -DREF_CHECK 
-DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -DTERMIO -g -m486 -Wall 
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM
+CFLAG= -DTHREADS  -DDSO_WIN32 
 DEPFLAG= 
 PEX_LIBS= -L. -L.. -L../.. -L../../..
-EX_LIBS= -ldl
+EX_LIBS= 
 AR=ar r
-RANLIB= /usr/bin/ranlib
-PERL= /usr/bin/perl
+RANLIB= true
+PERL= perl
 TAR= tar
 TARFLAGS= --no-recursion
 
 # Set BN_ASM to bn_asm.o if you want to use the C version
-BN_ASM= asm/bn86-elf.o asm/co86-elf.o
+BN_ASM= bn_asm.o
 #BN_ASM= bn_asm.o
 #BN_ASM= asm/bn86-elf.o# elf, linux-elf
 #BN_ASM= asm/bn86-sol.o # solaris
@@ -87,7 +87,7 @@ PROCESSOR= 
 
 # Set DES_ENC to des_enc.o if you want to use the C version
 #There are 4 x86 assember options.
-DES_ENC= asm/dx86-elf.o asm/yx86-elf.o
+DES_ENC= des_enc.o fcrypt_b.o
 #DES_ENC= des_enc.o fcrypt_b.o  # C
 #DES_ENC= asm/dx86-elf.o asm/yx86-elf.o # elf
 #DES_ENC= asm/dx86-sol.o asm/yx86-sol.o # solaris
@@ -96,7 +96,7 @@ DES_ENC= asm/dx86-elf.o asm/yx86-elf.o
 
 # Set BF_ENC to bf_enc.o if you want to use the C version
 #There are 4 x86 assember options.
-BF_ENC= asm/bx86-elf.o
+BF_ENC= bf_enc.o
 #BF_ENC= bf_enc.o
 #BF_ENC= asm/bx86-elf.o # elf
 #BF_ENC= asm/bx86-sol.o # solaris
@@ -105,7 +105,7 @@ BF_ENC= asm/bx86-elf.o
 
 # Set CAST_ENC to c_enc.o if you want to use the C version
 #There are 4 x86 assember options.
-CAST_ENC= asm/cx86-elf.o
+CAST_ENC= c_enc.o
 #CAST_ENC= c_enc.o
 #CAST_ENC= asm/cx86-elf.o # elf
 #CAST_ENC= asm/cx86-sol.o # solaris
@@ -114,7 +114,7 @@ CAST_ENC= asm/cx86-elf.o
 

Re: new engine

[Goetz Babin-Ebell]

Dr S N Henson wrote:

> The idea behind this is that a simple engine aware application could
> then just call ENGINE_load_config("filename.cnf") and forget about any
> other details.

Would carve the way to store the engine configuration in stone...

By

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: new engine

[Dr S N Henson]

Geoff Thorpe wrote:
> 
> On Tue, 31 Oct 2000, Ben Laurie wrote:
> 
> 
> BTW: Right now, all the existing engine implementations typically work
> immediately without any "setup" beyond what they work out for themselves
> before, during, or after initialisation.
> 

Indeed, but its possible to imagine various engines that require rather
complex settings possibly on a per instance basis. Lets say for example
we have a PKCS#11 engine. It might need to know the location of the
PKCS#11 library, whether to login immediately and probably a bunch of
other things I haven't thought of yet. We might also have multiple
instances using separate PKCS#11 libraries too.

IMHO a situation to avoid is one where this kind of thing is handled
only via engine specific ENGINE_ctrl() functions such that an engine
aware application needs to be modified to handle newer engines.

I can think of several ways of handling this. One is to just give the
engine access to a config file and let it decide how to interpret it. At
an application level we could have (say) an ENGINE_load_config() high
level function that can be used to decide which engines to load, some
things like default methods to override and sections containing engine
specific configuration.

The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

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

Re: new engine

[Ben Laurie]

Geoff Thorpe wrote:
> 
> On Tue, 31 Oct 2000, Ben Laurie wrote:
> 
> > > Yes, your answer is satisfactory.
> > > If I understand then I can't use openssl.exe main application for
> > > testing my new engine
> > > (of course after compilation of openssl with new engine features).
> >
> > Exactly, and this is wrong and bad. We should fix it.
> 
> Enough of the one liners already - go ahead and fix it! Sheesh!

Well, the main point is to decide how it should be fixed - once that's
done it should be easy, right?

> This is not *that* big a deal anyhow.
> 
> Anything that could be assumed as far as default values for initialising
> an ENGINE can be set by the author of the implementation. Anything that
> needs to be pulled out of some kind of environment specific to the ENGINE
> (eg. registry or configs relating to the engine-specific "thing") can also
> be pulled out by the implementation (and its author). Which leaves us with
> the only worthwhile point made in this little exchange so far, namely,
> that it should be possible to set various things inside OpenSSL config
> files that could be passed into the ENGINEs like a batch file. This *can*
> be done, but it depends how you choose syntatically to do it ...
> numerically isn't so hot except for "generic" parameter types that can be
> defined in OpenSSL once and stay fixed (which is not likely to be the case
> often IMHO). On the other hand, doing it string based might be ugly too.
> 
> Anyway, some way of batching a series of ENGINE_ctrl() functions by way of
> config files could be done. The case that started this deals with some
> kind of engine implementation that requires a hostname, username, and
> password. That's hardly typical for engines (so far) - and if any such
> thing as "default values" for those settings exists on that system, it's
> very likely they're stored somewhere in the environment that controls (or
> administers) the stuff that engine deals with. So the "requirement" that
> they be specified by OpenSSL config files is at best a nice-to-have, but
> hardly a showstopper. Your comment that;
> 
> > Leaves me with one - if specific engines have to be initialised "by
> > hand", then we haven't got much in the way of abstraction, have we? Is
> > there a better way? Config files? External programs?
> 
> is a little simplisitic, as have been most of the bite(yte)-sized comments
> thus far; "to make the engine go" (as you said in another post) requires
> whatever the engine's purpose dictates and whatever the environment it
> operates in dictates. If defaults can be assumed, then by definition they
> can be used inside the engine implementation to obviate the need for
> ENGINE_ctrl()ing. Likewise if the defaults *exist* somewhere, they can
> equally be pulled out automatically. The only issue is whether this can or
> should be driven by generic OpenSSL-based settings rather than
> ENGINE-specific settings.

Well, the point is that if I have some application that uses OpenSSL to
provide crypto, I shouldn't have to modify the application in order to
be able to use a specific engine, in an ideal world.

> Other possible cases of engines requiring settings are equally likely to
> require smart cards, paths, one-time-pad keys, retina-scans, filenames,
> network addresses, challenge-response variants, hardware settings, system
> settings, system limitations (eg. RAM, disk caching, whatever), UIDs,
> PINs, IRQs, DMAs, and probably a tonne of other things. There should be
> some way to feed arbitrary name-value pairs into an ENGINE perhaps, maybe
> an ENGINE_ctrl_ext() or some such variant, but the lack of that feature
> thus far is hardly "not much in the way of abstraction", and likewise the
> addition of that feature is not going to make such a general problem go
> away.
> 
> BTW: Right now, all the existing engine implementations typically work
> immediately without any "setup" beyond what they work out for themselves
> before, during, or after initialisation.

This is true. But clearly there are other engines where this isn't the
case. Anyway, I think the idea of driving ENGINE_ctrl()s from the
configuration isn't so good, because it leads to obscure configuration.
Probably its better to pass a configuration handle into the
ENGINE_init() and let it pick up whatever it needs from there itself?

Cheers,

Ben.

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

"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]

Re: Doing own nonblocking socket I/O

[Bodo Moeller]

On Tue, Oct 31, 2000 at 02:58:48PM +, Ben Laurie wrote:
> Bodo Moeller wrote:

>> Talking about "real servers" -- I think Apache 1.3.14 still uses
>> blocking sockets in its select-accept-loop, which doesn't work
>> reliably on BSD.

> What do you mean "doesn't work reliably"? Works for me!

Isn't that exactly what race conditions are famous for?

If select() says that an 'accept' fd is currently readable, then the
next accept() may block anyway if a RST from the peer is detected
between select() and accept().  Non-BSD systems don't immediately
forget about connections that are reset before they are accepted
-- the next accept() will lead to ECONNRESET or EPROTO or something
like that.  But on systems with the traditional BSD behaviour,
select-accept-loops have to use non-blocking accept sockets
to avoid this race condition.

To actually see this race condition in action, you'd probably
have to add a sleep(1) right before the accept(), and write
a client that connects and immediately sends a RST
(that's SO_LINGER with l_linger set to 0).
Then start a server listening on multiple ports, and connect
to one of these using this 'evil' client software.
Connections to other ports should no longer work until
there's another connection to this one port.


-- 
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: engine & PKCS11

[Richard Levitte - VMS Whacker]

From: "Martin Szotkowski" <[EMAIL PROTECTED]>

martin.szotkowski> will be in OpenSSL created engine (I mean ENGINE)
martin.szotkowski> that will communicate with HW using PKCS11?

There's been some talking about doing that, but hasn't been started
yet.

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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]

engine & PKCS11

[Martin Szotkowski]

Hi,
will be in OpenSSL created engine (I mean ENGINE) that will communicate with
HW using PKCS11?
I think, this is way how to create universal engine.

Martin

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