3

if you were to recommend a cipher/mode configuration that emphasizes performance for your customers, would you recommend a hardware based accelerated solution over one that isn't? For big data at rest/transit what are some good cipher/mode choices that work well with hardware accelerators?

In particular, I am thinking of the context of loading hadoop clusters in the cloud from on premise. Assuming it's not a managed VPN, would it make more sense to go with ChaCha/Poly or hardware accelerated AES? My thoughts are that the developer loading the cloud will likely have a beefy machine so it should have pretty modern CPUs - therefore I'm thinking of using TLS AES-GCM (I am trying to avoid rolling my own transit security protocol, but this may be necessary).

As this is Big Data, this becomes a significant performance issue when you're talking TB worth of data.

For big data at rest in the cluster, I am thinking definitely hardware accelerated AES, though not sure about the mode of operation. My understanding is that GCM has opcodes in modern CPUs, however, because of the TLS support so that might be a good performant choice.

(Btw, I understand that supporting all modern secure suites is a good idea, but I am looking for strong default configs on both client/server).

Raoul722
  • 2,836
  • 2
  • 20
  • 39
Blaze
  • 551
  • 4
  • 13
  • a) Can you deploy arbitrary specialized hardware (rack mounted, PCIe, ..)? b) Do you trust / are you allowed to trust non certified hardware / software with the processing of secret data? C) Is money an issue? – SEJPM Apr 25 '16 at 14:01
  • a) Yes as long as it isn't too oddball and is a commonly known best practice, b) no, probably not, c) not really – Blaze Apr 25 '16 at 14:04
  • If you trust the software the answer to your problem becomes AES (GCM?) + as many server CPUs as needed. If you can not trust the software, you need to get hardware you trust (because of certifications?) and let it do the job. These are called HSMs and chances are you'll get them as PCI cards or network connected rack mounted modules and chances are high they'll only support AES (with whatever mode) unless you throw lots of money and time at the vendor. – SEJPM Apr 25 '16 at 14:10
  • 1
    @SEJPM HSM's are usually focussed on high security applications. They are used by banks and CA's to keep their keys secure. When talking about TLS (as seems to be the case) they it's probably better to refer to the hardware as SSL accelerators. Note that there are certainly also TLS accelerators that turn a TLS connection into a TCP stream (contrary to what the Wikipedia page mentions). – Maarten Bodewes Apr 25 '16 at 18:19
  • AES-GCM is faster than ChaCha20-Poly1305 IFF all parties have hardware support. Otherwise it is both very slow and subject to cache-timing attacks. Also, if "certified" means FIPS 140-2 then your only option is probably AES-GCM (but note that you SHOULD NOT require FIPS 140-2 complience unless legally required to do so; it gains nothing and actually makes you less secure). – Demi Apr 25 '16 at 21:22
  • Thanks @Demetri. Mostly I'm assuming that client and server both have modern hardware (loading Hadoop cluste). My assumption at this point is that modern Intel CPUs all have AES hardware acceleration. Is this the right assumption? – Blaze Apr 26 '16 at 00:11
  • @MaartenBodewes Thanks. I looked up HSM and I read that they were really just for things like accelerated RSA. My assumption is that server CPUs are usually good for AES256 acceleration. – Blaze Apr 26 '16 at 00:12
  • The problem I'm faced with is what ciphers customers should support from a client base when loading a cloud based hadoop cluster. Also, how should the hadoop cluster store data at rest. My feeling right now is that we should not have encryption for data in transit in the cloud based cluster itself. Thoughts? – Blaze Apr 26 '16 at 00:13
  • @Blaze thats how the NSA got google's data, because they werent encrypting the data in transit within the data center – Richie Frame Apr 26 '16 at 00:15
  • @RichieFrame Do you have a cite for that? My understanding is that NSA got it between datacenters. I agree, from a trust boundary point of view, you need to be careful in that respect. – Blaze Apr 26 '16 at 00:43
  • @Blaze To my knowledge all AMD64 CPUs have AES-NI EXCEPT for low-end processors which would not be used in servers. But don't quote me on that.

    With regards to intra-data-center traffic, my guess is that it should still be encrypted. Hardware-accelerated AES-GCM is around 24Gb/s (3GB/s) and is faster than almost any storage or network.

     – Demi Apr 26 '16 at 02:19
  • @Demetri Nahelem processors like the W5590 do not have AES-NI – Richie Frame Apr 26 '16 at 02:21
  • @Blaze Also, DO NOT try to roll your own crypto. Use a well-regarded, high-level library, like BoringSSL. – Demi Apr 26 '16 at 02:22
  • Roughly all high-end (and mid-end) CPUs from 2011 and newer should have AES-NI. Post 2013 (don't know for certain when Atoms got it) many small / weak / cheap AMD64 also got support. As for the actual questions: You need to use HSMs if you need certification, you can use SSL accelerators (see Maarten's comment) for data transit acceleration (-> TLS) and if you don't see the need for the accelerators server and client CPUs will do the job reasonably well and will be much easier to deploy (I guess). – SEJPM Apr 26 '16 at 18:08

0 Answers0