If the reader is the sort of person who sometimes sends emails to multiple recipients, and who uses the public key of each recipient, thereby actively using encryption, he may be wondering why it’s possible for him to specify more than one encryption key, for the same mass-mailing.

The reason this happens, is a practice called Hybrid Encryption. If the basis for encryption was only RSA, let’s say with a 2048-bit modulus, then one problem which should become apparent immediately, is that not all possible 2048-bit blocks of cleartext can be encrypted, because even if we assume that the highest bit of the modulus was a 1, many less-significant bits would be zeroes, which means that eventually a 2048-bit block will arise, that exceeds the modulus. And at that point, the value that’s mathematically meaningful only within the modulus will get wrapped around. As soon as we try to encode the number (m) in the modulus of (m), what we obtain is (zero), in the modulus of (m).

But we know that strong, symmetrical encryption techniques exist, which may only have 256-bit blocks of data, which have 256-bit keys, and which are at least as strong as a 2048-bit RSA key-pair.

What gets applied in emails is, that the sender generates a 256-bit symmetrical encryption key – which does **not** need to be the highest-quality random-number, BTW – and that only this encryption key is encrypted, using multiple recipients’ public keys, once per recipient, but that the body of the email is only encrypted once, using the symmetrical key. Each recipient can then use his private key, to decrypt the symmetrical key, and can then decrypt the message, using the symmetrical key.

This way, it is also easy to recognize whether the decryption was successful or not, because if the private key used was incorrect, a 2048- or a 2047-bit binary number would result, and the correct decryption is supposed to reveal a 256-bit key, prepended by another 1792 zeroes. I think that if most crypto-software recognizes the correct number of leading zeroes, the software will assume that what it has obtained is a correct symmetrical key, which could also be called a temporary, or per-message key.

Now, the reader might think that this subject is relevant to nothing else, but quite to the contrary. A similar scheme exists in many other contexts, such as SSL and Bluetooth Encryption, by which complex algorithms such as RSA are being used, to generate a temporary, or per-session key, or to generate a per-pairing key, which can then be applied in a consistent way by a Bluetooth Chip, if that’s the kind of Bluetooth Chip that speeds up communication by performing the encryption of the actual stream by itself.

What all this means is that even if hardware-encryption is being used, the actual I/O chip is only applying the per-session or per-pairing key to the data-stream, so that the chip can have logic circuits which only ‘know’ or implement *one* strong, symmetrical encryption algorithm. The way in which this temporary key is generated, could be made complicated to the n-th degree, even using RSA if we like. But then this Math, to generate one temporary or per-pairing key, will still take place on the CPU, and not on the I/O chip.

Now, I suppose that with the Bluetooth Specification, an issue can arise, by which older, obsolete protocols (and therefore, paired devices) use DES encryption as their symmetrical method, while we’d want our Bluetooth Implementation to be compatible with the older, and the newer specifications as well.

This problem can easily be solved, firstly by recognizing that any Bluetooth Chip is still capable of transmitting and receiving data, without applying any encryption to it, exactly as it is being sent and received by the CPU.

Then we’d compare the two encryption methods, to see which one consumes more computational capacity, and we’d discover that by far, AES does. And so what we’d do next, is design the actual I/O chip to hardware-encrypt AES, while leaving it up to the CPU to do any DES encryption.

Some people ask, ‘Is AES-128 secure enough, or should we use AES-256?’ My answer would be that they are both essentially secure, and that *for real-time purposes*, AES-128 might be better.

I’ve found that switching my server to AES-256 slows down some of my clients, but maybe only because these clients still need to do the encryption on the CPU. And if a Web-browser is slowed down too much, there is a risk of socket-timeouts, specifically in the case of Web-sockets and SSL / TLS.

Generally, SSL and TLS are still implemented on the CPU, while some WiFi Chips now offer hardware-encryption, for the connection to a secure WiFi Access-Point.

OTOH, In the case of encrypted emails, the symmetrical encryption is as much of a long-term consideration, as the permanent RSA keys were. Further, if the encryption of an email we’re sending is slow, there is no harm in that. So for such deliberate, durable examples, I’d choose AES-256.

Dirk

## 2 thoughts on “Hybrid Encryption”