## A Hypothetical form of Broadcast Encryption

I have pursued the mental exercise, of supposing that a group of (n) people might exist, who are to receive a broadcast, encrypted message, but in such a way that two of those recipients’ credentials are required, to decrypt that message. The assumed author of the message is a secure party, entrusted to keep all the encryption details of the system.

The basis of my exercise is, that RSA encryption and hybrid encryption may be used, with the twist, that as long as the modulus is the same for two transactions, a symmetrical key can be encrypted twice, in order to be decrypted twice. A formalized way to write this could be:

C = (T ^ E1) ^ E2 mod (p)(q)

T = (C ^ D2) ^ D1 mod (p)(q)

Where (p) and (q) are random 1024-bit prime numbers, (T) stands for the symmetrical encryption key, and (C) stands for the encrypted form of that key. Clearly, (p) and (q) would be filtered by the central party, such that neither (p-1) nor (q-1) are divisible by either (E1) or (E2), which are, 65537 and 32771 respectively.

My concept continues, that the central party associates a single prime number with each distributed recipient for the long term, and that the recipient is not allowed to know their own prime number. For any pair of recipients, a modulus (p)(q) follows, which the recipients store, for each other recipient, that the current recipient may eventually want to combine his key with.

(Corrected 09/22/2018, 18h00 … )

(As of 09/21/2018, 23h40 : )

## Hybrid Encryption

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.

(Corrected 10/05/2018, 13h45 … )

## Some Notes on the Merits of Hybrid Encryption

In my most recent postings, I sort of took the perspective, that ‘RSA’ is the only form of public key cryptography. But in reality, this is far from true.

As far as the actual public-key methods go, there is also ‘El-Gamal’ and ‘Diffie-Hellman’ in public use, as well as ‘DSA’. The last of those is only useful for signing, not for encrypting. But what that means in practice, requires that people understand another concept in public-key cryptography, which is called ‘hybrid encryption’, which marries one of the public key exchanges with strong, symmetrical encryption. Symmetrical encryption is any scheme where the same key can be used to decrypt, which was used to encrypt. Symmetrical methods in use include ‘AES’ and ‘Blowfish’, and several others.

A concept which exists purely with RSA, is that a sender of a message can use the public key of the recipient to encrypt, so that only the recipient will be able to decrypt, using his own private key.

Well, if we consider SSL-secured Web-sites, we do not see that our Web-browser needs to build any public and private key-pairs. And so according to that, it might be imaginable that the server has a public key to receive data with securely, but it is not obvious how the browser receives data securely from the server. And what actually happens with SSL, is that a pseudo-random key is built essentially by the client, and is then sent to the server securely via RSA. That key is then used by both peers, to send and receive the actual user data via strong, symmetrical encryption. And this idea, of only using public key-exchange to encrypt a strong, symmetrical key once per session, is referred to as hybrid encryption.

This also makes sense from the standpoint, that a single public-key, RSA encryption requires much more CPU time, than the repeated use of AES aor Blowfish.

TLS key exchange is based on methods, that more closely resemble Diffie-Hellman than RSA, but again forms a basis of hybrid encryption.

And this is also why SSH, which is also known as ‘Secure Shell Protocol’, only requires that the client have a DSA key. Given that an SSH client uses his public key to authenticate himself, in theory an SSH server can be set to allow RSA authentication, but then all the client must do is to encrypt a piece of data which he cannot control, using his private key, to prove to the server that he is in fact the owner of a stated public key.

Hence, for SSH authentication, DSA works just as well for the client to use.

Dirk