How to verify the signatures, within GnuPG Certificates, from the command-line.

I found this to be a very specific question, with inadequate documentation elsewhere on the Web, and so I’m writing my own observations on it here. First of all, the reader should know what a certifiicate is, as opposed to just, ‘a public key’. A public key goes together Mathematically with a private key, so that either will decrypt what the other enrcypted, but in such a way that, if the public is made aware of the public key alone, they are unable to derive the private key.

This does not just get used for encryption, but also to sign documents or other electronic assets. In fact, if the RSA algorithm is being used for encryption, it may already be somewhat out-of-date, because many Web sites that have an ‘httpS://’ URL, use TLS by now, instead of SSL, the latter being insecure by today’s knowledge. However, while Diffie-Hellman key exchange is suitable for encryption, creating a shared secret between the server and client, that in turn can be used as a strong, symmetrical key for a connection, the actual verification of Web-sites still uses RSA. But, that’s a bit of an aside comment, because we’re not interested in this posting, in certifying Web-sites with an X.509 certificate. This posting is about ‘GnuPG’, which is an alternative to ‘X.509′.

A certificate is what one obtains, when a public key belonging to one person, together with certain mandatory information, is signed, using the private key of another, so that the public key of the other person can be used to validate that signature. This is important because, if there were only a public and private key, the recipient of a (signed) document would have no way of knowing, whether a public key he’s been given, actually belongs to the correct author. He’d just know, that it’s the public key associated with an arbitrary private key, where the two are supposedly already matched as they should be.

Conversely, if a person wanted to encrypt a document being sent to another, then he’d have no way of knowing, that he’s encrypting it using the correct public key. The person who has the corresponding private key, might not be the intended recipient.

Because of the signature of the public key with another person’s key-pair, that person’s attestation to the fact that it belongs to its rightful owner, can add trust in the public key, for the recipient of a signed document, or the sender of a document to be encrypted, the latter so that only the holder of the correct private key will be able to decrypt it.

So, it can happen to users of GnuPG, that they’ve been using GUIs such as ‘Kleopatra’ or ‘KGPG’, that these GUIs have not displayed any messages, but that they’d like to verify the signatures of their public keys, belonging to other people anyway. And from the command-line, there is a way to do that…

(Updated 5/24/2020, 8h35 … )

Continue reading How to verify the signatures, within GnuPG Certificates, from the command-line.

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

Opus En Ligne

( Last edited on 11/25/2016. )

On the Island Of Montreal, bus and subway fares have been handled for many years via a contact-less smart-card, called our “Opus Card”. Most residents “recharge” their fares at designated commercial establishments, but those so inclined may instead buy a USB-connected reader for this card, which also has contacts, which the privately-used readers use to recharge them.

I am one passenger, who chooses to pay their fares this way at home, by plugging the USB-cable of the card-reader into my remaining Windows 7 computer named ‘Mithral’, and by going to a Web-site, where we can provide payment information.

Until last month, the way in which this system worked was:

  • We install a device-driver for the actual card reader – which is chosen for us by the designated site.
  • We kept our Java installation up-to-date.
  • The site charges our payment method, validated on their side.
  • The Web-site deployed and launched a Java application with each use, that connected to the card reader and wrote changes to the data on the card.

At least in theory it was possible to say, that this system was based on an open standard, that being Java.

But as of this month, the transit authority has switched to a different system. We still need the actual USB driver for the card reader. But now we must also download what they call their ‘SmartCardPlugin’, which is given to us from the site as an .MSI File in the case of Windows users. This plug-in actually forms the bridge, between their Web-application and the recognized card reader.

While this system seems to work quite well, based on my first use today, I would say it represents bad programming aesthetics. Even though the actual software-components were provided by Xerox, this system does not install a PKCS#11 security device, nor anything approaching a CAC card reader, with PKI. Instead, this service is based on an .EXE File, and leaves its hook in our browser, which in the case of Firefox, we can find under Tools -> Options -> Applications.

What this means is that the site will display an Web-object, that needs to be ‘opened’ by a specific application, associated by the Web-browser.

The most positive aspect to how this works seems to be, that indeed, it provides compatibility with Firefox, Chrome, IE etc..

But instead of providing strong security, this method is only as secure as the SSL connection to the site.

It may be interesting to note, that even when this system was based on Java, none of the officials ever promised that it would work under Linux, so I see no loss there.

Some users have complained, in that this system fails to meet their expectations, in one day combining the payment service as a smart-phone, NFC service. I have to concur with this hope. I also find it a bit clumsy right now, to have to plug in my Opus Card into a USB port, and to open a site which asks me for my payment credentials – ‘the old-fashioned way’.

But OTOH, I do not see much of a practical loss, compared with how it used to work. And one reason the officials may be doing it this way, could be a negative prognosis for the future of Java itself.

It just so happens that I prefer proven standards.

Dirk

Continue reading Opus En Ligne