At its core, a digital signature is a cryptographic scheme that enables the verification of the authenticity and integrity of a digital message or document. It involves the use of mathematical algorithms to generate a unique digital fingerprint, or signature, for a specific piece of data. We have discussed the basics of digital signature in our earlier articles. In the case of digital signatures, it should be virtually impossible to forge or falsify a signature, or to generate a second message for which this signature is also valid. This assumes that the private key cannot be calculated from the digital signatures and the public key generated with it.
In the ever-evolving landscape of digital communication and transactions, ensuring the authenticity, integrity, and non-repudiation of digital documents is paramount. Digital signatures play a pivotal role in achieving these objectives by providing a mechanism for verifying the identity of the signer and confirming the integrity of the signed content.
Known Procedures Used to Generate a Digital Signature
By far the best known and most widely used digital signature method is RSA, for which various methods can be used to purge the hash value (padding), such as the PSS standardized in PKCS#1. The security of RSA is based on the difficulty of decomposing large numbers into their prime factors (factorization). This is also the basis for the security of Rabin’s signature process.
---
Many digital signature methods are based on the discrete logarithm in finite fields, such as DSA, the El-Gamal, the Schnorr signature, the Pointcheval star signature, XTR or the Cramer-Shoup signature. The discrete logarithm in elliptic curves is the basis for the security of ECDSA, ECGDSA or Nyberg-Rueppel signatures – these methods belong to the elliptic curve cryptosystems. All methods based on the discrete logarithm (in finite fields or on elliptic curves) are probabilistic and use other public parameters in addition to the key length.
Other digital signature methods are based on linear codes, such as the McEliece-Niederreiter signature, or on grids, such as the Goldreich-Goldwasser-Halevi signature or NTRU. The Merkle signature uses hash trees and is based solely on the security of the hash function used.
Some digital signature methods have certain characteristics, such as non-reputable digital signatures or blind signatures, where the signer does not know what they are signing; others allow the signed message to be recovered from the signature (message recovery), such as the Nyberg-Rueppel signature or RSA using the ISO 9796 padding method.
In principle, any digital signature method can be combined with any hash function, as long as the length of the hash values is suitable for the selected parameters of the signature method. However, international and national standards often define the hash function with the signature procedure (e.g. FIPS-PUB 186-2) or at least provide recommendations (e.g. ANSI X9.62).
Use in Practice
PGP systems
PGP stands for Pretty Good Privacy. PGP itself is not an encryption algorithm, but a software product that combines many, sometimes quite complex, methods for symmetric and asymmetric encryption as well as electronic signatures.
PGP systems make it possible for each communication partner to generate a key pair at any time. Trust in the assignment of keys to a person is to be ensured by a kind of mutual electronic certification. This creates a web of trust based on transitive trust relationships. If a person A trusts a person B and that person B trusts a third person C, this means that person A also trusts person C, without an explicit relationship of trust. The advantage of this method is the low level of requirements for the individual user.
This is also the great weakness of PGP. Keys and authenticity information for the key must be exchanged bi-laterally with each participant in a trustworthy manner. There is no way to withdraw “lost” or known keys from circulation in general.
Common variants of the software originally developed by Phil Zimmermann are PGP (commercial) and GnuPG (GNU GPL). The GNU Privacy Project took care of a graphical frontend based on GnuPG for all common operating systems. Since 2003, the project doesn’t seem to show much activity. The program WinPT (Windows Privacy Tools), which is also based on GnuPG, also offers a graphical user interface under Windows for more convenient operation of digital signatures.
For the mail clients Mozilla Thunderbird, Mozilla Mail and Netscape Mail, there is the convenient plug-in Enigmail, which allows the user to use the encryption and signature functions provided by GnuPG directly in the mail program. The plug-in is open source and licensed under the GNU GPL and the Mozilla Public License. The Bat program can also offer corresponding encryption and signing functions using OpenPGP.
The encryption and signature functions of GnuPG can also be used directly and without a plug-in with the mail and groupware client Novell Evolution, which is mainly used under Linux. Evolution is also open source and is licensed under the GNU GPL. The desktop suite KDE also allows the use of GnuPG in many of the included programs (e.g. Kopete and KMail). For the desktop environment Gnome, which is used in Ubuntu, among other things, there is a frontend for GnuPG called Seahorse.
Certificate-based systems
In certificate-based systems, each user receives a digital certificate that contains information about their identity and public key. Each certificate is certified by an issuing body, which in turn can be certified by higher authorities. The trust system of this PKI is strictly hierarchical. The common root of trust is a so-called root certificate. Certificate-based systems fit well into corporate hierarchies. The disadvantage is the high costs for construction and operation as well as the technical complexity of a public key infrastructure (PKI).
The S/MIME standard is based on digital certificates.
A certificate links data from a cryptographic key (or key pair, consisting of a public key and a secret key) to data from the holder and a certificate authority, as well as other specifications such as version, validity period, intended use, and fingerprint.
In web data exchange, the server transmits its certificate with the public key to the client. The client, in this case the user’s web browser, checks whether it can trust the received certificate. To do this, he looks at the list of certificates that were given to him during the installation or that the user installed himself and tries to verify the signature of the server certificate with one of the certificates integrated in the browser. If the certificate could be verified, it starts an encrypted data transfer. Otherwise, the user is asked via a dialog whether he wants to check and accept the certificate. It is fatal if a certificate that is actually not trustworthy has been declared trustworthy out of carelessness.
Example of Generating Digital Signature
PGP systems
To generate a digital signature using PGP (Pretty Good Privacy) in the command line, ensure that GnuPG (which includes PGP functionality) is installed on your system. You can usually install it using your package manager. For example, on Debian-based systems, you can use:
1 | sudo apt-get install gnupg |
If you haven’t already generated a PGP key pair, you can do so using the gpg command. Run the following command and follow the prompts:
1 | gpg --full-generate-key |
This command will guide you through the process of creating a key pair, including selecting key type, key size, expiration date, and providing a user ID (usually your email address).
Once you have your key pair generated, you can sign a file using your private key. Suppose you have a file named example.txt that you want to sign. Run the following command:
1 | gpg --detach-sign example.txt |
This command will generate a detached signature file named example.txt.sig. The --detach-sign option indicates that the signature should be separate from the original file. To verify the signature using the corresponding public key, you can use the following command:
1 | gpg --verify example.txt.sig example.txt |
If the signature is valid and matches the file, you will see a message indicating that the signature is good.
Certificate-based systems
We have already shown the steps to digitally sign using RSA system in this article.
Diffie-Hellman key exchange is a method used to securely exchange cryptographic keys over a public channel. It is primarily used for key agreement rather than for generating digital signatures. However, Diffie-Hellman can be used in conjunction with other cryptographic algorithms, such as DSA, to create a digital signature scheme. Below, I’ll provide an example of how you can use Diffie-Hellman key exchange with DSA for digital signature generation in the command line:
First, you need to generate Diffie-Hellman parameters. Run the following command:
1 | openssl dhparam -out dhparams.pem 2048 |
This command generates Diffie-Hellman parameters with a 2048-bit prime modulus and saves them to a file named dhparams.pem.
Next, you need to generate a DSA private key. Run the following command:
1 | openssl dsaparam -genkey -out dsaprivate.pem -noout |
This command generates a DSA private key and saves it to a file named dsaprivate.pem.
Now, extract the public key from the private key. Run the following command:
1 | openssl dsa -in dsaprivate.pem -pubout -out dsapublic.pem |
This command extracts the public key from the DSA private key and saves it to a file named dsapublic.pem.
Let’s say you have a file named data.txt that you want to sign. Run the following command:
1 | openssl dgst -sha256 -sign dsaprivate.pem -out signature.bin data.txt |
This command computes the SHA-256 hash of the data.txt file and signs it using the DSA private key, generating a signature file named signature.bin.
To verify the signature, you’ll need the public key corresponding to the DSA private key. Run the following command:
1 | openssl dgst -sha256 -verify dsapublic.pem -signature signature.bin data.txt |
This command verifies the signature against the data.txt file using the DSA public key.
