HQSL in Practice

Public key cryptography, to put it very simply, rests on the fact that certain mathematical operations, while theoretically reversible, take far more effort to do backwards than forwards. This manifests in paired cryptographic keys – public and private, where only the private key is meant to be kept secret.

What is encrypted using a public key can only be decrypted with the corresponding private key. A similar procedure, signing, does the opposite – what is signed with the private key can be verified with the corresponding public key, but none other.

This is the basic mechanism underneath just about every encrypted connection you use daily – while other encryption methods are typically used to encrypt the data itself, public key cryptography is critical for safely exchanging encryption keys.

When you’re using Hamlog.Online as your online QSL database, and are logging on using secure WWPass authentication, a public/private key pair will be automatically created for you. The entire process happens within your browser, and while Hamlog.Online stores your private key in its database, it is encrypted using another encryption key, which is only available through your WWPass authentication. Nobody else can use it. WWPass effectively acts as a personal key to a bank vault, where your private seal is kept.

The public key – the matching imprint of that seal, which individual stampings can be compared to – is then sent to the public key server at HQSL.net, where it is kept for everyone’s reference. Along the way, Hamlog.Online stamps it with knowledge of which call signs it is valid for during which periods in time, derived from data in Hamlog.Online database, which ultimately derives from manual verification of your amateur radio license documents. This information is, in turn, signed with Hamlog.Online’s own private key, and can be verified with the public key published on Hamlog.Online itself.

Anyone can identify which public key was used to sign a particular HQSL card, obtain that public key from the HQSL.net key server, and check the Hamlog.Online certifying signature on it. The system is not locked down to Hamlog.Online, either: Anyone can sign their QSL cards this way, and certify other people’s keys. Which keys a card verifier application trusts to certify other keys, and where does it go looking for keys used to sign a particular card is a matter of configuration.

Signing does not prevent every possible form of fraud. It does two important things, however:

  • It lets you be certain that the content of the QSL card has not been altered in transit or otherwise forged since it was created, even if all you have is a slightly smudged photocopy of the original card. To the extent possible with modern cryptography, you can be certain that what you read is what the owner of a particular secret key actually wrote, whether they made a mistake when doing so or not.
  • It lets you know, with the same level of certainty, that someone (In addition to its own license verification, Hamlog.Online also relies on license verification done by other parties, like QRZ.com) has manually verified the license documents of the card sender, so they were in fact legally entitled to use that call sign at the time given in the QSO record.

Which is more certainty than a paper card alone lets you have.

Reading an HQSL card

In most circumstances, you will never need to read an HQSL directly. You just need a phone with a QR code reader application, which will scan the QR code printed on the card, and direct you to our online HQSL verifier. The verifier will show you a QSL card formatted for reading, along with the signature verification results.

If you want more control over the process, like determining whom to trust to certify public keys, and which servers to request these public keys from, you can run this application locally, install it onto your own web server – any kind will do – or use one of our dedicated phone applications, once these are available.

However, you might want to stay offline entirely, or use the machine-readable data for something, like entering a QSO into your own logs. You can read the HQSL standard specification for exhaustive details, but in brief, an HQSL is an URL, with fields separated by commas, listed in specific order:

https://hqsl.net/h#AC1PZ,FN42gv,W1KOT,202402081323,+00,18.101,FT8,59_05,,UNSIGNED

Let’s go through the components of this record in order:

  1. https://hqsl.net/h# - the header. The primary purpose of this element is to make the HQSL an actual URL, and in theory it can be any URL. The HQSL verifier web application can be deployed anywhere.
  2. AC1PZ - the sender’s call sign, as used on the air.
  3. FN42gv - the sender’s Maidenhead grid.
  4. W1KOT - the recipient’s call sign.
  5. 202402081323 - the date and time of the QSO in an ISO-style format: YYYY, MM, DD, HH, MM, in UTC. In this case, February 8th of 2024, 13:23 UTC.
  6. +00 - signal report. This being an FT8 QSO, it is given the way it is traditionally used on the air in FT8.
  7. 18.101 - frequency in MHz.
  8. FT8 - the communication mode.
  9. 59_05 - extra information not covered by other fields, like a context exchange.
  10. An empty field, reserved for future changes to the standard.
  11. UNSIGNED - the cryptographic signature field. A card without an actual signature will have the word UNSIGNED in it instead. A properly signed card will have a string of characters encoding a binary signature that one can verify using appropriate software. The verifier application will do that automatically when you open the URL.