Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL 1.0 beta 2
On Mon, May 25, 2009, Peter Waltenberg wrote: Up to the OpenSSL team. I'm happy to do any maintenance required, but it's up to them to merge it - or not. Given that there are a number of people using the patch now and AES-GCM is needed for new TLS modes, I'd hope it gets merged. I had a brief look at the patch. Thre are quite a few C++ style comments in there which cause issues on some compilers. If you up the gcc warning levels these will be obvious (see $gcc_devteam_warn in the Configure script). This can't go into 1.0.0 because that's in a feature freeze. It could go into HEAD (which will be 1.1.0) and 1.0.1 (no branch exists for this yet). This really needs EVP support though. Applications should avoid use of low level APIs because they prohibit the use of ENGINEs and such things as FIPS require the use of EVP. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: X.509 certificates with RSASSA-PSS signatures
On Sun, May 24, 2009, Martin Kaiser wrote: Hello Steve, Thus wrote Dr. Stephen Henson (st...@openssl.org): The best approach IMHO is to have a new pss public key algorithm to handle the case of PSS only keys and pass the ASN1 structures down to the specific method API via the ctrl mechanism. Hm, not sure if I understand this. Do you suggest having a new value for EPV_PKEY's type field to indicate pss? (Can't figure out quickly if type contains a NID_... value) PSS parameters would then be added to rsa_st? A while ago, I tried a new THIS_IS_PSS flag for EVP_PKEY's rsa_st. It worked but I'm not sure if it was a good approach. Probably, the EVP_PKEY_CTX was introduced to store such information... EVP_PKEY_CTX was introduced (by me!) to contain parameters relating to a specific cryptographic operation. Fixed parameters should go in EVP_PKEY. PSS can have both so we'd need a new EVP_PKEY type and/or expand the RSA structure too. Use of the ctrl mechanism will require some changes to ASN1_item_sign and ASN1_item_verify. The current code uses EVP_Sign*() and EVP_Verify*() which isn't flexible enough the new EVP_Digest*() API will need to be used instead. Check out the CMS code for an example, cms_sd.c passes a CMS SignerInfo structure down to the EVP_PKEY_METHOD via a ctrl. The method can then inspect or modify it as appropriate. In ASN1_item_*() we'd pass algor1, algor2, and it. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH] openssl 0.9.8k qnx diffs
Hi:
Here's a small patch that provides better support on QNX6.
Regards,
-seanb
--- Configure.orig 2009-02-16 03:44:22.0 -0500
+++ Configure 2009-05-25 10:31:04.0 -0500
@@ -390,7 +390,8 @@
# QNX
qnx4,cc:-DL_ENDIAN -DTERMIO::(unknown):::${x86_gcc_des}
${x86_gcc_opts}:,
-qnx6,cc:-DL_ENDIAN -DTERMIOS::(unknown)::-lsocket:${x86_gcc_des}
${x86_gcc_opts}:,
+QNX6,
gcc:-DTERMIOS-lsocket::${no_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
+QNX6-i386, gcc:-DL_ENDIAN -DTERMIOS -O2 -Wall-lsocket:${x86_gcc_des}
${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
SCO/Caldera targets.
#
--- config.orig 2009-02-16 03:43:41.0 -0500
+++ config 2009-05-25 10:33:21.0 -0500
@@ -769,6 +769,8 @@
t3e-cray-unicosmk) OUT=cray-t3e ;;
j90-cray-unicos) OUT=cray-j90 ;;
nsr-tandem-nsk) OUT=tandem-c89 ;;
+ x86pc-*-qnx6) OUT=QNX6-i386 ;;
+ *-*-qnx6) OUT=QNX6 ;;
*) OUT=`echo $GUESSOS | awk -F- '{print $3}'`;;
esac
--- util/shlib_wrap.sh.orig 2007-08-27 03:52:57.0 -0500
+++ util/shlib_wrap.sh 2009-05-25 10:31:49.0 -0500
@@ -80,7 +80,7 @@
# it into a script makes it possible to do so on multi-ABI
# platforms.
case $SYSNAME in
- *BSD) LD_PRELOAD=$LIBCRYPTOSO:$LIBSSLSO ;; # *BSD
+ *BSD|QNX) LD_PRELOAD=$LIBCRYPTOSO:$LIBSSLSO ;; # *BSD, QNX
*) LD_PRELOAD=$LIBCRYPTOSO $LIBSSLSO ;; # SunOS, Linux, ELF
HP-UX
esac
_RLD_LIST=$LIBCRYPTOSO:$LIBSSLSO:DEFAULT # Tru64, o32 IRIX
[openssl.org #1936] enhancement request - X509V3_EXT_get_nid
Hi,
I need to use a bit different definition of one of existing extension
methods. I have done it by putting the changed method in ext_list by
function X509V3_EXT_add. Unfortunately I have found that function
X509V3_EXT_get_nid seeks through standard_exts first and only then
through ext_list, so the standard method is found first, and the
changed one is never used, so changes described in attachment are necessary.
Is changing the order possible or even planned?
Best regards,
Libor Krystek
--- v3_lib-old.c2009-05-22 16:03:27.557510309 +0200
+++ v3_lib.c2009-05-22 16:00:24.108728645 +0200
@@ -101,12 +101,14 @@
int idx;
if(nid 0) return NULL;
tmp.ext_nid = nid;
+ if(ext_list)
+ {
+ idx = sk_X509V3_EXT_METHOD_find(ext_list, tmp);
+ if(idx != -1) return sk_X509V3_EXT_METHOD_value(ext_list, idx);
+ }
ret = OBJ_bsearch_ext(t, standard_exts, STANDARD_EXTENSION_COUNT);
if(ret) return *ret;
- if(!ext_list) return NULL;
- idx = sk_X509V3_EXT_METHOD_find(ext_list, tmp);
- if(idx == -1) return NULL;
- return sk_X509V3_EXT_METHOD_value(ext_list, idx);
+ return NULL;
}
const X509V3_EXT_METHOD *X509V3_EXT_get(X509_EXTENSION *ext)
[openssl.org #1937] Fix for mis-use of st_mode field of struct stat
This was found in a code sweep associated with the OpenSolaris bug:
6346809 S_IFxxx is not a bitmask but our programmers don't know
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6346809)
The issue is there are a few places where OpenSSL uses the st_mode field
of struct stat as a bit mask when it isn't.
The patch below was generated against 0.9.8a (but is still relevant for
0.9.8k and higher?).
Thanks,
-Mark
diff -ruN openssl-0.9.8a/apps/ca.c openssl-0.9.8a/apps/ca.c
--- openssl-0.9.8a/apps/ca.c2005-09-30 18:47:15.0 +0200
+++ openssl-0.9.8a/apps/ca.c2009-03-26 17:27:26.364972087 +0100
@@ -858,8 +858,8 @@
perror(outdir);
goto err;
}
-#ifdef S_IFDIR
- if (!(sb.st_mode S_IFDIR))
+#ifdef S_ISDIR
+ if (!S_ISDIR(sb.st_mode))
{
BIO_printf(bio_err,%s need to be a
directory\n,outdir);
perror(outdir);
diff -ruN openssl-0.9.8a/crypto/rand/randfile.c
openssl-0.9.8a/crypto/rand/randfile.c
--- openssl-0.9.8a/crypto/rand/randfile.c 2005-05-21 19:39:52.0
+0200
+++ openssl-0.9.8a/crypto/rand/randfile.c 2009-03-26 17:28:39.081971620
+0100
@@ -110,8 +110,8 @@
in=fopen(file,rb);
if (in == NULL) goto err;
-#if defined(S_IFBLK) defined(S_IFCHR)
- if (sb.st_mode (S_IFBLK | S_IFCHR)) {
+#if defined(S_ISBLK) defined(S_ISCHR)
+ if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
/* this file is a device. we don't want read an infinite number
* of bytes from a random device, nor do we want to use buffered
* I/O because we will waste system entropy.
@@ -153,8 +153,8 @@
i=stat(file,sb);
if (i != -1) {
-#if defined(S_IFBLK) defined(S_IFCHR)
- if (sb.st_mode (S_IFBLK | S_IFCHR)) {
+#if defined(S_ISBLK) defined(S_ISCHR)
+ if (S_ISBLK(sb.st_mode) || S_ISCHR(sb.st_mode)) {
/* this file is a device. we don't write back to it.
* we succeed on the assumption this is some sort
* of random device. Otherwise attempting to write to
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #1938] Fixes for pem.pod and hmac.pod
Find attached a couple of fixes for hmac.pod and pem.pod. The patches simply update the Name sections of the relevant pod file so that man pages are properly generated for the PEM_* and HMAC_* routines. The patches were generated against 0.9.8a but also apply to 0.9.8k. Thanks, -Mark diff -ruN openssl-0.9.8a/doc/crypto/pem.pod openssl-0.9.8a/doc/crypto/pem.pod --- openssl-0.9.8a/doc/crypto/pem.pod 2004-03-22 00:03:52.0 +0100 +++ openssl-0.9.8a/doc/crypto/pem.pod 2009-04-10 12:05:36.443643142 +0200 @@ -2,7 +2,7 @@ =head1 NAME -PEM - PEM routines +PEM, PEM_read_bio_PrivateKey, PEM_read_PrivateKey, PEM_write_bio_PrivateKey, PEM_write_PrivateKey, PEM_write_bio_PKCS8PrivateKey, PEM_write_PKCS8PrivateKey, PEM_write_bio_PKCS8PrivateKey_nid, PEM_write_PKCS8PrivateKey_nid, PEM_read_bio_PUBKEY, PEM_read_PUBKEY, PEM_write_bio_PUBKEY, PEM_write_PUBKEY, PEM_read_bio_RSAPrivateKey, PEM_read_RSAPrivateKey, PEM_write_bio_RSAPrivateKey, PEM_write_RSAPrivateKey, PEM_read_bio_RSAPublicKey, PEM_read_RSAPublicKey, PEM_write_bio_RSAPublicKey, PEM_write_RSAPublicKey, PEM_read_bio_RSA_PUBKEY, PEM_read_RSA_PUBKEY, PEM_write_bio_RSA_PUBKEY, PEM_write_RSA_PUBKEY, PEM_read_bio_DSAPrivateKey, PEM_read_DSAPrivateKey, PEM_write_bio_DSAPrivateKey, PEM_write_DSAPrivateKey, PEM_read_bio_DSA_PUBKEY, PEM_read_DSA_PUBKEY, PEM_write_bio_DSA_PUBKEY, PEM_write_DSA_PUBKEY, PEM_read_bio_DSAparams, PEM_read_DSAparams, PEM_write_bio_DSAparams, PEM_write_DSAparams, PEM_read_bio_DHparams, PEM_read_DHparams, PEM_write_bio_DHparams, PEM_write_DHparams, PEM_read_bio_X509, PEM_read_X509, PEM_write_bio_X509, PEM_write_X509, PEM_read_bio_X509_AUX, PEM_read_X509_AUX, PEM_write_bio_X509_AUX, PEM_write_X509_AUX, PEM_read_bio_X509_REQ, PEM_read_X509_REQ, PEM_write_bio_X509_REQ, PEM_write_X509_REQ, PEM_write_bio_X509_REQ_NEW, PEM_write_X509_REQ_NEW, PEM_read_bio_X509_CRL, PEM_read_X509_CRL, PEM_write_bio_X509_CRL, PEM_write_X509_CRL, PEM_read_bio_PKCS7, PEM_read_PKCS7, PEM_write_bio_PKCS7, PEM_write_PKCS7, PEM_read_bio_NETSCAPE_CERT_SEQUENCE, PEM_read_NETSCAPE_CERT_SEQUENCE, PEM_write_bio_NETSCAPE_CERT_SEQUENCE, PEM_write_NETSCAPE_CERT_SEQUENCE - PEM routines =head1 SYNOPSIS diff -ruN openssl-0.9.8a/doc/crypto/hmac.pod openssl-0.9.8a/doc/crypto/hmac.pod --- openssl-0.9.8a/doc/crypto/hmac.pod 2002-07-18 20:54:45.0 +0200 +++ openssl-0.9.8a/doc/crypto/hmac.pod 2009-04-10 11:09:46.449071541 +0200 @@ -2,7 +2,7 @@ =head1 NAME -HMAC, HMAC_Init, HMAC_Update, HMAC_Final, HMAC_cleanup - HMAC message +HMAC, HMAC_CTX_init, HMAC_Init, HMAC_Init_ex, HMAC_Update, HMAC_Final, HMAC_CTX_cleanup, HMAC_cleanup - HMAC message authentication code =head1 SYNOPSIS
Re: [openssl.org #1021] about Window ce 5.0
HI, set the environement variable OSVERSION=WCE500 TARGETCPU=your target cpu could be armv4i or x86 or mips etc PALTFORM=standardsdk or enulator etc On Mar 11 2005, 8:53 pm, r...@openssl.org (jbkim via RT) wrote: Hi, I'm Kim in Korea. First, I'm not good at speaking English.. sorry about that.. I'm wonder about that openssl library is used for windows ce 5.0 I try compile openssl, following install.wce. but, I got the message d:\wcecompat/wcedefs.mak(20) : fatal error U1050: Unexpected OSVERSION environment variable value Stop. Have you any version or any way for Windows CE 5.0? Response to me, please. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL1.0 beta 2
Sorry about the C++ comments, I just found them in the GCM acceleration code. I'll fix those. There's no EVP layer for an encrypt + hash EVP API which would be needed for GCM and CCM to be usable via an EVP type interface. AES-CCM also has it's own quirks which would bite if you ever wanted to have it FIPS certified and it was used via a generic upper layer API. By specification it's not supposed to produce decrypted output if the hash fails which breaks the normal Init/Update/Update/.../Final pattern. If you mean the use of AES_set_encrypt_key() and AES_encrypt() - you'd have to get CCM and GCM explicitly tested to get them FIPS certified anyway, they won't gain FIPS certfication just because the underlying AES is FIPS certified so there's no real loss there. However I take the point about not using AES hardware where it exists. The code IBM uses is software only and the catch was that there's was a fairly decent performance penalty using EVP and it didn't seem worth the hit when CCM and GCM are only specified for use with AES. I'll change GCM and CCM to call the EVP functions. As a comment, there are a number of hardware cores offering AES-GCM now, so re-vectoring they whole of AES-GCM is possibly a more desirable option than using just AES hardware when available. Creating an encrypt +hash EVP API though - at least one that would also cope with CCM just gave me a headache - and there doesn't seem enough gain to do it for only one algorithm. As for CMAC, I just copied HMAC - which also lacks upper level EVP style entry points. Again, both algorithm famillies (CMAC/HMAC) probably should have a single generic EVP wrapper. CMAC is cleaner in that it does use the underlying EVP calls - the performance trade off there was against the ability to support multiple ciphers - no contest. Peter From: Dr. Stephen Henson st...@openssl.org To: openssl-dev@openssl.org Date: 25/05/2009 09:58 PM Subject:Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL1.0 beta 2 Sent by:owner-openssl-...@openssl.org On Mon, May 25, 2009, Peter Waltenberg wrote: Up to the OpenSSL team. I'm happy to do any maintenance required, but it's up to them to merge it - or not. Given that there are a number of people using the patch now and AES-GCM is needed for new TLS modes, I'd hope it gets merged. I had a brief look at the patch. Thre are quite a few C++ style comments in there which cause issues on some compilers. If you up the gcc warning levels these will be obvious (see $gcc_devteam_warn in the Configure script). This can't go into 1.0.0 because that's in a feature freeze. It could go into HEAD (which will be 1.1.0) and 1.0.1 (no branch exists for this yet). This really needs EVP support though. Applications should avoid use of low level APIs because they prohibit the use of ENGINEs and such things as FIPS require the use of EVP. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1935] AES-GCM, AES-CCM, CMAC updated for OpenSSL1.0 beta 2
On Tue, May 26, 2009, Peter Waltenberg wrote: AES-CCM also has it's own quirks which would bite if you ever wanted to have it FIPS certified and it was used via a generic upper layer API. By specification it's not supposed to produce decrypted output if the hash fails which breaks the normal Init/Update/Update/.../Final pattern. I saw that quirk in the spec. PKCS#11 specs handle that by effectively ignoring it. I'm not sure what FIPS would have to say about that: would be strange if it was impossible to validate CCM using PKCS#11. Perhaps they'd say that was the applications responsibility. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
