Re: .NET wrapper for OpenSSL
Frank This is a very interesting project. IMHO, there are 2 kinds of APIs we can provide: 1. A OpenSSL-like one. Original users of OpenSSL may like it. 2. Plugin as a service provider for the .NET crypto framework. Existing .NET codes will be easily re-configured to use the OpenSSL implementation. Weijun Frank Laub wrote: I've just recently put together a C# class library that wraps the crypto DLL via PInvoke. I was wondering if anyone here would be interested in such a thing or if perhaps I should just create a seperate project for it. It has many advantages but the biggest is allowing for ease of use of the OpenSSL crypto API via managed lanaguages. If anyone is interested, give me a shout. -Frank __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] printf size_t support.
On 3/13/06, Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> wrote: > > My stand on this is that it's good that BIO_printf and friends works > in compatible ways with printf, AND it is a good thing to make use of > good extensions that are available elsewhere even if they aren't part > of a formal standard. > > So, the real question is, do we have any use for the z modifier? That > is the question that should be discussed, not if z is formalised or > not. There is a need for the z modifier. The problem is only in how it's used. (I haven't looked at the BIO_printf code to see the full implementation.) However, size_t is the type of numbers returned by system calls, and since we're making use of those numbers, we need to be using the correct type. (There is no cross-platform automatic conversion, in C++ terms, of size_t to whatever is expected by any program that uses it, so whatever uses it should use size_t to be portable.) > > In my opinion we do need z, since size_t isn't always unsigned (with > Visual C 6, for example), and that some compilers pester us with > warnings if a size_t is used with a %lu specifier and even break > builds (with Visual C, for instance, last time I battled with this). I am in complete agreement, for the reasons stated above. (Even though they're probably not written such that most or even any people can understand them -- including myself a week from now. ;) ) The gist is, we use function calls that return size_t. We can't assume that size_t is of any particular type or size, and we can't assume that it will have an automatic conversion available to whatever we use it with. This is especially security-relevant to any kind of printf, whether system call or BIO_ call, since printf relies on sizes of parameters on the stack being precisely correct. So, the proper implementation is one that takes the possibility of a different-size size_t into account. The patch proposed does that, and (to my eye) appears to be compatible with both *NIX and Windows -- as well as (from Mr. Levitte's later statements) apparently having been developed and tested on Windows. Cheers, -Kyle H __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: .NET wrapper for OpenSSL
This would be a good thing to have available. I don't believe it should be in the core OpenSSL code, though, but it could be in contrib/ -- I would suggest making it available as a separate project on sourceforge or somewhere. -Kyle H On 3/13/06, Frank Laub <[EMAIL PROTECTED]> wrote: > I've just recently put together a C# class library that wraps the crypto DLL > via PInvoke. I was wondering if anyone here would be interested in such a > thing or if perhaps I should just create a seperate project for it. It has > many advantages but the biggest is allowing for ease of use of the OpenSSL > crypto API via managed lanaguages. If anyone is interested, give me a shout. > > -Frank > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
.NET wrapper for OpenSSL
I've just recently put together a C# class library that wraps the crypto DLL via PInvoke. I was wondering if anyone here would be interested in such a thing or if perhaps I should just create a seperate project for it. It has many advantages but the biggest is allowing for ease of use of the OpenSSL crypto API via managed lanaguages. If anyone is interested, give me a shout. -Frank
[PATCH] Convert destest.c to use DES_* functions.
Hi,
The attached patch converts destest.c to use DES_* function
instead of des_* functions. It's the only part of the source
that is still using the old names.
Kurt
Index: crypto/des/destest.c
===
RCS file: /home/kurt/openssl/cvs/openssl-cvs/openssl/crypto/des/destest.c,v
retrieving revision 1.38
diff -u -r1.38 destest.c
--- crypto/des/destest.c23 Jun 2005 21:53:56 - 1.38
+++ crypto/des/destest.c12 Mar 2006 19:18:49 -
@@ -335,8 +335,8 @@
{
int j,err=0;
unsigned int i;
- des_cblock in,out,outin,iv3,iv2;
- des_key_schedule ks,ks2,ks3;
+ DES_cblock in,out,outin,iv3,iv2;
+ DES_key_schedule ks,ks2,ks3;
unsigned char cbc_in[40];
unsigned char cbc_out[40];
DES_LONG cs;
@@ -383,7 +383,7 @@
/* if (memcmp(cbc_out,cbc3_ok,
(unsigned int)(strlen((char *)cbc_data)+1+7)/8*8) != 0)
{
- printf("des_ede3_cbc_encrypt encrypt error\n");
+ printf("DES_ede3_cbc_encrypt encrypt error\n");
err=1;
}
*/
@@ -394,7 +394,7 @@
{
unsigned int n;
- printf("des_ede3_cbcm_encrypt decrypt error\n");
+ printf("DES_ede3_cbcm_encrypt decrypt error\n");
for(n=0 ; n < i ; ++n)
printf(" %02x",cbc_data[n]);
printf("\n");
@@ -412,8 +412,8 @@
memcpy(in,plain_data[i],8);
memset(out,0,8);
memset(outin,0,8);
- des_ecb_encrypt(&in,&out,ks,DES_ENCRYPT);
- des_ecb_encrypt(&out,&outin,ks,DES_DECRYPT);
+ DES_ecb_encrypt(&in,&out,&ks,DES_ENCRYPT);
+ DES_ecb_encrypt(&out,&outin,&ks,DES_DECRYPT);
if (memcmp(out,cipher_data[i],8) != 0)
{
@@ -440,8 +440,8 @@
memcpy(in,plain_data[i],8);
memset(out,0,8);
memset(outin,0,8);
- des_ecb2_encrypt(&in,&out,ks,ks2,DES_ENCRYPT);
- des_ecb2_encrypt(&out,&outin,ks,ks2,DES_DECRYPT);
+ DES_ecb3_encrypt(&in,&out,&ks,&ks2,&ks,DES_ENCRYPT);
+ DES_ecb3_encrypt(&out,&outin,&ks,&ks2,&ks,DES_DECRYPT);
if (memcmp(out,cipher_ecb2[i],8) != 0)
{
@@ -468,7 +468,7 @@
memset(cbc_out,0,40);
memset(cbc_in,0,40);
memcpy(iv3,cbc_iv,sizeof(cbc_iv));
- des_ncbc_encrypt(cbc_data,cbc_out,strlen((char *)cbc_data)+1,ks,
+ DES_ncbc_encrypt(cbc_data,cbc_out,strlen((char *)cbc_data)+1,&ks,
&iv3,DES_ENCRYPT);
if (memcmp(cbc_out,cbc_ok,32) != 0)
{
@@ -477,7 +477,7 @@
}
memcpy(iv3,cbc_iv,sizeof(cbc_iv));
- des_ncbc_encrypt(cbc_out,cbc_in,strlen((char *)cbc_data)+1,ks,
+ DES_ncbc_encrypt(cbc_out,cbc_in,strlen((char *)cbc_data)+1,&ks,
&iv3,DES_DECRYPT);
if (memcmp(cbc_in,cbc_data,strlen((char *)cbc_data)) != 0)
{
@@ -495,19 +495,19 @@
memset(cbc_out,0,40);
memset(cbc_in,0,40);
memcpy(iv3,cbc_iv,sizeof(cbc_iv));
- des_xcbc_encrypt(cbc_data,cbc_out,strlen((char *)cbc_data)+1,ks,
+ DES_xcbc_encrypt(cbc_data,cbc_out,strlen((char *)cbc_data)+1,&ks,
&iv3,&cbc2_key,&cbc3_key, DES_ENCRYPT);
if (memcmp(cbc_out,xcbc_ok,32) != 0)
{
- printf("des_xcbc_encrypt encrypt error\n");
+ printf("DES_xcbc_encrypt encrypt error\n");
err=1;
}
memcpy(iv3,cbc_iv,sizeof(cbc_iv));
- des_xcbc_encrypt(cbc_out,cbc_in,strlen((char *)cbc_data)+1,ks,
+ DES_xcbc_encrypt(cbc_out,cbc_in,strlen((char *)cbc_data)+1,&ks,
&iv3,&cbc2_key,&cbc3_key, DES_DECRYPT);
if (memcmp(cbc_in,cbc_data,strlen((char *)cbc_data)+1) != 0)
{
- printf("des_xcbc_encrypt decrypt error\n");
+ printf("DES_xcbc_encrypt decrypt error\n");
err=1;
}
#endif
@@ -534,16 +534,16 @@
/* i=((i+7)/8)*8; */
memcpy(iv3,cbc_iv,sizeof(cbc_iv));
- des_ede3_cbc_encrypt(cbc_data,cbc_out,16L,ks,ks2,ks3,&iv3,
+ DES_ede3_cbc_encrypt(cbc_data,cbc_out,16L,&ks,&ks2,&ks3,&iv3,
DES_ENCRYPT);
- des_ede3_cbc_encrypt(&(cbc_data[16]),&(cbc_out[16]),i-16,ks,ks2,ks3,
+ DES_ede3_cbc_encrypt(&(cbc_data[16]),&(cbc_out[16]),i-16,&ks,&ks2,&ks3,
&iv3,DES_ENCRYPT);
if (memcmp(cbc_out,cbc3_ok,
(unsigned int)(strlen((char *)cbc_data)+1+7)/8*8) != 0)
{
unsigned int n;
- printf("des_ede3_cbc_encrypt encrypt error\n");
+ printf("DES_ede3_cbc_encrypt encrypt error\n")
[PATCH] Remove old libdes support?
Hi,
Various places in the source say that old des support is going to
be removed before 1.0. I think it's time to move forward.
I think we have 2 options:
- Completly drop the old des support, including des_old.h
- Drop the libdes compatibility, so that it's only compatible
with older openssl versions, and people can still use the des_*
versions.
The second option would be removing the des_old.c, des_old2.c
files, and change des_old.h to remove the libdes compatibility.
I think the attached patch removes most of it, but maybe more
can/should be removed?
We could also change des.h to not default to
OPENSSL_ENABLE_OLD_DES_SUPPORT.
Kurt
Index: crypto/des/Makefile
===
RCS file: /home/kurt/openssl/cvs/openssl-cvs/openssl/crypto/des/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- crypto/des/Makefile 4 Feb 2006 01:45:28 - 1.8
+++ crypto/des/Makefile 13 Mar 2006 21:07:37 -
@@ -30,7 +30,7 @@
qud_cksm.c rand_key.c rpc_enc.c set_key.c \
des_enc.c fcrypt_b.c \
xcbc_enc.c \
- str2key.c cfb64ede.c ofb64ede.c ede_cbcm_enc.c des_old.c des_old2.c \
+ str2key.c cfb64ede.c ofb64ede.c ede_cbcm_enc.c \
read2pwd.c
LIBOBJ= set_key.o ecb_enc.o cbc_enc.o \
@@ -39,7 +39,7 @@
ofb_enc.o str2key.o pcbc_enc.o qud_cksm.o rand_key.o \
${DES_ENC} \
fcrypt.o xcbc_enc.o rpc_enc.o cbc_cksm.o \
- ede_cbcm_enc.o des_old.o des_old2.o read2pwd.o
+ ede_cbcm_enc.o read2pwd.o
SRC= $(LIBSRC)
@@ -157,18 +157,6 @@
des_enc.o: ../../include/openssl/stack.h ../../include/openssl/symhacks.h
des_enc.o: ../../include/openssl/ui.h ../../include/openssl/ui_compat.h
des_enc.o: des_enc.c des_locl.h ncbc_enc.c spr.h
-des_old.o: ../../include/openssl/des.h ../../include/openssl/des_old.h
-des_old.o: ../../include/openssl/e_os2.h ../../include/openssl/opensslconf.h
-des_old.o: ../../include/openssl/ossl_typ.h ../../include/openssl/rand.h
-des_old.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h
-des_old.o: ../../include/openssl/symhacks.h ../../include/openssl/ui.h
-des_old.o: ../../include/openssl/ui_compat.h des_old.c
-des_old2.o: ../../include/openssl/des.h ../../include/openssl/des_old.h
-des_old2.o: ../../include/openssl/e_os2.h ../../include/openssl/opensslconf.h
-des_old2.o: ../../include/openssl/ossl_typ.h ../../include/openssl/rand.h
-des_old2.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h
-des_old2.o: ../../include/openssl/symhacks.h ../../include/openssl/ui.h
-des_old2.o: ../../include/openssl/ui_compat.h des_old2.c
ecb3_enc.o: ../../include/openssl/des.h ../../include/openssl/des_old.h
ecb3_enc.o: ../../include/openssl/e_os2.h ../../include/openssl/opensslconf.h
ecb3_enc.o: ../../include/openssl/ossl_typ.h ../../include/openssl/safestack.h
Index: crypto/des/des_old.h
===
RCS file: /home/kurt/openssl/cvs/openssl-cvs/openssl/crypto/des/des_old.h,v
retrieving revision 1.22
diff -u -r1.22 des_old.h
--- crypto/des/des_old.h7 Aug 2005 22:21:40 - 1.22
+++ crypto/des/des_old.h13 Mar 2006 21:02:43 -
@@ -3,26 +3,10 @@
/* WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
*
* The function names in here are deprecated and are only present to
- * provide an interface compatible with openssl 0.9.6 and older as
- * well as libdes. OpenSSL now provides functions where "des_" has
- * been replaced with "DES_" in the names, to make it possible to
- * make incompatible changes that are needed for C type security and
- * other stuff.
- *
- * This include files has two compatibility modes:
- *
- * - If OPENSSL_DES_LIBDES_COMPATIBILITY is defined, you get an API
- * that is compatible with libdes and SSLeay.
- * - If OPENSSL_DES_LIBDES_COMPATIBILITY isn't defined, you get an
- * API that is compatible with OpenSSL 0.9.5x to 0.9.6x.
- *
- * Note that these modes break earlier snapshots of OpenSSL, where
- * libdes compatibility was the only available mode or (later on) the
- * prefered compatibility mode. However, after much consideration
- * (and more or less violent discussions with external parties), it
- * was concluded that OpenSSL should be compatible with earlier versions
- * of itself before anything else. Also, in all honesty, libdes is
- * an old beast that shouldn't really be used any more.
+ * provide an interface compatible with openssl 0.9.6 and older.
+ * OpenSSL now provides functions where "des_" has been replaced
+ * with "DES_" in the names, to make it possible to make incompatible
+ * changes that are needed for C type security and other stuff.
*
* Please consider starting to use the DES_ functions rather than the
* des_ ones. The des_ functions will disappear completely before
@@ -131,7 +115,6 @@
} ks;
} _ossl_old_des_key_schedule[16];
-#ifndef OPENSSL_DES
T1_lib.c patch
if openssl has OPENSSL_NO_EC there is a small problem in t1_lib.c
Besides that I have the feeling that part of the point list code could
be simplified.
The lists supported are constant, so making an malloc etc and filling
this with
constant data looks a bit heavy.
regards
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
--- openssl-SNAP-20060313/ssl/t1_lib.c 2006-03-13 03:00:59.0 +0100
+++ openssl-SNAP-20060313+S/ssl/t1_lib.c2006-03-13 17:52:42.288071000
+0100
@@ -375,9 +375,9 @@ int ssl_parse_clienthello_tlsext(SSL *s,
fprintf(stderr,"\n");
#endif
}
+#endif /* OPENSSL_NO_EC */
data+=size;
}
-#endif /* OPENSSL_NO_EC */
*p = data;
return 1;
@@ -447,10 +447,10 @@ int ssl_parse_serverhello_tlsext(SSL *s,
fprintf(stderr,"\n");
#endif
}
+#endif /* OPENSSL_NO_EC */
data+=size;
}
-#endif /* OPENSSL_NO_EC */
if (data != d+n)
{
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH] printf size_t support.
In message <[EMAIL PROTECTED]> on Mon, 13 Mar 2006 10:05:38 +0100, [EMAIL PROTECTED] said: Stefan.Neis> > > Is the patch tested on windows ? Stefan.Neis> > > "z" modifier - I'm not sure that this is portable. Stefan.Neis> > Stefan.Neis> > if I remember correctly windows doesn't support this Stefan.Neis> > modifier (at least I was told this as we discussed this Stefan.Neis> > for another project) Stefan.Neis> Stefan.Neis> I'm not exactly sure, but I believe it's an extension of Stefan.Neis> glibc (or maybe of C99 ?). At least, it doesn't seem to Stefan.Neis> be supported by older Unix systems either, e.g. it's Stefan.Neis> apparently not supported by Solaris 7. I'm sorry to disrupt this cozy discussion, but does it really matter if z conforms to some formal standard or not? After all, we're not trying to *replace* printf and friends, we're just building something that works for our purposes and more, and most of all, works everywhere independently of the current libc. If we wanted to write a replacemeent for printf and friends, we wouldn't have prefixed it with BIO_, and then this discussion would actually be relevant! My stand on this is that it's good that BIO_printf and friends works in compatible ways with printf, AND it is a good thing to make use of good extensions that are available elsewhere even if they aren't part of a formal standard. So, the real question is, do we have any use for the z modifier? That is the question that should be discussed, not if z is formalised or not. In my opinion we do need z, since size_t isn't always unsigned (with Visual C 6, for example), and that some compilers pester us with warnings if a size_t is used with a %lu specifier and even break builds (with Visual C, for instance, last time I battled with this). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] printf size_t support.
Hi, > > Is the patch tested on windows ? > > "z" modifier - I'm not sure that this is portable. > > if I remember correctly windows doesn't support this modifier > (at least I was told this as we discussed this for another project) I'm not exactly sure, but I believe it's an extension of glibc (or maybe of C99 ?). At least, it doesn't seem to be supported by older Unix systems either, e.g. it's apparently not supported by Solaris 7. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
