## 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 … )

## Pixel C Keyboard Pairing Problem – Solved.

I own a Google Pixel C Tablet, which I did order with its recommended, accompanying Bluetooth Keyboard. I’ve been using it with a lot of fun for months now. But yesterday evening, the problem finally happened to me, which I had been contemplating, which was, that I had spent such a long series of hours using them, into the night, that the keyboard actually went dead. I mean, the batteries of the KB could not live as long as my session would have, and pressing keyboard keys eventually had no more effect on the tablet, as the pressed keystrokes were no longer being received. So what I did was to close the tablet over the keyboard in the recommended way, to plug the two in to have them charge, and to leave them that way overnight.

Next morning, I wanted to find that not only the tablet charge was back at 100%, but that I could just step in and start using the keyboard again. But what I found, was that the tablet – with its battery at 100% – was still unresponsive to the keyboard. So my first conclusion was, that the state of the Bluetooth Pairing, was somehow corrupted on the software-level, between the tablet and the keyboard. So I followed ‘The usual, basic steps, to re-pair the two':

1. Separate the tablet from the keyboard. The on-screen keyboard will become available.
2. On the tablet, go into Settings -> Bluetooth, tell it to Forget all Bluetooth Pairings, and turn Bluetooth Off.
3. Re-Attach the tablet to the keyboard, and watch the tablet ask me to turn Bluetooth On. Do so.
4. Wait for the Tablet to show me the PIN-number, which I am to type into the keyboard, to make them pair.

The next problem was, that Step (4) above wouldn’t happen. So my next thought was, that one of two things could finally be wrong with my keyboard:

• The charging system / KB battery could genuinely be defective (Unlikely, as they are virtually still new, and were working before).
• The logical corruption in the Bluetooth Pairing State, between the tablet and keyboard, could be more-deeply corrupted than I thought, from the broken-off session the previous night, maybe even at the Firmware Level.

So now I proceeded with ‘A more-robust procedure, which amounts to resetting the keyboard, as there does not exist a more-proper, explicit way to reset that keyboard':

1. Separate the tablet from the keyboard.
2. On the tablet, go into Settings -> Bluetooth, and tell it to Forget all Pairings / and turn Bluetooth Off.
3. Soft Boot the tablet.
4. After the orderly reboot has finished, Go To Step (3) in the more-basic procedure above.

And what I found next, was that after I had allowed the tablet to turn Bluetooth back On, it did in fact greet me with the 6-digit PIN-number, and after I typed that into the keyboard, and after I had hit Enter on the KB, the keyboard worked fine again.

Yay!

Now, there exist people who claim, that they tried all the steps above, numerous times without success, but that “Suddenly, the keyboard started working again.” To the best of my understanding, what must really have been happening to those people, is that they did try all the above steps, but ‘Maybe not in the correct sequence?’

Dirk

(Edit : )

Even when there is no malfunction taking place, I never try to reboot my tablet, with the BT Keyboard connected.

My best guess for what goes wrong with this KB, would be that it keeps its local store of information, with its encryption key, as a volatile (RAM) chip, with no backup power-supply. It lacks a non-volatile chip to store that. Hence, when the battery goes fully flat, its encryption key is corrupted, and depending on the extent to which encryption is hardware-based these days, it can also leave a trace in the firmware of the tablet itself, that the tablet was paired with it. Hence the reboot needed.

## Klystron, Kernel Update a Success

The laptop which I name ‘Klystron’, received a Kernel Update on July 7. This brought its kernel version to 4.4.0-30-generic as far as I can tell.

Prior to this update, one of the problems the laptop was still experiencing, was due to its Realtek WiFi chip-set, and the kernel module ‘RTL8723BE’. It had a malfunction in how it was connecting to my WiFi, which should have set in twice again, since July 7, according to earlier observations I had made. This bug had become quite predictable.

But since the latest kernel update, this malfunction has not been taking place anymore.

So I would say, that this kernel update was a huge, welcome success.

A separate question I have not yet answered, was whether its Suspend Behavior has also been corrected. This will be slightly more complicated for me to test, because as the above posting suggests, I had adapted a script, which seems to correct it. If the problem had been resolved in the kernel update, my script would simply not do anything. And the end result would remain, that the problem is not apparent.

In order to see whether the kernel update actually resolved that issue, I would first need to disable my script, and then try a few Suspend Cycles, since this problem was also not taking place with 100% consistency.

I have not yet committed myself to doing that.

Dirk

## Klystron Kernel Update

My Linux laptop named ‘Klystron‘ is still fully subscribed to the “Kanotix” repositories. As the reader may recall, Kanotix is a slightly customized version of Debian Linux, that is KDE-based, and that is maintained by a group of developer-experts who I trust implicitly.

Being subscribed to their specific repositories and configuration details has as one advantage, that periodic kernel updates are fed to me, via package manager.

As I came home from camping yesterday, on July 7, I also rebooted this laptop, and saw that indeed, a kernel update was being offered, which I immediately installed. So that laptop now has kernel version ‘4.4.0-30-generic‘, or so my /boot directory would seem to say.

One problem that I was experiencing with that laptop since before camping, was some subtle WiFi issue which I could no longer pinpoint. I had written, that its ability to use the hardware encryption offered by the (kernel module ‘RTL8723BE’) chip-set seemed to work fine. But there were some other problems with the WiFi.

I would like to be able to report, when and if that issue has been resolved completely. But since Klystron has only been running on kernel version 4.4.0-30-generic for one day, it is still far too soon to call out a victory. I will continue to observe the behavior of that laptop for the next little while, and give further comment on it later. So far its behavior looks good.

Dirk