At my day job, I work a reasonable amount of time with cryptographic and authentication systems. Lately, I've been reading about OpenCL and CUDA. I'm wondering if buying a high end graphics card to do some brute force number crunching would be worthwhile.
Today on Hacker News, there was a link to netmap. Netmap looks like a neat way of getting very high network throughput (like saturating a 10G Ethernet line using only 1.66 GHz of processor) using standard hardware (no special ASICs or FPGAs).
I've also read in the past about TLS / SSL and load balancers. TLS / SSL is what's used to encrypt data going between a server and a client, such as for credit card number or username & password transmission. A traditional load balancer will sit on the network in-line before the cluster of servers that actually serve webpages. As requests come into the load balancer, it distributes the requests to the servers in such a way that no server gets overloaded.
I've also read a tiny amount about load balancers that will decrypt and encrypt TLS / SSL traffic such that the webservers don't have to (encryption on general purpose CPUs is expensive). I'd imagine that, for these load balancers to do TLS / SSL inline, this requires very high network throughput as well as very fast number crunching for encryption systems. Traditionally, I'd expect a load balancer such as this would use special hardware (as normal routers do) in order to obtain very high network throughput. I'd also expect custom FPGA code or ASICs would be used to provide high throughput encryption abilities. In both cases, these are low volume, very specialized systems that will be very expensive to create and sell.
But what if someone could combine both netmap and OpenCL to perform load balancing and TLS / SSL in one box that uses off the shelf hardware?
It probably wouldn't be as capable as the truly high end hardware, but it could probably compete in the mid-range and cost significantly less. As the hardware required would be basically:
A high end server system with some add-in cards would fit the hardware bill. Then you'd just need a nicely setup OS (to support netmap and the ATI drivers) and some software to load balance and run the encryption. This isn't simple but it's less complex than a dedicated custom hardware system.
I think this is a pretty neat idea. Of course, as more processors start to include encryption abilities, the viability of a device like this is reduced. But an advantage of this type of device over built-in encryption abilities in CPUs is that it's easy to update this device, we just write new software and deploy it normally. A CPU can't easily be updated to add additional encryption schemes once it is produced.
Another concern would be that the load balancer would need to store the private key and pass it around to the graphics cards, this could be a security issue, but one that could be mitigated by having separate private keys for normal TLS / SSL traffic and traffic where really sensitive data is transmitted (like credit card numbers). The credit card processing server should probably have an HSM and that would be OK because traffic would be much lower.
Something like this could really accelerate the adoption of HTTPS everywhere in order to prevent FireSheep type attacks.
Today on Hacker News, there was a link to netmap. Netmap looks like a neat way of getting very high network throughput (like saturating a 10G Ethernet line using only 1.66 GHz of processor) using standard hardware (no special ASICs or FPGAs).
I've also read in the past about TLS / SSL and load balancers. TLS / SSL is what's used to encrypt data going between a server and a client, such as for credit card number or username & password transmission. A traditional load balancer will sit on the network in-line before the cluster of servers that actually serve webpages. As requests come into the load balancer, it distributes the requests to the servers in such a way that no server gets overloaded.
I've also read a tiny amount about load balancers that will decrypt and encrypt TLS / SSL traffic such that the webservers don't have to (encryption on general purpose CPUs is expensive). I'd imagine that, for these load balancers to do TLS / SSL inline, this requires very high network throughput as well as very fast number crunching for encryption systems. Traditionally, I'd expect a load balancer such as this would use special hardware (as normal routers do) in order to obtain very high network throughput. I'd also expect custom FPGA code or ASICs would be used to provide high throughput encryption abilities. In both cases, these are low volume, very specialized systems that will be very expensive to create and sell.
But what if someone could combine both netmap and OpenCL to perform load balancing and TLS / SSL in one box that uses off the shelf hardware?
It probably wouldn't be as capable as the truly high end hardware, but it could probably compete in the mid-range and cost significantly less. As the hardware required would be basically:
- A fast processor / motherboard / RAM combo
- A large number of PCIe 2.0 slots with a large number of lanes each
- At least 2 10Gb Ethernet PCIe cards
- A few high end ATI graphics cards to execute OpenCL code
A high end server system with some add-in cards would fit the hardware bill. Then you'd just need a nicely setup OS (to support netmap and the ATI drivers) and some software to load balance and run the encryption. This isn't simple but it's less complex than a dedicated custom hardware system.
I think this is a pretty neat idea. Of course, as more processors start to include encryption abilities, the viability of a device like this is reduced. But an advantage of this type of device over built-in encryption abilities in CPUs is that it's easy to update this device, we just write new software and deploy it normally. A CPU can't easily be updated to add additional encryption schemes once it is produced.
Another concern would be that the load balancer would need to store the private key and pass it around to the graphics cards, this could be a security issue, but one that could be mitigated by having separate private keys for normal TLS / SSL traffic and traffic where really sensitive data is transmitted (like credit card numbers). The credit card processing server should probably have an HSM and that would be OK because traffic would be much lower.
Something like this could really accelerate the adoption of HTTPS everywhere in order to prevent FireSheep type attacks.