Also I expect that if someone wanted to port SSL code to a GPU then performance would be pretty good. The FPGA devices in high-end SGI machines should also do well. Of course that would take a moderate amount of work, with hardware being cheap nowadays it’s often more cost effective to just buy bigger machines.

But if you want to rent some servers in a hosting center, or run some virtual machines on EC2, Linode, Slicehost, etc then you get none of that. It’s the AMD64 ISA and nothing else.

hm?

The other way arround. There are way better plattforms for crypto out there.
eg. sparc T2, tile64[0], mips octeon. …
Not to forget the big ppc and itanium systems.

only recently the x86 plattform became initial support for usable crypto (in terms of performance) with intels nehalem plattform which has hardware aes support[1].

[0]: http://www.tilera.com/pdf/ProductBrief_TILEPro64_Web_v2.pdf
[1]: http://softwarecommunity.intel.com/isn/downloads/intelavx/AES-Instructions-Set_WP.pdf

E.g. http://www.boost.org/doc/libs/1_39_0/boost/interprocess/detail/atomic.hpp

glandium: What do we have to do on i386 and AMD64 to enable such atomic operations? I doubt that anyone will be doing new deployments of intensive multi-threaded SSL programs on any other architecture nowadays.

imajica: The fact that there is a check for NULL suggests that it is possible.

I agree that we need to allow support for other algorithms, but I’m sure you agree that we can support them without making our code non-thread-safe! I resisted the obvious temptation to suggest that defaults be hard-coded – about half the bugs I reported could have been resolved by writing static configuration with no option to change certain parameters.

If you want to meet up some time then suggest a time and a place. You know roughly where I live so I’m sure you can find a bar or restaurant that is convenient for both of us.

#ifdef RSA_NULL
default_RSA_meth=RSA_null_method();
#else
#if 0 /* was: #ifdef RSAref */
default_RSA_meth=RSA_PKCS1_RSAref();
#else
default_RSA_meth=RSA_PKCS1_SSLeay();

My point is there are other exchange modes we want openssl to support … history shows us that locking out options is what gets projects into trouble.
I also feel the need to say the this;
Crypto hackers MUST NOT *MUST NOT* allow the “just make it work mentality” to survive. Further, we must allow and encourage support for the adoption of new PKI within existing systems … I know everyone loves RSA I know this point of view makes me unpopular, so let me just say that public RSA itself is technology from 1978 (created off work that was at best initiated in 1973) the updates to the algorithm have been largely based on “boundary limit” raising … the warning is that D/H work shows us that with this kind of hashing the larger the boundary of the data set the higher the probability of collision. These are very real problems now, and while yes there is a lot of work being done to create better exchange systems we desperately need as many options on the table as we can comfortably and rationally support. In this case I think our debian comrades have a larger decision to address. To move away from a “just make it practical” approach (which works very well in other software) to a “trust the design goals of the upstream providers” in regards to complex crypto wrappers.

Let’s discuss it over a jar or two soon.

ALC