Andrew Purtell, thanks for your nice comments, you gave good ideas.
Java's GSSAPI uses JCE ciphers for crypto support. Would it be possible to simply swap in an accelerated provider like Diceros?
Right. We also try to make improvement for RPCs which don't use kerberos for authentication and data protection, maybe use delegation token and so on. About simply swapping in an accelerated provider, I'm still considering the detail, I'm intended to to resolve them together.
On the other hand, whether to wrap payloads using the SASL client or server or not is an application decision. One could wrap the initial payloads with whatever encryption was negotiated during connection initiation until completing additional key exchange and negotiation steps, then switch to an alternate means of applying a symmetric cipher to RPC payloads.
Right, I agree, it's a good idea.
This is a similar issue we had/have with HBase write ahead log encryption, because we need to encrypt on a per-entry boundary for avoiding data loss during recovery, and each entry is small. You might think that small payloads mean we won't be able to increase throughput with accelerated crypto, and you would be right, but the accelerated crypto still reduces on CPU time substantially, with proportional reduction in latency introduced by cryptographic operations. I think for both the HBase WAL and Hadoop RPC, latency is a critical consideration.
You have a point. I will also setup benchmark for this.