Re: PKCS#11 wrapper around OpenSSL
Victor B. Wagner wrote: > On 2007.11.19 at 14:51:16 -0600, Steven Bade wrote: > >> OpenCryptoki's Soft token based on openssl, was never intended to be a >> FIPS capable function, its simply intended to be an example for those >> who might wish to >> a) test PKCS#11 applications without having to have a card > > It is what I need. Really there is just two applications I really want > to test - Firefox and Thunderbird. We have successfuly used it with Firefox and Thunderbird. We also tested (LONG time ago) with Netscape Web Server. > > But it is interesting to know how fully PKCS#11 specification is > implemented in OpenCryptoki. How much effort would be needed to add new > profile for new cryptography algorithms, which are supported by recent > OpenSSL, but, probably, never taken into account by authors of > OpenCryptoki. Adding new Mechanisms is pretty straight foward. Corhent added the DH mechanisms, and their developer was able to do it in about 1 month time. Some mechanisms maybe more difficult than others to integrate. We tried to make the code modular and be extensible for new mechanisms and new crypto providers, but that said, nothing is perfect. We implement the full spec of API's, we don't implement all mechanisms, that is not required of Tokens (I've never seen a token which implements all the mechanisms). Any questions etc, should be addressed to the opencryptoki mailing list, which is linked to off the sourceforge project page. > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 wrapper around OpenSSL
I believe that Sun contributed a pretty robust PKCS#11 engine for openSSL. Soft token exists in opencryptoki today, if i ever find time, I will be porting this to OSX Alon Bar-Lev wrote: > On Nov 6, 2007 11:07 AM, Victor B. Wagner <[EMAIL PROTECTED]> wrote: >> I was asked by one user if we are planning to provide PKCS#11 module, >> based on OpenSSL (it was in the context of adding GOST algorithms >> support to the Mozilla-based software). > > I guess you mean software token... You wish to have PKCS#11 token that is > implemented using OpenSSL libraries. > > PKCS#11 usually used in order to access hardware cryptography, it would > be nice if the engine interface of OpenSSL would have PKCS#11, it would > have been more standard, and allow supporting features that are not currently > supported by the engine interface, such as loading certificates from engine or > authenticating to the agent during usage etc.. > > In order to allow OpenSSL based application to use PKCS#11 properly with > minimum changes, I've written pkcs11-helper library [1]. > > But if you wish only have PKCS#11 soft token implemented using OpenSSL, > it should not too complex to achieve. > > Best Regards, > Alon Bar-Lev. > > [1] http://www.opensc-project.org/pkcs11-helper > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 wrapper around OpenSSL
OpenCryptoki's Soft token based on openssl, was never intended to be a FIPS capable function, its simply intended to be an example for those who might wish to a) test PKCS#11 applications without having to have a card b) implement a token for an accelerator, other examples in opencryptoki are ICA (IBM Cryptographic Accelerator - which has also been permuted on Z Linux to access what ever crypto exists in a CLEAR KEY format.), the Broadcom support. As peter points out, there are some design decisions in the accelrator token model which preclude FIPS. Integration of a FIPS module under OC is possible, but the integration points need to be much higher up in the actual token stack, because one really needs to be passing encrypted "blobs" as keys to the module and have a true separation of the Module, from the API... Possible, yes, just does not exist today Peter Waltenberg wrote: > There are some things that are "quite hard" problems doing it the other way > round. FIPS certification with the OpenSSL engine plugin active is probably > the worst. > With PKCS#11 on top of OpenSSL you have an "industry standard" API, which > most hardware cards support. So you could swap a FIPS certified hardware > card with a FIPS certified PKCS#11 on top of OpenSSL. Using OpenSSL with > the engine code underneath doesn't make much sense in this context. > > Note that IBM does have an open source PKCS#11 which sits on top of > OpenSSL, search for opencryptoki. That doesn't solve the FIPS problem > though due to some details of it's design. > > There are downsides in PKCS#11, various vendors have interpreted the > standard in their own unique manner - so even though it's "standardized", > you still need some implementation specific code to function across vendor > implementations. It also has more (a lot more) setup overhead than OpenSSL > and although the user API isn't bad to implement, the provider side is > painful. > > I can guarantee it's feasible, but it is a lot of work. > > Peter > > > > > > > From: "Victor B. Wagner" <[EMAIL PROTECTED]> > > > > To: openssl-dev@openssl.org > > > > Date: 19/11/2007 20:27 > > > > Subject:PKCS#11 wrapper around OpenSSL > > > > > > > > > I was asked by one user if we are planning to provide PKCS#11 module, > based on OpenSSL (it was in the context of adding GOST algorithms > support to the Mozilla-based software). > > I doubt is this solution is technically feasable. > > As far as I know, most people do it other way around - write interfaces > which allow to USE PKCS#11 modules from within OpenSSL. I've seen at > least two engines which interface external PKCS#11 modules, and both are > incomplete, so if there is a PKCS#11 module which implements new public > key algorithm, they wouldn't allow to use it. > > But question is - is it a good idea to write PKCS#11 module which uses > OpenSSL (with all its engine support) for cryptography and supports > everything OpenSSL supports. > > I haven't studied PKCS#11 specification in great detail - it is very huge. > From the first glance it looks like just a big enough coding effort - > OpenSSL contains all neccessary cryptography routines and ASN.1 support > to provide PKCS#11 interface. > > May be someone on this list hav dug a bit deeper in the PKCS#11 > specification and can give more arguments pro or contra? > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project
Re: patent risk in encryption algotithm ?
DSA is unencumbered... I'm not sure about CAST On Thu, 2003-09-25 at 23:43, Boehme, Alfred wrote: > Hello, > > I've been asked, if there is any known patent risk in the encryption algorithm of > OpenSSL ? > Especially > DSA, CAST-128, and CAST-256 > was asked for. > > Can someone help me here ? > > Thanks in advance > > Alfred > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS#11 engines revisited
Afchine When are you going to submit a 0.9.7 pkcs#11 engine?? As I understand things, 0.9.6 will not have any new submissions included 0.9.7 is probably frozen, but the 0.9.8 function will be built on the 0.9.7 base and a PKCS#11 engine for 0.9.7 would be more likely to be incorporated into 0.9.8??? afchine madjlessi wrote: > I've made some improvements in the Bull trustway pkcs#11 engine to be more generic. > In this release, PKCS#11 functions are called through the functions list rather than >specific calls directly to PKCS#11 functions. So it is possible to point it to any >PKCS#11 shared library renamed libpkcs11.so on Linux. > A new flag, RSA_FLAG_GEN_KEY is added to RSA_method to allow the use of the >additionnal entries (rsa_generate_key, i2d/d2i_RSAPrivate/PublicKey) for crypto cards >which can generate and store keys. > PKCS#11 engine is added in crypto/engine/pkcs11. In the crypto code, rsagen & >d2i/i2dRSAPublic/PrivateKey functions can be redirected to the the PKCS11 engine when >RSA_FLAG_GEN_KEY is defined by the engine. > This PKCS#11 engine identifier is "pkcs11" rather than trustway in the last release. > I've tested this engine with apache-mod_ssl & cc2000 Bull crypto card on Linux. It >have been tested also on Win32. > Cheers, > Afchine Madjlessi > __ > [EMAIL PROTECTED] > Bull - Trustway R&D - Networking & Security > http://www.servers.bull.com/trustway > > > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- --- Steven Bade Senior Software Engineer IBM Linux Technology Center [EMAIL PROTECTED] [EMAIL PROTECTED] Security "this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all" (Cat in the Hat) "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" Who cares about converting MPH to KPH. I want to convert to Furlongs per Fortnight __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Update: Bull TrustWay PKCS#11 engine
The 64$ question from my mind is are you working on a 0.9.7 engine for PKCS#11... That's the one of particular interest to me in the long run. afchine madjlessi wrote: > You can find here the last updates for Trustway PKCS#11 engine. > > ChangeLog: > - patch update for openssl-engine-0.9.6d > - patch update for mod_ssl-2.2.10-1.3.26 > > Work on a generic non-intrusive version of pkcs11 engine implementation for > openssl is in progress. > I will submit it as soon as possible. > > Cheers, > Afchine > __ > [EMAIL PROTECTED] > Bull Trustway R&D - Networking & Security > http://www.servers.bull.com/trustway > > > > > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
We generate all keys within our "tokens" Some tokens such as the 4758 keep all the token objects within the secure boundary, and rely on the proper PKCS#11 attributes to control selection, keys generated stay within the FIPS4 boundary. Others which are accelerators, still use the PKCS#11 key generation calls (or object creation functions which could be done with the 4758 as well, but then these objects really can't be marked as NEVER_EXTRACTABLE because their origin is not really known or can be trusted). I don;t remember exactly what the Trustway patch added, but it would be nice to allow for engine specific key generation to be used through the normal key generation paths, as well as allow for normal calls to be used to instantiate the CERT within the PKCS#11 token BTW, afchine, I for some reason always get 2 copies of ALL your posts to the mailing list... afchine madjlessi wrote: > "Steven Bade" <[EMAIL PROTECTED]> writes: > > >>I'm not sure about the second question, but we found that the eracom >>engine submission was much more generic. When one of my co-workers >>tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway >>module there were many issues, as well as specific calls directly to >>PKCs#11 functions rather than through the function list. If I remember >>correctly the Eracom submission from last year was much more generic and >>we had to do nothing except point it to our shared library... No >>requirements for GKPCS11 headers, no direct function calls... >> >> > > I think that in the case of Eracom card, keys are generated by an external > way. > Trustway card generates and stores keys, it's the reason of changes in the > RSA methods. > If needed, I can add the include files in the patch, so it doesn't require > to get gpkcs11 > headers. > > afchine > > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl
I'm not sure about the second question, but we found that the eracom engine submission was much more generic. When one of my co-workers tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway module there were many issues, as well as specific calls directly to PKCs#11 functions rather than through the function list. If I remember correctly the Eracom submission from last year was much more generic and we had to do nothing except point it to our shared library... No requirements for GKPCS11 headers, no direct function calls... Richard Levitte via RT wrote: > I've just started looking at this, and I've got a couple of > questions: > > 1. could this engine be considered a general PKCS#11 engine, or are > there specific ties to Trustway. I'd prefer to see a general > PKCS#11 engine. > > 2. Those extra functions in the RSA method, are they really needed? > I understand that they provide a lot of automagic things, but then > it should be added in the ENGINE framework as something that would > be potentially available for any hardware (that supports that extra > functionality). Also, when it comes to loading keys, the current > modus operandi is to explicitely use the ENGINE key loading > functions rather than having some implicit functionality going on. > The reason is that we'd prefer not to surprise the users too much. > > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Name space collision
thanks for taking the patch into consideration... When I get back to work I'll see if i can;t find the AIX Linker options and pass them on... Richard Levitte - VMS Whacker wrote: > From: Steven Bade <[EMAIL PROTECTED]> > > sbade> It seems that building with -Wl,-Bsymbolic on the linker options for > sbade> creating the libcrypto.so makes this issue go away... > > Hmm, I guess that's a change to be made in Makefile.org. However, > except for GNU ld, I have no idea what the option to get this right > is, so it would be nice if those who know all the other linkers we're > attempting to support could chip in and tell us how to do this. > > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Name space collision
Harald... We build our software token with -Bsymbolic. In fact all the shared objects we create are with -Bsymbolic. Because of licensing issues I can't staticaly bind with libcrypto (and even under debug scenarios, it turns out that binding static to libcrypto.a the problem occurs as well so this does not fix) If you are going to over ride SHA1_Update, you had better override all the SHA1_* functions... Harald Koch wrote: >>Here is a patch I created for the Makefile.org file to correct the >>problem we were having... >> > > I wouldn't like to see this in OpenSSL by default; there are times when > you *want* to over-ride functions inside the library in your own > program, and times when you don't. > > I'd advise you instead to build your software token with -Bsymbolic and > link it against the static versions of libssl and/or libcrypto. That's > what we do for our Apache and iPlanet plugins, and it works on most > UNIXes (I'm currently having trouble with HP/UX, but doesn't everyone? :-) > > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Name space collision
Here is a patch I created for the Makefile.org file to correct the
problem we were having...
Steven Bade wrote:
> It seems that building with -Wl,-Bsymbolic on the linker options for
> creating the libcrypto.so makes this issue go away...
>
> Tom Wu wrote:
>
>> Steven Bade wrote:
>>
>>> We've created in the openCryptoki project a software token which
>>> uses openSSL's crypto routines... When running under the iplanet
>>> regression test suite we get a core dump in the key generation
>>> code... Tracing it down, the crash occurs in the SHA1_Update... one
>>> of the community members as a test changed the calls in the openSSL
>>> code to SHA1_Update to be FOO_SHA1_Update.
>>>
>>> Any of the more experienced openSSL developers out there have any
>>> suggestions of things we may try with regard to linker options or
>>> other ideas that we could do to address this collision (I doubt that
>>> I;m going to be able to get netscape to chance their function names
>>> :)
>>
>>
>>
>> We encountered the same problem here when loading OpenSSL-based
>> modules under iPlanet or the Netscape browser. Our solution was to
>> add macros to the OpenSSL includes to "remap" the offending symbols to
>> avoid conflicts. We also added placeholders for the old function
>> names that called the remapped functions to ensure that our library
>> binaries were still binary and source-compatible with unmodified
>> OpenSSL libraries.
>>
>>> thanks for your help...
>>
>>
>>
>> Tom
>>
>
>
--
Steven A. Bade
UNIX Network Security Cryptographic Strategy and Development Architecture
[EMAIL PROTECTED]
T/L 678-4799
(512)-838-4799
--
To convert from Hogsheads to Cubic Feet - Multiply by 8.4219
"Two-way communication is necessary to proactively facilitate acceptance
and involvement and to get insights about the journey it takes to get where
we want"
this mess is so big and so bad and so tall,
we cannot clean it up, there is no way at all
(Cat in the Hat)
--- Makefile.org.base Fri Apr 5 08:56:18 2002
+++ Makefile.orgFri Apr 5 08:56:36 2002
@@ -258,6 +258,7 @@
( set -x; ${CC} -shared -o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-Wl,-soname=lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} \
-Wl,--whole-archive lib$$i.a \
+ -Wl,-Bsymbolic \
-Wl,--no-whole-archive $$libs ${EX_LIBS} -lc ) || exit 1; \
libs="$$libs -l$$i"; \
done
Re: Name space collision
Thanks, but I don;t think that in this case this will help since the particular use of the function is down in the deep libcrypto code itself so creating macros for our calls internaly would not do much good... I've been able to get past some of these types of problems in the past with -Wl,-Bsymbolic. Which I;m trying in the openSSL 0.9.6c build now Tom Wu wrote: > Steven Bade wrote: > >> We've created in the openCryptoki project a software token which >> uses openSSL's crypto routines... When running under the iplanet >> regression test suite we get a core dump in the key generation code... >> Tracing it down, the crash occurs in the SHA1_Update... one of the >> community members as a test changed the calls in the openSSL code to >> SHA1_Update to be FOO_SHA1_Update. >> >> Any of the more experienced openSSL developers out there have any >> suggestions of things we may try with regard to linker options or >> other ideas that we could do to address this collision (I doubt that >> I;m going to be able to get netscape to chance their function names >> :) > > > We encountered the same problem here when loading OpenSSL-based modules > under iPlanet or the Netscape browser. Our solution was to add macros > to the OpenSSL includes to "remap" the offending symbols to avoid > conflicts. We also added placeholders for the old function names that > called the remapped functions to ensure that our library binaries were > still binary and source-compatible with unmodified OpenSSL libraries. > >> thanks for your help... > > > Tom > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Name space collision
Fred Not sure what Tom is using... but we're using openCryptoki which is the IBM LTC sponsored open source implementation of PKCS#11 it has nothing to do with gpkcs11, and is available at the IBM Developerworks site under the Common Public License... Frederic DONNAT wrote: > Hi Tom > > > You say that you where loading openssl based modules under iplanet. > Are you talking about gpkcs11 stored on www.sourceforge.net ? > Could you tell me more about this ? What are these modules ? Are they free ? Where >could i find them if there are free ? > > Thanks in advance > Fred > > > -Original Message- > From: Tom Wu [mailto:[EMAIL PROTECTED]] > Sent: Fri 04/05/2002 6:25 AM > To: [EMAIL PROTECTED] > Cc: > Subject: Re: Name space collision > > Steven Bade wrote: > >>We've created in the openCryptoki project a software token which >>uses openSSL's crypto routines... When running under the iplanet >>regression test suite we get a core dump in the key generation code... >>Tracing it down, the crash occurs in the SHA1_Update... one of the >>community members as a test changed the calls in the openSSL code to >>SHA1_Update to be FOO_SHA1_Update. >> >>Any of the more experienced openSSL developers out there have any >>suggestions of things we may try with regard to linker options or other >> ideas that we could do to address this collision (I doubt that I;m >>going to be able to get netscape to chance their function names :) >> > > We encountered the same problem here when loading OpenSSL-based modules > under iPlanet or the Netscape browser. Our solution was to add macros > to the OpenSSL includes to "remap" the offending symbols to avoid > conflicts. We also added placeholders for the old function names that > called the remapped functions to ensure that our library binaries were > still binary and source-compatible with unmodified OpenSSL libraries. > > >>thanks for your help... >> > > Tom > > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Name space collision
We've created in the openCryptoki project a software token which uses openSSL's crypto routines... When running under the iplanet regression test suite we get a core dump in the key generation code... Tracing it down, the crash occurs in the SHA1_Update... one of the community members as a test changed the calls in the openSSL code to SHA1_Update to be FOO_SHA1_Update. Any of the more experienced openSSL developers out there have any suggestions of things we may try with regard to linker options or other ideas that we could do to address this collision (I doubt that I;m going to be able to get netscape to chance their function names :) thanks for your help... -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding a new hardware accelerator
Christian... You might want to look at participating in our openCryptoki project rather than create a PKCS#11 implementation from scratch. If you go to http://www-124.ibm.com/developerworks/projects/openCryptoki/ you can get some information, or you can email me and I'll try and answer what ever questions you may have... [EMAIL PROTECTED] wrote: > I've implemented an openssl engine adaption for Utimaco's new hardware > security module CryptOn2. It is a pci card which today can do asymmetric > encryption, DES, 3DES3, SHA1, MD5, RIPEMD. Random number generation and > secure key storage will be implemented in the near future as part of a > PKCS#11 implementation. > My openssl-engine adaption is tested to work with openssl-engine-0.9.6b. > > My questions are: > - How can I distribute my code to have CryptOn2 integrated into > openssl-engine-0.9.6x? > - I looked into the current snapshot and found a lot of changes within the > engine part. It seems to me that hardware accelerated symmetric crypto and > hashing will also be supported by the future 0.9.7 release of openssl. How > can I support you with the 0.9.7 integration? Do I concentrate on the > engine adaption or on OpenBSD's /dev/crypto or on a PKCS#11 module? > - Do you need some CryptOn2 boards to verify the functionality? > > Christian > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 "Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want" this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
