Geoff, thanks for your help.
I will go this way.
> -----Original Message-----
> From: Geoff Thorpe [mailto:[EMAIL PROTECTED]]
> Sent: 23 February 2001 18:14
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: ENGINE test
>
>
> Hi there,
>
> On Fri, 23 Feb 2001, Richard Levitte - VMS Whacker wrote:
>
> > From: Corinne Dive-Reclus <[EMAIL PROTECTED]>
> >
> > CDive> Because the job has been already done for
> nCipher, Rainbow and
> > CDive> Atalla, I thought perhaps you have a ready-to-use engine test
> > CDive> suite.
> >
> > Hmm, the tests have mostly (at least for me) been done "by hand",
> > depending on the functionality the hardware in question provides.
>
> Well, there is a pretty handy test suite available to you,
> but it doesn't really
> fit the typical definitions.
>
> openssl speed -engine <whatever> [optionally-specify-a-test]
> openssl s_server -engine <whatever>
> [Then hit s_server with s_client, a web-browser, anything
> else. Also, try
> different certs/keys/CAfiles depending on what your
> ENGINE supports - eg.
> hardware keys, acceleration, both, etc etc]
> openssl s_client -engine <whatever> -connect <host:port>
> [Doesn't really gain you much over s_server]
> mod_ssl
> [Compile mod_ssl with apache, mm, and openssl-engine-0.9.6
> (may require you
> to backfit the engine slightly - this is easy though), or
> try building with
> a snapshot of openssl-0.9.7-dev - YMMV. Then use
> SSLCryptoDevice, turn
> session caching off, and slam the web server with your
> favourite ssl
> benchmarking tool].
>
> There's probably others I've skipped over.
>
> But as you hinted upon earlier, one thing that is
> conspicuously absent from that
> list of existing "tests" is something to really rip into
> multi-threading.
>
> > CDive> I am not too confident about the BN_() bits I have written to
> > CDive> interact with my library and wanted to check it is
> OK even if a
> > CDive> multi-threads case.
> >
> > If that's to interact with whatever library that interfaces the
> > hardware, so far we've simply trusted that library to handle it.
> > I'm not sure anyone worries about threading and BN routines. The
> > locking is usually done, if needed, at a much higher level.
>
> Hmm .. yes and no. It depends if you're dealing with state in the
> hardware-specific engine code. Eg. if you store global
> pointers, contexts,
> handles, etc. Also, it can become a lot more critical (and
> need a lot more
> attention and testing) if you're embedding hardware-specific
> information inside
> the keys themselves - eg. in the "ex_data" of an RSA, DSA, or
> DH key for
> example. Acceleration-only support is certainly quite
> straightforward and isn't
> hard from the engine point of view - any external shared
> libraries loaded by the
> engine need to be thread-safe of course, but that's SEP.
>
> > CDive> Anyway, if not such test already exists, can I reuse a
> > CDive> OpenSSL-based multithreaded utility ?
> >
> > Sure, why not?
>
> If one exists, yes - that will do nicely. The advantage of
> using the kind of
> "test suite" (if we can call it that) I mentioned above, is
> that it so happens
> it's precisely the sort of scenario users will want to be
> using. Test suites are
> usually a collection of "specialised and highly tuned"
> applications for
> hammering away at code - which is kind of ironic given that
> most users aren't
> using those test suites when they grab your code. Ie. it is a
> good deal more
> important whether it works or not with their applications
> than whether it works
> with some arcane test suite. :-)
>
> Seriously, it *should* work with everything of course,
> including test suites.
> But reusing engine-enabled applications for testing is the
> way to go no matter
> what else you do. Even if there are bugs or quirks in the
> applications that make
> testing difficult - it highlights to you any weirdness you
> will have to support
> anyway when users start using your code.
>
> Kind of like a test suite that can verify S/MIME compliancy.
> It's important to
> prevent creating YASOKAB ("yet another set of kludges and
> breakage") in the pool
> of existing implementations - but it's even more important to
> see if your
> implementation can interoperate with real world users and tools. An
> implementation that only complies with the standards as
> written is probably an
> S/MIME implementation that would work perfectly and
> interoperate perfectly with
> exactly nothing on the market. That's not to say
> openssl-engine applications are
> all as broken as ... well ... I'd best not mention popular S/MIME
> implementations lest their lawyers are scoping the mail lists
> for fresh meat ...
> but it's better to know in advance what it takes to get
> popular applications
> working well with your code, rather than what it takes to get
> your code working
> to specifications.
>
> Cheers,
> Geoff
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
