Location of OpenSSL libraries
I have a build script for some software that needs to locate the OpenSSL headers and libraries, and I have reports that it is failing to locate the libraries on some OSes. One example identifies itself (via 'uname') as: sunos open-solaris-noc 5.11 snv_95 i86pc i386 i86pc What is the default installation location for the OpenSSL libraries on such a machine? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Location of OpenSSL libraries
Victor B. Wagner wrote on 2009-10-19:
On 2009.10.19 at 16:30:14 +0100, Steve Hay wrote:
I have a build script for some software that needs to locate the
OpenSSL headers and libraries, and I have reports that it is failing
to
locate the libraries on some OSes.
One example identifies itself (via 'uname') as:
sunos open-solaris-noc 5.11 snv_95 i86pc i386 i86pc
What is the default installation location for the OpenSSL libraries
on
such a machine?
Are you sure that these libraries are installed on the machine? As
far,
as I know on Solaris 11 (although my test machine reports snv_111b)
OpenSSL librares are installed into /lib and headers into
/usr/include/openss
It's possible that the libraries are missing, but apparently the header
files were found in /usr/include/openssl so I'm expecting the libraries
to be around somewhere.
Note that if you are trying to build 64-bit application on solaris, it
should link with /lib/amd64/libcrypto.so rather than /lib/libcrypto.so
(on Solaris 64-bit libraries are stored in the ${prefix}/lib/`isainfo
-k` rather than just ${prefix}/lib, where 32-bit libraries are kept.
Command isainfo -k returns amd64 for 64-bit Solaris Intel and sparcv9
for 64-bit Solaris Sparc.
Yes, it's doing a 64-bit build, so it's the amd64/ or sparcv9/ bit
that's missing: it only checks in ${prefix}/lib64 and ${prefix}/lib at
the moment.
Note that it is the location of the libcrypto.a file that I'm after (not
the .so file). Does that change anything?
Some Linux distribution also keep OpenSSL shared libraries in the
/lib,
and recent freeBSD too, but they put symilinks libcrypto.so and
libssl.so into /usr/lib to link with. Solaris doesn't do this.
In the Solaris 10 OpenSSL libraries are stored in the /usr/sfw/lib and
include files in /usr/sfw/include.
Where would the 'openssl' executable be in that case? Is there a
/usr/sfw/bin? The build script looks for a 'openssl' somewhere and takes
$prefix to be the parent directory of that location. (E.g. If 'openssl'
is in /usr/bin then $prefix is taken to be /usr, and it looks for
headers in /usr/include/openssl and libraries in /usr/lib64 or /usr/lib)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
How to generate a random salt
How do I portably generate a random salt within a C program for use in PKCS#5 v2.0 key derivation? I find that just calling RAND_bytes() works OK on Win32 using 0.9.6 and later, but not with 0.9.5. I can fix it by calling RAND_screen() first. Is this OK? Do I also need to call RAND_screen() for 0.9.6+ or is it safe to omit it? What about other OS's? The FAQ notes that /dev/[u]random is used where present; does that imply that I don't need to do anything prior to calling RAND_bytes() for such OS's? For the remaining OS's I'm instructed to call RAND_add() or RAND_seed() first. Where do I get the data to pass to those functions from without requiring the user of my application having EGD available? Finally, if RAND_bytes fails is there any merit in falling back on RAND_pseudo_bytes(), or is that not suitable for generating a salt? (I may also need to generate an IV by the same means.) - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Trouble using PKCS5_pbe2_set()
Dr. Stephen Henson wrote:
On Fri, Sep 10, 2004, Dr. Stephen Henson wrote:
On Fri, Sep 10, 2004, Steve Hay wrote:
As an alternative to my luckless attempts at using
EVP_CIPHER_param_to_asn1() + PKCS5_v2_PBE_keyivgen(), I thought I would
try PKCS5_pbe2_set() + EVP_PBE_CipherInit(), but I've run into the
problem that I thought I would have: PKCS5_pbe2_set() randomly
generates its own IV, so that trying to decrypt previously encrypted
data doesn't work. (Or at least, I think that's what the problem is.)
I thought that calling
EVP_CipherInit_ex(ctx, cipher, NULL, NULL, iv, crypt_mode);
after the EVP_PBE_CipherInit() call would replace the iv set by
PKCS5_pbe2_set() with my own one, but it seems to make no difference, as
the attached sample program demonstrates.
Currently you can't set the IV yourself in PKCS5_pbe2_set(). If you however
just want to save and restore the random IV (along with the parameters used
for the key) you can use the {i2d,d2i}_ASN1_TYPE() functions to save and
restore this to and from a memory buffer along with the salt and key length.
Actually you'd be better just encoding and decoding the X509_ALGOR structure
(pbe2 I believe you called it) before the data and on the decode side passing
*that* to EVP_PBE_CipherInit().
OK, I tried that and it works very well.
However, as the attached program shows, it now turns out that this has
all been a waste of time. If you recall what my original problem was
(namely, EVP_BytesToKey() only supports default key length -- see
http://www.mail-archive.com/[EMAIL PROTECTED]/msg37111.html),
the main reason for switching to EVP_PBE_CipherInit() was that
PKCS5_v2_PBE_keyivgen(), which is called by EVP_PBE_CipherInit(),
supposedly works with non-default key lengths. But now that I've
finally got it working I find that it doesn't support non-default key
lengths after all.
Walking through the attached program in a debugger, I see that my
EVP_CIPHER_CTX_set_key_length() call correctly sets the key length to 24
(whereas BF default is 16), but then PKCS5_v2_PBE_keyivgen() does this:
/* Fixup cipher based on AlgorithmIdentifier */
EVP_CipherInit_ex(ctx, cipher, NULL, NULL, NULL, en_de);
(crypto/evp/p5_crpt2.c line 185-6 in openssl-0.9.7d), which has the
effect of resetting the key length in the ctx to the cipher's default,
namely 16 here!
So now I'm back to square one: How do I do PKCS#5 key derivation using a
non-default key length?
- Steve
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
#include stdio.h
#include openssl/evp.h
#include openssl/rand.h
#include openssl/x509.h
int main(int argc, char **argv) {
FILE *in, *out;
if (argc != 4) {
printf(Usage: %s infile outfile cryptmode\n, argv[0]);
return 2;
}
if ((in = fopen(argv[1], rb)) == NULL) {
printf(Error reading input\n);
return 3;
}
if ((out = fopen(argv[2], wb)) == NULL) {
printf(Error writing output\n);
return 4;
}
if (do_crypt(in, out, atoi(argv[3])) == 0) {
printf(Error running do_crypt()\n);
return 5;
}
return 0;
}
#define KEYLEN 24
const unsigned char pswd[] = 0123456789ABCDEFGHIJKLMN;
int do_crypt(FILE *in, FILE *out, int crypt_mode) {
unsigned char inbuf[BUFSIZ], outbuf[BUFSIZ + EVP_MAX_BLOCK_LENGTH];
int inlen, outlen;
unsigned char salt[PKCS5_SALT_LEN];
const EVP_CIPHER *cipher = EVP_bf_cbc();
X509_ALGOR *pbe2;
EVP_CIPHER_CTX ctx;
int len;
unsigned char *buf, *p;
char lenstr[10];
if (crypt_mode) {
if (!RAND_bytes(salt, PKCS5_SALT_LEN))
return 0;
pbe2 = PKCS5_pbe2_set(cipher, PKCS5_DEFAULT_ITER, salt, PKCS5_SALT_LEN);
len = i2d_X509_ALGOR(pbe2, NULL);
buf = OPENSSL_malloc(len);
p = buf;
i2d_X509_ALGOR(pbe2, p);
itoa(len, lenstr, 10);
fwrite(lenstr, 1, strlen(lenstr) + 1, out); // Include '\0' in output
fwrite(buf, 1, len, out);
OPENSSL_free(buf);
}
else {
fscanf(in, %10[^\0]%*[\0], lenstr);
len = atoi(lenstr);
buf = OPENSSL_malloc(len);
fread(buf, 1, len, in);
p = buf;
pbe2 = NULL;
d2i_X509_ALGOR(pbe2, p, len
Re: Trouble using PKCS5_pbe2_set()
Dr. Stephen Henson wrote:
On Mon, Sep 13, 2004, Steve Hay wrote:
So now I'm back to square one: How do I do PKCS#5 key derivation using a
non-default key length?
Urk, yes you are right. There isn't a way to set the key length in
PKCS5_pbe2_set().
OK, I'd hoped to avoid this but I don't think there's an option without
modifying the API...
What you *can* do is to create a new EVP_CIPHER structure which has its
default key length set to whatever you want.
So something like...
EVP_CIPHER new_cipher;
new_cipher = *EVP_bf_cbc();
new_cipher.key_len = whatever_key_length;
then you pass new_cipher to the relevant functions.
This should work with EVP_BytesToKey() too.
The above seems to work OK after a quick test, but why does one need
EVP_CIPHER cipher = *EVP_bf_cbc();
cipher.key_len = ...
rather than
EVP_CIPHER *cipher = (EVP_CIPHER *)EVP_bf_cbc();
cipher-key_len = ...
?
The program below does a similar thing for a struct called FRED and
works fine, but the equivalent with EVP_CIPHER produces an Access
Violation error when attempting to set the key_len.
//--
#include stdio.h
#include openssl/evp.h
typedef struct fred_st FRED;
struct fred_st { int foo; };
const FRED *new_fred(void) {
static FRED fred;
fred.foo = 16;
return fred;
}
void main(void) {
FRED *fred = (FRED *)new_fred();
EVP_CIPHER *cipher = (EVP_CIPHER *)EVP_bf_cbc();
printf(FRED foo = %d\n, fred-foo);
fred-foo = 24;
printf(FRED foo = %d\n, fred-foo);
printf(BF-CBC key len = %d\n, EVP_CIPHER_key_length(cipher));
// The next line causes an Access Violation:
cipher-key_len = 24;
printf(BF-CBC key len = %d\n, EVP_CIPHER_key_length(cipher));
}
//--
This outputs:
FRED foo = 16
FRED foo = 24
BF-CBC key len = 16
and then crashes.
- Steve
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Key generation question
Steve Hay wrote: El hallabi-Kettani Abderrahmane wrote: the function PKCS5_v2_PBE_keyivgen() exist in version openssl0.7.9d in directory openssl/crypto/evp/p5_crypt.c it corresponds to what you want to do . If you'd read my mail properly, you'd see that I'd already found that function. The problem is that it only exists in 0.9.4 and above, and I was looking for a way to do this (and/or wondering if I need to do this at all) in earlier versions as well. It occurs to me that I can make use of PKCS5_v2_PBE_keyivgen() for 0.9.4+, and just use EVP_BytesToKey() for earlier versions -- the fact that the latter doesn't support non-default key lengths isn't a problem because I can't set the key length prior to 0.9.6 anyway! So my question now is how do I use the (undocumented!) PKCS5_v2_PBE_keyivgen() function? If I understand it correctly from looking at the source code, the first three parameters are the cipher context to have the generated key+iv set in plus the data and data length to generate the key+iv from. The last two parameters are the digest function to use and the encrypt/decrypt mode. What are the other two parameters for? Namely, param and cipher in the following signature: int PKCS5_v2_PBE_keyivgen(EVP_CIPHER_CTX *ctx, const char *pass, int passlen, ASN1_TYPE *param, const EVP_CIPHER *cipher, const EVP_MD *md, int en_de); I could set the cipher to the cipher function that is already set in the ctx, but why doesn't PKCS5_v2_PBE_keyivgen() just use that itself? Am I missing something here? I've no idea what the ASN1_TYPE *param is, or where to get one from. I had a look at EVP_CIPHER_param_to_asn1(), but it says that the cipher IV in the ctx passed to it must be set when the call is made, which seems to be a chicken-and-egg problem to me -- I haven't got the cipher IV yet ;) Any clues how to use PKCS5_v2_PBE_keyivgen() would be greatly appreciated. - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Key generation question
Dr. Stephen Henson wrote: On Thu, Sep 09, 2004, Steve Hay wrote: I've no idea what the ASN1_TYPE *param is, or where to get one from. I had a look at EVP_CIPHER_param_to_asn1(), but it says that the cipher IV in the ctx passed to it must be set when the call is made, which seems to be a chicken-and-egg problem to me -- I haven't got the cipher IV yet ;) Any clues how to use PKCS5_v2_PBE_keyivgen() would be greatly appreciated. The function itself is intended to be used to generate or supply various paramaters in an appropriate DER structure. The password based encryption functions are intended to be called via the EVP_PBE_CipherInit() interface which is very similar to EVP_CipherInit(). The ASN1_TYPE parameter comes from various places depending on the PBE algorithm in use. For PKCS#5 v2.0 PKCS5_pbe2_set() is used. This is primarily to allow the PBE stuff to be used in appropriate ASN1 structures. The IV is generated randomly and included in the structure. Currently there's no way to supply your own IV but that will be fixed at some point... I'm afraid I don't know what password based encryption is, so I don't know if this is the right thing to even be trying to do. It doesn't sound like what I wanted... Does the fact that the IV is generated randomly mean that this will be no good for encrypting and then later (i.e. with a different IV) decrypting some data? If so, then this no good anyway. Alternatively you can get at the guts of the function by using PKCS5_PBKDF2_HMAC_SHA1(). Then you have to generate your own salt and pass it to the function along with the password and interation count. Sounds a little more hopeful. Where do I get the salt from? Would randomly generating it lead to the same encryption/decryption problem as with the IV above? Would hard-coding something in the source code suffice or is that not advisable? However, PKCS5_PBKDF2_HMAC_SHA1() only seems to generate a key, not an IV, but I already have a key -- it's the IV that I want! It may be worth taking a step back and reconsidering what I'm trying to achieve. I'm just trying to create a program to encrypt (and later decrypt) a plain text file. The user chooses (or more likely randomly generates) a key and specifies this as the key to use when *building* the program. I then discovered that the encryption/decryption functions require an IV too, but still don't really know what an IV is... At the moment I'm trying to generate the IV, and also getting a new key, from the key that the user has supplied, and I'm getting lost in all sorts of things that I don't understand and wasn't expecting to encounter -- passwords, IV's, salt, PKCS#5, etc :( Is it necessary/advisable to generate a key+IV in this way, or would it in fact suffice to have the user supply the IV too and just use the given key+IV? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Key generation question
Charles B Cranston wrote: Perhaps one way to think of the IV is that it is part of the key. That is, the IV and key are used to encrypt, and then the (same) IV and the (same) key can decrypt. IOW I could hard-code the IV into my source code, or use one supplied by the user at build time (as with the key). As long as they're both the same for the encrypt as for the decrypt then it'll work. (And by the same token, the PKCS5_pbe2_set() function is definitely no good for me because the IV won't be the same each time.) It's just that if the IV is sent in clear text (included in the structure...) then it is not secret. I don't think that this is an issue for me -- nothing's being sent anywhere. The IV would be as secret as the key in either of the above scenarios. One popular algorithm is to use MD5 to make a 128 bit hash of a password string, then use 64 bits of it as an IV and the other 64 bits of it as a DES key. So the IV and the key are innately related. Of course you could use the first and second 64 bits of an SHA1 hash just as well. In these cases, the IV can be regenerated from the password string at decrypt time, as long as it is the same string :-) I assume that this is the sort of thing that the PKCS5_PBKDF2_HMAC_SHA1() function is doing, except that it only seems to output a key, not an IV as well. Am I missing something here? Is there any function in OpenSSL to generate a key+IV from some given data (in my case, the key supplied by the user), or do I have to resort to hard-coding an IV or asking the user for that too? IV is used in cipher block chaining, that is, the output from block N is used as part of the input for block N+1, and the IV is the initial shift in at the very beginning: clear clear clear block 1 block 2 block 3 | | | v v v +--+--+ +--+--+ +--+--+ IV -| DES ++ DES ++ DES +--- +--+--+ +--+--+ +--+--+ | | | v v v cipher cipher cipher 3 block 1 block 2 block 3 You can find a diagram like this in any good book on encryption.. Look under Cipher Block Chaining. So, given that you are doing chaining, the IV supplies the startup value for the chain. Thanks for the info! - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Key generation question
Dr. Stephen Henson wrote: On Thu, Sep 09, 2004, Steve Hay wrote: I'm afraid I don't know what password based encryption is, so I don't know if this is the right thing to even be trying to do. It doesn't sound like what I wanted... It one of various standards which convert a password into a key (and sometimes and IV). For various reasons it is not advisable to use a password directly as a key. The thing that I'm converting into a key+IV is random bytes to start with, so I suspect there is virtually no distinction between password and key in my case, which could be why I'm getting confused. Alternatively you can get at the guts of the function by using PKCS5_PBKDF2_HMAC_SHA1(). Then you have to generate your own salt and pass it to the function along with the password and interation count. Sounds a little more hopeful. Where do I get the salt from? Would randomly generating it lead to the same encryption/decryption problem as with the IV above? Would hard-coding something in the source code suffice or is that not advisable? However, PKCS5_PBKDF2_HMAC_SHA1() only seems to generate a key, not an IV, but I already have a key -- it's the IV that I want! It may be worth taking a step back and reconsidering what I'm trying to achieve. I'm just trying to create a program to encrypt (and later decrypt) a plain text file. The user chooses (or more likely randomly generates) a key and specifies this as the key to use when *building* the program. I then discovered that the encryption/decryption functions require an IV too, but still don't really know what an IV is... At the moment I'm trying to generate the IV, and also getting a new key, from the key that the user has supplied, and I'm getting lost in all sorts of things that I don't understand and wasn't expecting to encounter -- passwords, IV's, salt, PKCS#5, etc :( How is the key user supplied? Will then just input some human readable string or generate a random value in some way? The key supplied by the user is just random bytes, probably generated with openssl rand ... or Perl's built-in rand() function or similar. In fact, the user can opt to not specify any key at all, in which case the build process for this program will generate one automatically using one of those means. The key is then written into a .h header file and built into the program. Is it necessary/advisable to generate a key+IV in this way, or would it in fact suffice to have the user supply the IV too and just use the given key+IV? The IV is an initial value used by some ciphersuites. Unlike the key it is not sensitive information and can be included along with the message itself. So you might generate a random IV, write it out to a file, use it to initialize an encryption context then write out the encrypted data. At the other end you would read the IV from the file and use that. Ah, that rings a bell. I think I've seen other software that writes out the IV as the first X bytes of the encrypted data; the decrypt operation then reads it back from there. Is there any harm in having a fixed IV? A salt is designed to avoid certain attacks on password based encryption. Specifically if the same password is used multiple times or if the password is vaguely guessable. My key isn't going to be guessable, but many files could be encrypted by the same program, i.e. all using the same key, so it sounds like I should be thinking of my key as a password and generating the real key from it using a salt after all. Again you can generate a random value and prepend that to the data. Using a fixed value removes the protection a salt provides. So what's the best way to do it? At the moment I have roughly this to initialise the EVP_CIPHER_CTX: EVP_BytesToKey(cipher_func, EVP_md5(), NULL, user_key, KEY_LEN, 1, key, iv) EVP_CIPHER_CTX_init(ctx) EVP_CipherInit_ex(ctx, cipher_func, NULL, NULL, NULL, crypt_mode) EVP_CIPHER_CTX_set_key_length(ctx, KEY_LEN) EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, crypt_mode) That's no good because EVP_BytesToKey() doesn't work for variable key length cipher's with non-default key lengths (and uses an old PKCS#5 standard?). So one solution would be simply to replace EVP_BytesToKey() above with this: if (encrypting) generate random salt else read salt from data PKCS5_PBKDF2_HMAC_SHA1(user_key, KEY_LEN, salt, saltlen, iter, KEY_LEN, key) The iv would have to generated/read from data as per the salt since PKCS5_PBKDF2_HMAC_SHA1() doesn't seem to create an IV. Presumably the iter value needs to be treated similarly too to ensure it is the same for decryption as for encryption, or can iter safely be hard-coded in the program? Another approach might have been to replace the whole initialisation with something like: EVP_CIPHER_CTX_init(ctx) if (encrypting) generate random salt else read salt from data pbe2 = PKCS5_pbe2_set(cipher_func, iter, salt, saltlen
Re: Problem building OpenSSL on Solaris 2.4
Will Day wrote: A short time ago, at a computer terminal far, far away, Steve Hay wrote: I'm trying to build OpenSSL 0.9.5a on Solaris 2.4, using the Sun WorkShop Compiler v3.0. ar: asm/sparcv8.o cannot open ar: asm/sparcv8.o not found [...] make this change in crypto/bn/Makefile: Where it has: asm/sparcv8.o: asm/sparcv8.S Change it to: asm/sparcv8.o: asm/sparcv8.s asm/sparcv8.s: asm/sparcv8.S /usr/ccs/lib/cpp asm/sparcv8.S $@ Thanks for this! I can now successfully run "make". But.. When I run "make test" I see the following message over and over again: tcov_exit: Coverage data file '/tmp/openssl-0.9.5a/crypto/sha/sha1dgst.d' is empty. What does this mean? How do I fix it? Do need to bother fixing it? The "make test" command appears to complete successfully other than this, finishing with "`test' is up to date." Steve Hay __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
