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]
