Example Python code, that saves text to the Linux clipboard, persistently.

There are some quirks as to how the Linux X-server clipboard works, which have been observed for some time, but which will also affect how to write a Python script / program, that saves some text to the clipboard, but with the intention that the script should exit immediately, while the copied text should remain on the clipboard.

What works against that, is the way the X11 clipboard works generally, which is, that there is no part of the actual O/S, which stores the clipboard contents. Instead, the application being copied from stores this data, and the data is not transferred until another application, or the same application, pastes it again. This has as consequence, that if the first application tries to store the data to the clipboard but then exits, and if the second application next tries to paste it, the clipboard, by first approximation, will be empty because the first application, which was holding the data, has quit.

There may exist some Linux environments in which the desktop manager takes over in a case like that, to hold a copy of the data that was Copied, but my Debian / Stretch, Plasma 5.8 computer, which I name ‘Phosphene’, fails to do so. And this is also how or why, the Plasma 5 clipboard utility, which is named ‘Klipper’, will sometimes still show that last item at the top of its clipboard history, but why that item cannot be pasted (using <Ctrl>+V), until an earlier item is selected within Klipper, and then the item of interest is selected again, so that this most-recently copied item will actually be available on the clipboard again.

In principle, ‘Klipper’ has a setting which states ‘Assure clipboard never empty’. But, long story short, that setting does not work

(Update 4/09/2019, 6h05 : )

Actually, I have learned an intricacy, of how the Plasma 5, Klipper app interacts with the X11 clipboard, and which I was not aware of before. Apparently, the actual clipboard has 3 ‘slots’: ‘Primary’, ‘Secondary’, and ‘Clipboard’. Mouse-Highlighting will cause ‘Primary’ to point to the selected text, while <Ctrl>+C Copying will cause ‘Clipboard’ to point to the selected text. After that, middle-clicking with the mouse will Paste from ‘Primary’, while <Ctrl>+V will Paste from ‘Clipboard’.

When using <Ctrl>+C, an ideally Linux-compliant application will actually leave with both clipboard targets pointing at the selection, while certain applications such as Firefox will only end up with ‘Clipboard’ pointing at the selected text.

The only real pitfall in understanding ‘Klipper’ was, the fact that while it does keep a copy of the clipboard’s contents ‘on the side’, regardless of how they were Copied, Pasting that copy directly after the application Copied from has closed, is only facilitated for middle-clicking with the mouse, not for the <Ctrl>+V -type Pasting.

However, left-clicking on one of the entries in the Klipper History will cause the ‘Clipboard’ X11 pointer to point to it, unless that just happens to be the most-recent entry.

Basically, the user community wanted an alternative to Windows, that has familiar features, and instead, the Linux developers left them a well-hidden Easter Egg. (:1)


 

I recently needed to install a Python script, which hashes a domain-name, password combination, and which has as feature the ability to save the hash-code ‘to the clipboard’, instead of just printing it out, so that the user should next be able to paste the hash-code, and in some cases do so, without the hash-code ever being displayed. This script failed to work in its original version and I needed to modify it, to get it to work the way I wanted it to work.

(Updated 4/09/2019, 15h40 … )

Continue reading Example Python code, that saves text to the Linux clipboard, persistently.

What I’ve learned about RSA Encryption and Large Prime Numbers – How To Generate

One of the ways in which I function, is to write down thoughts in this blog, that may seem clear to me at first, but which, once written down, require further thought and refinement.

I’ve written numerous times about Public Key Cryptography, in which the task needs to be solved, to generate 1024-bit prime numbers – or maybe even, larger prime numbers – And I had not paid much attention to the question, of how exactly to do that efficiently. Well only yesterday, I read a posting of another blogger, that inspired me. This blogger explained in common-sense language, that a probabilistic method exists to verify whether a large number is prime, that method being called “The Miller-Rabin Test”. And the blogger in question was named Antoine Prudhomme.

This blogger left out an important part in his exercise, in which he suggested some working Python code, but that would be needed if actual production grade-code was to generate large prime numbers for practical cryptography. He left out the eventual need, to perform more than just one type of test, because this blogger’s main goal was to explain the one method of testing, that was his posting subject.

I decided to modify his code, and to add a simple Fermat Test, simply because (in general,) to have two different probabilistic tests, reduces the chances of false success-stories, even further than Miller-Rabin would reduce those chances by itself. But Mr. Prudhomme already mentioned that the Fermat Test exists, which is much simpler than the Miller-Rabin Test. And, I added the step of just using a Seive, with the known prime numbers up to 65535, which is known not to be prime itself. The combined effect of added tests, which my code performs prior to applying Miller-Rabin, will also speed the execution of code, because I am applying the fastest tests first, to reduce the total number of times that the slower test needs to be applied, in case the candidate-number could in fact be prime, as not having been eliminated by the earlier, simpler tests. Further, I tested my code thoroughly last night, to make sure I’ve uploaded code that works.

Here is my initial, academic code:

http://dirkmittler.homeip.net/text/Generate_Prime_3.py

 

(Corrected 10/03/2018, 23h20 … )

(Updated 10/08/2018, 9h25 … )

Continue reading What I’ve learned about RSA Encryption and Large Prime Numbers – How To Generate

I just installed Sage (Math) under Debian / Stretch.

One of the mundane limitations which I’ve faced in past years, when installing Computer Algebra Systems etc., under Linux, that were supposed to be open-source, was that the only game in town – almost – was either ‘Maxima’ or ‘wxMaxima’, the latter of which is a fancy GUI, as well as a document exporter, for the former.

Well one fact which the rest of the computing world has known about for some time, but which I am newly finding for myself, is that software exists called ‘SageMath‘. Under Debian / Stretch, this is ‘straightforward’ to install, just by installing the meta-package from the standard repositories, named ‘sagemath’. If the reader also wants to install this, then I recommend also installing ‘sagemath-doc-en’ as well as ‘sagetex’ and ‘sagetex-doc’. Doing this will literally pull in hundreds of actual packages, so it should only be done on a strong machine, with a fast Internet connection! But once this has been done, the result will be enjoyable:

screenshot_20180915_201139

I have just clicked around a little bit, in the SageMath Notebook viewer, which is browser-based, and which I’m sure only provides a skeletal front-end to the actual software. But there is a feature which I already like: When the user wishes to Print his or her Worksheet, doing so from the browser just opens a secondary browser-window, from which we may ‘Save Page As…’ , and when we do, we discover that the HTML which gets saved, has its own, internal ‘MathJax‘ server. What this seems to suggest at first glance, is that the equations will display typeset correctly, without depending on an external CDN. Yay!

I look forward to getting more use out of this in the near future.

(Update 09/15/2018, 21h30 : )

Continue reading I just installed Sage (Math) under Debian / Stretch.

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

Continue reading Hybrid Encryption