AES, counter mode, etc.
When I looked at the AES API, it looked like there was no way to specify a block size independently of the key size. Is that intentional? Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: 1) You should be able to insert your own function for choosing a stream of counters. They don't have to be simple incrementing counters. 2) Counter mode can be used in a random-access manner. For example, if you encrypt a file with counter mode, you can then access the blocks of that file independently, as long as you know the counter value. John __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
'make test' problem in openssl-0.9.7-stable-SNAP-20020213
The 'make test' target is assuming that 'openssl.cnf' already exists in the location where OpenSSL is to be installed. This causes the test to fail in our environment where each new revision of a piece of software is given its own location. 'Make report' results for one system (Solaris 2.5.1) are attached but the problem appears to occur on all architectures. -- Dawn Whiteside Network Integration Specialist, IST University of Waterloo [EMAIL PROTECTED] testlog Description: Binary data
Re: OpenSSL (openssl-0.9.1c)
On Thu, Feb 14, 2002 at 04:16:40PM +0100, Richard Levitte - VMS Whacker wrote: From: Khan Alamgir [EMAIL PROTECTED] akh Please help! Use a more modern OpenSSL. The current release is 0.9.6c. And call SSL_library_init() :-) 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]
Re: OpenSSL Makefiles - SUGGESTION
On Thu, Feb 07, 2002 at 07:17:50AM -0500, Saju Paul Panikulam wrote: It would be nice to have a paragraph in the Makefiles to remove the TAB (^I) characters from the OpenSSL source and header files. The debugger on the platform that we use does not handle the TABs very well. Had to write a little script to remove them. We used expand but any editor (ex, ed, sed) should be able to do the same job. I don't think we should further complicate the Makefiles by including workarounds for this kind of problems with broken software. -- 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: cvs commit: openssl/crypto/err err.c
Bodo Moeller wrote: On Thu, Feb 14, 2002 at 02:42:36PM +0100, [EMAIL PROTECTED] wrote: Log: For some reason, getting the topmost error was done the same way as getting the bottommost one. I hope I understood correctly how this should be done. It seems to work when running evp_test in an environment where it can't find openssl.cnf. --- err.c 2002/01/24 17:17:29 1.51 +++ err.c 2002/02/14 13:42:33 1.51.2.1 @@ -720,7 +720,7 @@ if (es-bottom == es-top) return 0; if (top) - i=(es-bottom+1)%ERR_NUM_ERRORS; /* last error */ + i=es-top; /* last error */ else i=(es-bottom+1)%ERR_NUM_ERRORS; /* first error */ This fix for err.c is correct. But evp_test.c should never have called OPENSSL_config() because OPENSSL_config() uses the configuration file found in an OpenSSL *installation*. If we want to use a configuration file during 'make test', we should use one located in the source tree. It may be a good idea to test that configuration works, somehow. And yeah, I shouldn't have put config in evp_test, it was a mistake. 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]
Re: 'make test' problem in openssl-0.9.7-stable-SNAP-20020213
From: Dawn Whiteside [EMAIL PROTECTED] dwhitesi The 'make test' target is assuming that 'openssl.cnf' already exists dwhitesi in the location where OpenSSL is to be installed. This causes the dwhitesi test to fail in our environment where each new revision of a piece dwhitesi of software is given its own location. That was corrected yesterday, and openssl-0.9.7-stable-SNAP-20020214 and on should work better in this case. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: cvs commit: openssl/crypto/err err.c
On Fri, Feb 15, 2002 at 10:55:13AM +, Ben Laurie wrote: This fix for err.c is correct. But evp_test.c should never have called OPENSSL_config() because OPENSSL_config() uses the configuration file found in an OpenSSL *installation*. If we want to use a configuration file during 'make test', we should use one located in the source tree. It may be a good idea to test that configuration works, somehow. And yeah, I shouldn't have put config in evp_test, it was a mistake. Now with Steve's change (add a file name parameter to OPENSSL_config()) the OPENSSL_config() call can be put back into evp_test -- it just should use a file in the source code tree. -- 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: OpenSSL and ASP
Warning: loads of Win32-specific information inside. Proceed at your own
risk!
If by making it run via ASP/IIS you mean having it accessible from
Visual Basic/VBScript I'm afraid there's quite a bit of manual tweaking
that will have to be done.
In order for C functions to be at all usable from Visual Basic they
can't use the standard C calling convention. I can't really claim to
understand the logic behind this, so I'll abstain from commenting on it.
C functions that wish to be called from VB must instead use the
__stdcall convention, which handles the stack differently, and uses a
more intricate name decoration scheme.
If everything were easy, it would simply be a case of switching the
default calling convention in the OpenSSL makefiles to __stdcall by
supplying the /Gz compiler flag, but unfortunately things are very
rarely easy. Compilation will fail after just the odd file or two due to
a function pointer assignment in crypto/mem.c:
static void *(*malloc_func)(size_t) = malloc;
malloc, as defined in the Visual C++ malloc.h is actually:
void * __cdecl malloc(size_t)
This is unfortunately not the same type as:
static void *( __stdcall *malloc_func)(size_t)
Which our malloc_func function pointer has been expanded to by passing
the /Gz compiler switch.
So, we will either have to prepare the entire OpenSSL library for the
__stdcall convention by explicitly specifying as __cdecl the functions
we wish to be exempt from this rule, or we will have to explicitly
define every function we wish to have callable from VB as __stdcall.
Either way, this is going to require a bit of hacking.
An alternative to the above, which doesn't require rewriting OpenSSL
itself, once you have identified which functions you are going to call,
is to make yourself a wrapper library that uses __stdcall and simply
forwards the parameters to their OpenSSL equivalents:
int __stdcall std_X509_verify(X509* a, EVP_PKEY* r)
{
return X509_verify(a, r);
}
These new __stdcall functions can now be declared in VB as something
like:
Declare Function X509_verify Lib std_libeay32 Alias std_X509_verify _
(ByVal a As Long, r As Long) As Integer
Hope this gives you a few ideas on how to proceed. I might be able to
find some time to look into making OpenSSL VB-friendly, but I can't make
any promises at present. :-/
Best regards,
//oscar
Derek Strickland wrote:
[...] Is there no
way to make this run via ASP/IIS or at least use a built in IIS object that
will communicate effectively with an OpenSSL Listener on his end. Help
would be awesome. Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and ASP
here a resume some points last april that I found while trying to compile the library. - The basic approach is to compile the whole stuff with the /Gz option in order not to modify the 3000 exported function prototypes. - All main routines need a __cdecl main The #define for MAIN, all the *test.c modules, and openssl.c - The pwd_read routine needs some __cdecl in the declaration of signal and a pointer array. - in apps/s_socket.c one call to signal needs an addition of __decl for socket_cleanup - mem.c needed some treatment with Malloc, Free, Realloc The macro CRYPTO_malloc_init needs some fix, easiest way was to call with all parms NULL and tests that in mem.c Goal: allow __stdcall type functions to be passed. - There are 5 modules that call qsort and 2 that call bsearch. Instead of finding all the routines that call them, I copied qsort and bsearch into the source from mfc and made them __stdcall friendly. It seems possible to me to aviod that and replace all the _cmp functions of stack and set comparisions by __cdecl routines, it seems that are not suppoed to be called by applications anyway. - The asm routines : all declarations either need a __cdecl or the asm routines to be modified. With the first option some routines are not callable from VB, so be it for the moment. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and ASP
From: Oscar Jacobsson [EMAIL PROTECTED] oscar Hope this gives you a few ideas on how to proceed. I might be able to oscar find some time to look into making OpenSSL VB-friendly, but I can't make oscar any promises at present. :-/ Suggestion: there are packages out there that supply interfaces for OpenSSL to perl, python, ruby and I don't know what other languages. If you build a VB interface, it might be a good idea to release it as a separate package. The reason is very simple: maintainability. The OpenSSL dev team has already enough to do. Maintaining things that can be considered periferical is an extra load that probably is better handled by someone who is interested in that particular thing. The perfect example it the OpenSSL perl/ directory, which is supposed to be a perl interface, but which hasn't been touched at all for years and simply doesn't work any more. Others are maintaining a separate perl interface and have it release to CPAN. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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: cvs commit: openssl/crypto/err err.c
Bodo Moeller wrote: On Fri, Feb 15, 2002 at 10:55:13AM +, Ben Laurie wrote: This fix for err.c is correct. But evp_test.c should never have called OPENSSL_config() because OPENSSL_config() uses the configuration file found in an OpenSSL *installation*. If we want to use a configuration file during 'make test', we should use one located in the source tree. It may be a good idea to test that configuration works, somehow. And yeah, I shouldn't have put config in evp_test, it was a mistake. Now with Steve's change (add a file name parameter to OPENSSL_config()) the OPENSSL_config() call can be put back into evp_test -- it just should use a file in the source code tree. Its not a file name parameter it is the config section to use in order to use something other than openssl_conf. I thought that was one of the requested features. If I've misinterpreted it I can change it to specify an alternative config file. I'm not sure either is really needed if I move some more of the handling over to CONF_modules_load_file(). It isn't too hard to specify an alternative filename at present anyway just doing: if (CONF_modules_load_file(filename, section, flags) = 0) /* Some error occurred */ instead of calling OPENSSL_config() should do the trick. Doing things that way allows it to exit and tidy up gracefully rather than the abrupt exit(1) of OPENSSL_config(). Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.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: cvs commit: openssl/crypto/engine hw_sureware.c
Hmm. You did this with a different name from me (idx instead of index_)
- isn't that going to be irritating?
[EMAIL PROTECTED] wrote:
steve 14-Feb-2002 19:46:16
Modified:crypto/engine Tag: OpenSSL_0_9_7-stable hw_sureware.c
Log:
Fix warnings:
#if out some unused function.
index is a global function on some platforms.
Revision ChangesPath
No revision
No revision
1.2.2.1 +8 -4 openssl/crypto/engine/hw_sureware.c
Index: hw_sureware.c
===
RCS file: /e/openssl/cvs/openssl/crypto/engine/hw_sureware.c,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- hw_sureware.c 2002/02/07 20:44:07 1.2
+++ hw_sureware.c 2002/02/14 18:46:12 1.2.2.1
@@ -95,9 +95,11 @@
static EVP_PKEY *surewarehk_load_pubkey(ENGINE *e, const char *key_id,
UI_METHOD *ui_method, void *callback_data);
static void surewarehk_ex_free(void *obj, void *item, CRYPTO_EX_DATA *ad,
- int index,long argl, void *argp);
+ int idx,long argl, void *argp);
+#if 0
static void surewarehk_dh_ex_free(void *obj, void *item, CRYPTO_EX_DATA *ad,
- int index,long argl, void *argp);
+ int idx,long argl, void *argp);
+#endif
/* This function is aliased to mod_exp (with the mont stuff dropped). */
static int surewarehk_mod_exp_mont(BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
@@ -759,7 +761,7 @@
/* This cleans up an RSA/DSA KM key(do not destroy the key into the hardware)
, called when ex_data is freed */
static void surewarehk_ex_free(void *obj, void *item, CRYPTO_EX_DATA *ad,
- int index,long argl, void *argp)
+ int idx,long argl, void *argp)
{
if(!p_surewarehk_Free)
{
@@ -768,10 +770,11 @@
else
p_surewarehk_Free((char *)item,0);
}
+#if 0
/* This cleans up an DH KM key (destroys the key into hardware),
called when ex_data is freed */
static void surewarehk_dh_ex_free(void *obj, void *item, CRYPTO_EX_DATA *ad,
- int index,long argl, void *argp)
+ int idx,long argl, void *argp)
{
if(!p_surewarehk_Free)
{
@@ -780,6 +783,7 @@
else
p_surewarehk_Free((char *)item,1);
}
+#endif
/*
* return number of decrypted bytes
*/
__
OpenSSL Project http://www.openssl.org
CVS Repository Commit List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
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]
Re: cvs commit: openssl/crypto/engine hw_sureware.c
Ben Laurie wrote: Hmm. You did this with a different name from me (idx instead of index_) - isn't that going to be irritating? I hadn't realised someone else had come across this. It should be consistent I suppose. Personally I always find variable names with appended underscores a little odd looking. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.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]
zencod ENGINE for OpenSSL-SNAP-0.9.7-20020214
Title: zencod ENGINE for OpenSSL-SNAP-0.9.7-20020214 Hi all, My company (zencod) has developped a crypto accelerator which should provide: - asymetric computations: RSA, DSA, DH - random generation - digest functions: SHA1, MD5 - cipher operations: DES, RC4 So we have coded an ENGINE which should fit OpenSSL ENGINE features. The development has been made under Linux OS, Mdk-8.0 with: gcc-2.96-0.48mdk gcc version 2.96 2731 (Linux-Mandrake 8.0 2.96-0.48mdk) glibc-2.2.2-4mdk As you announce a new release, we would like to be part of it, so we send you our source code. I join an archive including: our zencod ENGINE source code: - /crypto/engine/hw_zencod.c - /crypto/engine/hw_zencod_err.h - /crypto/engine/hw_zencod_err.c - /crypto/engine/vendor_defns/hw_zencod.h a diff file for: - /crypto/engine/Makefile.ssl - /crypto/engine/engine.h - /crypto/engine/eng_all.c With have tested the ENGINE using our own tests file which are cloned from OpenSSL tests files. For each algorithm, we have used the test file corresponding with some modification to call our engine. (If you want the source file, just ask for it). We also have tested it using speed funtionnality, and we success to call the ENGINE from Apache Web Server through mod-ssl module. I hope you won't find it too badly coded. Best regards Fred Donnat Frederic RD Engineer ZENCOD www.zencod.com zencod-engine.tar.gz Description: zencod-engine.tar.gz
RE: OpenSSL and ASP
Thanks a bunch for the help and the insight. Hope it isn't too offensive to the list as a whole for me to do this publicly, but I am in awe of the whole experience. This is my first attempt to participate in an Open Source forum and you guys have been way helpful and prompt in your replies. Being a newbie to this list I don't know if it is proper decorum or bandwidth etiquette, but I just wanted to take a second to publicly recognize you for your assistance and say words that are all too often left unsaid, Thank you! -Original Message- From: Oscar Jacobsson [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 8:00 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Richard Levitte - VMS Whacker Subject: Re: OpenSSL and ASP Richard Levitte - VMS Whacker wrote: Suggestion: there are packages out there that supply interfaces for OpenSSL to perl, python, ruby and I don't know what other languages. If you build a VB interface, it might be a good idea to release it as a separate package. [reasoning deleted for brevity] Quite true. It would be far easier/cleaner, IMHO, to build a separate OpenSSL COM-wrapper, which could then be used to call OpenSSL from any given language that supports COM: VB, Java, C, C++ (the latter two wouldn't really need to go through the wrapper though. :-)) I've built a couple of different COM objects around the OpenSSL data types and their functions in my day, but I'm not familiar enough with the subtleties of OOP COM design to have acheived anything I'd call fully Reusable just yet. If anybody's looking for code examples however, I'm sure I should be able to throw something together. Best regards, //oscar __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES, counter mode, etc.
Thus spake John Viega: When I looked at the AES API, it looked like there was no way to specify a block size independently of the key size. Is that intentional? The NIST FIPS specifies AES with a 128-bit block size. Rijndael can be used in many other ways, but there is a significant performance loss in flexible implementations. 192- and 256-bit blocks may be added in the future, but there's higher priorities at the moment. Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: Already under discussion, though in reference to ALL modes :) S -- Stephen Sprunk So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me. --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
This is a test
Please ignore this message. I'm testing a bug database for OpenSSL so hopefully we'll be able to better keep track of bug reports... __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Thus spake Richard Levitte - VMS Whacker: From: Stephen Sprunk [EMAIL PROTECTED] stephen After implementing CBC, CFB, OFB, and CTR for AES (mostly plagiarized stephen from IDEA), I'm beginning to wonder why we have 40 different stephen implementations of the exact same algorithms in the first place. stephen Couldn't we have a general modes macro set, to which you pass the stephen ECB function of the cipher you're using? The current state is EAY legacy. His idea was that one should be able to pick out any of the algorithm directories and create a separate library for them (the old libdes is actually exactly the same as crypto/des/). First of all, do we still think that's necessary, given the wide acceptance of OpenSSL and libcrypto? In either case, it shouldn't be that difficult to develop a macro set that implements various modes. Pass in some function names, block size, types for casts, and let it generate the boilerplate. Worth doing? S -- Stephen Sprunk So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSSalways said exactly what pleased me. --Albert Einstein __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP macros for AES
Stephen Sprunk wrote: Thus spake Richard Levitte - VMS Whacker: The current state is EAY legacy. His idea was that one should be able to pick out any of the algorithm directories and create a separate library for them (the old libdes is actually exactly the same as crypto/des/). First of all, do we still think that's necessary, given the wide acceptance of OpenSSL and libcrypto? I'm not too bothered by that. We've been advising people to avoid the low level API where possible for a while now. In either case, it shouldn't be that difficult to develop a macro set that implements various modes. Pass in some function names, block size, types for casts, and let it generate the boilerplate. Worth doing? Maybe. It would be good to the the CFB and OFB modes working properly in general for other numbers of bits. I thought about moving the whole cipher mode handling to the EVP layer and trimming down the individual block ciphers to just encrypt/decrypt a single block at one point. However tests suggested that this would have a considerably impact on performance so we're probably stuck with the duplicate mode code for now. There is some duplication in individual cipher modes and some macros might help though there is some variation where some cipher optimize the storing of things like the IV in the most effective internal format. I wonder if we could do better by moving some of the mode handling to the assembly language routines and take advantage of some special cases to avoid function call overhead. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.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: AES, counter mode, etc.
John Viega wrote: Additionally, with respect to counter mode, it might be best to implement external to the EVP proper interface, just like HMAC. There are a few issues I see that make counter mode a bit different from other modes: 1) You should be able to insert your own function for choosing a stream of counters. They don't have to be simple incrementing counters. 2) Counter mode can be used in a random-access manner. For example, if you encrypt a file with counter mode, you can then access the blocks of that file independently, as long as you know the counter value. That could be handled by passing the relevant info in a cipher ctrl call in the same way that other cipher parameters can be changed. The HMAC stuff could conceivable also be handled with ctrls at the digest level. However the ctrl functionality doesn't exist at the digest level at present and the HMAC stuff has been around since the SSLeay days. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.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]
[PATCH] argument passing to app_verify_callback
Alas, I meant to send this in weeks ago, before it was too
late for 0.9.7; also apologies if this comes as a duplicate
(we're changing email addresses here, this can cause obvious
chicken-related problems with subscribers-post-only lists...).
This is a patch to actually hand the user-supplied argument
into calls to app_verify_callback. It affects the following 5
files:
ssl/ssl.h
ssl/ssl_cert.c
ssl/ssl_lib.c
ssl/ssltest.c
test/testssl
In the first three cases, the change is 1-3 lines of code,
and a few more lines of comments (e.g. removing comments
saying that the argument is ignored); there's a slightly
larger chunk of code to test it in ssltest.c. The implementation
was done against the 12/09 snapshot, and the patch re-generated
and re-tested against the 2/12 snapshot. (The patch applies
cleanly to 2/13 as well, but that snap fails to build for me for
unrelated reasons already mentioned on the list.)
thanks,
Diana Smetters
PARC
==
BEGIN LONG BACKGROUND/RATIONALE, SKIP IF UNINTERESTED
Why this is useful: I'm looking at generating
an updated Java SSL package that wraps OpenSSL and matches the
JDK1.4 SSL APIs (there is at least one Java wrapper for OpenSSL,
but it doesn't match any of the recent APIs distributed by Sun).
One of the things offered by this API is the ability to have the
code verifying the certificates passed in the handshake do so by
calling back into a piece of arbitrary Java code. That Java code
can be object instance specific (e.g. it can depend on state contained
in a particular object instance), and the object providing it is tied
to a particular SSL context. That means to find the code to call back
into from the OpenSSL side, you have to know which particular Java object
instance contains that code. Without passing either the SSL context
or an argument into the app_verify_callback, it's hard to do that
(there might be some table-based hack you could do, but...).
Since the API was already defined to take an app-specified argument,
it seems the most effective solution would be to fix the bug whereby
the argument is ignored. Taking the alternate route of relying on
the built-in verification algorithms and then using the verify_callback
at the end to override the built-in behavior had two problems:
first, that callback takes no app-defined args, and there's no
reasonable way to change that. Second, it is very likely to end up
with duplicated work, as the app isn't going to know that all that
checking is being done ahead for it; it isn't in other Java SSL
implementations that are using these callback mechanisms, and
so relying on it would prevent this being a drop-in replacement.
Keep in mind that 99.9% of Java applications using SSL do *not* use
this option to manage verification themselves, they rely on built-in
behavior provided by their SSL package. (In this case, that would
result in them using OpenSSL's standard chain verification code.)
I'm hoping to distribute this work freely; it'll be a lot easier for
people to use if it doesn't require patching OpenSSL.
If there's a better way of doing this that I've missed, I'd love
to hear about it offline.
Personally, I like and use this feature of the Java API because
I do research in things like new ways of handling trust management,
certificates, etc.
END BACKGROUND
diff -ur ./ssl/ssl.h ../openssl-SNAP-20020212/ssl/ssl.h
--- ./ssl/ssl.h Mon Jan 14 16:03:04 2002
+++ ../openssl-SNAP-20020212/ssl/ssl.h Thu Feb 14 12:03:14 2002
@@ -608,7 +608,7 @@
/* if defined, these override the X509_verify_cert() calls */
int (*app_verify_callback)();
- char *app_verify_arg; /* never used; should be void * */
+ void *app_verify_arg; /* app-supplied argument passed to callback function */
/* Default password callback. */
pem_password_cb *default_passwd_callback;
@@ -1232,7 +1232,7 @@
void SSL_CTX_set_verify(SSL_CTX *ctx,int mode,
int (*callback)(int, X509_STORE_CTX *));
void SSL_CTX_set_verify_depth(SSL_CTX *ctx,int depth);
-void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, int (*cb)(),char *arg);
+void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, int (*cb)(),void *arg);
#ifndef OPENSSL_NO_RSA
int SSL_CTX_use_RSAPrivateKey(SSL_CTX *ctx, RSA *rsa);
#endif
diff -ur ./ssl/ssl_cert.c ../openssl-SNAP-20020212/ssl/ssl_cert.c
--- ./ssl/ssl_cert.cWed Oct 24 09:01:31 2001
+++ ../openssl-SNAP-20020212/ssl/ssl_cert.c Thu Feb 14 12:03:14 2002
@@ -483,7 +483,7 @@
X509_STORE_CTX_set_verify_cb(ctx, s-verify_callback);
if (s-ctx-app_verify_callback != NULL)
- i=s-ctx-app_verify_callback(ctx); /* should pass app_verify_arg */
+ i=s-ctx-app_verify_callback(ctx, s-ctx-app_verify_arg);
else
{
#ifndef OPENSSL_NO_X509_VERIFY
diff -ur ./ssl/ssl_lib.c ../openssl-SNAP-20020212/ssl/ssl_lib.c
--- ./ssl/ssl_lib.c Fri Feb 8 08:00:55 2002
+++
Re: EVP macros for AES
From: Stephen Sprunk [EMAIL PROTECTED] stephen The current state is EAY legacy. His idea was that one should be able stephen to pick out any of the algorithm directories and create a separate stephen library for them (the old libdes is actually exactly the same as stephen crypto/des/). stephen stephen First of all, do we still think that's necessary, given the wide stephen acceptance of OpenSSL and libcrypto? Actually, with the dependence on opensslconf.h, we have already broken that pattern. stephen In either case, it shouldn't be that difficult to develop a macro set stephen that implements various modes. Pass in some function names, block stephen size, types for casts, and let it generate the boilerplate. Worth stephen doing? I've been playing with something like that for a few weeks now. I'll get back about that in a few days. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ 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]
