Hi, * Aleix Conchillo Flaque ([EMAIL PROTECTED]) wrote: > > as you can see, hardware is slower. my box is an Intel P4 at 1,4 GHz and > is a bit faster than the processors in the nShiled (i think the model > i'm trying is one of the worstest). i've tried the hardware version of > my program with a multiprocess and i've gain more performace (uses two > processors).
Yup, makes sense. > but, what if i use a dual pentium box with P4 at 2GHz or a fastest > machine? this will be faster and cheaper than the cryptographic > hardware. eventhough, the cryptographic hardware has more fetures than > just do operations (at least the nShield), which may be is the good > thing. That's the rub, essentially. I'll back off from making any grotesque personal commentaries on the merits of cryptographic hardware for this sort of thing - it's a can of worms and I've no particular desire to go fishing. The least grotesque/personal version I can manage summarises something like this; many people would have you believe there is a security gain from using hardware that can generate and operate private keys and never expose the raw key material outside a dedicated hardware perimeter. There are others who would have you believe the actual security gain is neglible from said devices because they addresses exposures that can be as easily addressed by good software design and not doing "stupid things". There is also an argument that states that if you can get "into" the memory-space (and user-privileges) containing the crypto implementation, you may not be able to run key-scanning attacks when using hardware devices, but you can quite likely still perform key-operations *using* the hardware device just as the application can (eg. you could sign a certificate revocation request and revoke the the server's certificate, etc). Who you listen to and how the arguments pan out depend very much on your application, architecture, threat-model, political leaning, and astrological charts. However, getting past all that - yes, conventional PC hardware gives you more PKC bang for your buck, but you shouldn't carelessly disregard how your machine will handle the load and how that could affect "other things". Eg. if you run secure and non-secure services, you could find that the performance curve of any non-secure services suffers greatly when the secure services get overloaded. PKC crypto doesn't really need disk, I/O, nor swap, so it's hellishly CPU bound. OTOH: if you are offloading the crypto operations to hardware (or any remote machine for that matter), the secure services could still become unresponsive but perhaps with a less dramatic impact on non-secure services. Ie. the secure services will perhaps result in giant queues of incoming connections and/or start rejecting new connection attempts, and you may also have loads of threads/processes sleeping whilst waiting for the crypto services to catch up, but that will allow "other things" to get on with life more easily than if the CPU was busily thrashing away at (too many) RSA calculations. Try running a few looped copies of "openssl speed rsa1024" at the same time on your host machine, you'll probably find that anything else you try to do will *crawl* (eg. switch X desktops). YMWV. Also this reminds me I should tidy my GMP wrapper ENGINE back up and look at committing it - even on the OpenSSL's mostly commonly used platform (x86) together with the overheads of conversion between GMP and OpenSSL bignum formats, the GMP wrapper ENGINE resulted in significant speed ups in RSA private key operations. I would suspect that on other chipsets where GMP has been actively working the speed up would be more significant still (I had reports of 3x speed ups on some PPC system or other, though I can't confirm/deny this myself). Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.openssl.org/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
