Hybrid Cryptoschemes and Public Key Authentication

Overview

Lesson contents Alessandro Barenghi Hybrid Cryptosystems Digital Certiﬁcates Dipartimento di Elettronica, Informazione e Bioingegneria (DEI) Politecnico di Milano The Web of Trust model alessandro.barenghi - at - polimi.it

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 1 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 2 / 47

Communication security Issues

The trivial solution Does it scale? Alice and Bob want to have a conﬁdential, authenticated Problem 1: To communicate with n people, Alice needs to communication. know/store n separate keys: key storage is an issue Trivial solution: they meet in person, and exchange a secret key k Problem 2: To communicate with someone, Alice needs to meet From the meeting point on, they use a symmetric cipher to encrypt him/her in person once, or have a secure communication channel their communications A A Solution: Alice generates an asymmetric keypair kpub, kpri and makes Conﬁdentiality is achieved, authentication is implicit from the secrecy A B B kpub available, and so does Bob generating kpub, kpri of the symmetric key To communicate with Bob, Alice signs the message with kA , and This was the only solution possible up to 1976, as only symmetric pri encrypts it with kB ciphers were available pub

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 3 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 4 / 47 Eﬃciency issues Cryptographic Hash

Hybrid cryptosystems A non-encrypting cryptographic primitive Asymmetric ciphers are slow (≈ 100kiB/s on a desktop): encryption A hash is a deterministic function from arbitrary length message m, and signature of large messages are unpractical to fixed length output h = H(m) Build a hybrid cryptosystem using multiple cryptographic primitives Practically used to obtain a fixed-length “label” h for a digital object Encryption: Alice generates a random symmetric key k, encrypts the B The same value of h may be the hash of different messages (no such message with it, and encrypts k with kpub B thing as bijective arbitrary size → fixed size compression) Decryption: Bob decrypts k using kpri , and uses it to decrypt the message, after which he may discards k. For a cryptographic hash it should not be practically feasible to: Signature: Alice should sign something smaller than the whole 1 Given h, find a m such that H(m) = h (1st preimage) message, although uniquely bound to it in some way 2 Given a message m, find m0 such that H(m0) = H(m) (2nd preimage) 3 Find two messages m0, m00 such that H(m0) = H(m00) (collision) Solving the efficient signature problem requires a new cryptographic primitive, the cryptographic hash Note that 1st preimage ⇒ 2nd preimage ⇒ collision,

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 5 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 6 / 47

One last(ing) issue Digital certiﬁcates

What are digital certificates? Public key authentication Digital certificates are designed mimicking an actual paper certificate Hybrid cryptoschemes allow efficient, confidential communication for the information we want to authenticate Crucial assumption: Alice and Bob are employing each other’s public Our purpose is to authenticate the binding of a public key to the key to send the messages identity of someone/some company If no measures are taken, it is easy to perform an impersonation The format for standardised digital certificates is defined through a attack on public key cryptosystems formal language through Abstract Syntax Notation One (ASN.1) We need some form of digital certificate of authenticity of public The contents of a digital certificate and their semantic values are keys specified employing ASN.1 in the X.509 Standard by ITU-T We will see solutions to this issue, and the infrastructures built to (International Telecommunication Union) manage their lifecycle (certificate issuing-use-revocation-expiration) The certificate signatures are performed employing signing the output of a cryptographic hash with an asymmetric primitive

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 7 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 8 / 47 Digital certiﬁcates Digital certiﬁcates

Contents The X.509 standard mandates the certificate for the digital signature Format to contain the following information: The digital certificates are commonly exchanged as files Version and Serial Number : Used identify the certificate and specify Most common encoding: Distinguished Encoding Rules (DER, ITU the accepted extensions X.690) specifies a binary encoding format for the certificate Subject: The person, or entity to which the key belongs. DER encoding includes non printable characters, Issuer: The entity that verified the information and issued the certificate. The DER encoded certificate may be encoded in Base64 yielding data Valid-From/Valid-To: The validity period of the certificate. that can be copy-pasted easily (common file extension: PEM) Key-Usage: Purpose of the public key (e.g. encryption, signature Parsing certificates should be done carefully: string fields may contain verification on data, signature verification on certificates...). also non-printable characters (strings stored as length+content) Public Key: The public key to be bound to the subject. Signature Algorithm: The algorithm used to sign the hash of the certificate and the hash algorithm. Signature: The actual signature of the hash of the certificate.

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 9 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 10 / 47

Digital certiﬁcates Digital certiﬁcates

How is it signed? The signature is performed through hashing part of the certificate and signing the digest as per RFC 5280. Certificate inspection The parts of the certificate which must be signed include: Inspecting X.509 certificates manually requires a pretty-printer Version and Serial Number Modern browsers include a summary pretty printer Subject, Issuer and Validity dates The public key to be certified The openssl library client performs prettyprinting if used as: Some of the certificate extensions (e.g. key usage) openssl x509 -inform DER -in -noout -text The signature process takes as input the aforementioned fields, A decoder for DER files can be found at http://lapo.it/asn1js/ Issuer encoded in DER in order, hashes them and signs the hash with kpri RFC 5280 specifies that either OS2IP (a custom sequence of bytewise additions!) or PKCS1 standard hashing must be used In practice, PKCS1 is the most common choice since it mandates the use of a cryptographically strong hash

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 11 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 12 / 47 Digital certiﬁcates Practical key sizes

A brief primer on security margins Possible issues A proper security margin is ensured choosing a large enough keyspace The signature is reliable iff the employed hash is collision-resistant for all the ciphers involved and the signature algorithm is not broken The table obtained from the estimates at www.keylength.com by One of the most common choices for the hash was MD5 both academia and national standard bodies Today, computing a collision for MD5 takes ≈ 10s on this laptop Safe Secret/Private Key length [b] Given a message m1, you can derive a colliding message is in the form m = m ||pad, where pad is a properly chosen 64 B string up to RSA ECDSA DSA AES 2 1 year (key/group) Equiv. Certificates signed with MD5 can be forged taking a valid certificate, 1986 512 111 122/515 60 changing the desired values, and stuffing the pad as the comment 2010 1024 144 144/1024 80 field in the certificate extensions (last part to be fed to MD5) 2030 2048 224 224/2048 112 More of this to come in the lesson on cryptographic hashes 2060 4440 256 256/4440 128 Fores. Future 26268 512 512/26268 256

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 13 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 14 / 47

Digital certiﬁcates PKI Infrastructure

Who signs the certificates? Roles Certification Authority (CA): An entity (typically a firm) which “Someone trusted” signs the certificate, vouching for its authenticity takes care of signing the certificates, and distributes its public key to To provide this trusted entity, three solutions have been proposed: all the users in a trusted manner PKI: Public Key Infrastructure:A centralized, tree structured architecture of entities which sign certificates of their subsiders. The Registration Authority (RA): An entity (again, usually a firm) root authorities are implicitly trusted which takes care of verifying the actual authenticity of a certificate, WoT: Web-of-Trust:A distributed architecture relying on the “small gathering data on the user (physically checking his/her identity and world assumption” where everyone can sign certificates. The trust on certificate hash). Very often, it coincides with the CA the authenticity of a certificate is established depending on the trust on User: Asks the CA to sign his certificate, or employs the CA public the authenticity of its signers keys to verify the authenticity of the certificates for another user.

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 15 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 16 / 47 PKI Actions PKI Actions

Bootstrapping a CA Bootstrapping a CA CA User The CA creates its own keypair and fills in the fields of its certificate We assume, for the sake of clarity, that we are describing a root CA, Only once per CA's certificate i.e. one sitting at the top of the PKI hierarchy Generate public-private key pair The CA self-signs its own certificate, and stores its own private key in a tightly guarded place (at least,hopefully) Generate CA's own certificate The CA takes care to distribute its self-signed public key certificate in a safe manner to the largest possible user-base CA ID signed with Typical ways to do so include: Embedding the certificates in applications, e.g., web browsers Embedding the certificates within operating system distribution chains

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 17 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 18 / 47

PKI Actions PKI Actions

Issuing a Certificate Issuing a Certificate CA User The user willing to get his public key certified starts by generating Generate public-private key pair safely a keypair The certificate signature request CSR is PKCS10 standardised and Check the integrity of the CSR Generate CSR (Certificate Signing Request) Send CSR self-signed by the user UserID signed with

User ID PKCS10 mandates the use of X.509 format to represent the CSR

If the CSR is intact, verify that the user's true identity matches the one in the CSR The CA should verify either via a RA or directly whether the actual User ID user/firm who generated the certificate is the one who claims to be User ID Once the certificate is signed, it can be publicly used and does not Store Signed Certificate Generate user's certificate Dev ID need to be sent over a secure channel to the user

CA ID User ID signed with Send Certiﬁcate CA ID The user can check that the CA signature is authentic

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 19 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 20 / 47 PKI Actions PKI Actions

Issuing a certiﬁcate - CSR Structure (speciﬁed in the X.509 stardard)

Practical CSR creation Version The user has generated a A private key can be created with the following openssl command keypair Subject Name openssl genrsa -out example client.key The user performs the PKCS The CSR creation automatically generates the public key signature as usual Public Key Algorithm openssl req -new -key example client.key -out client.csr The yellow part of the The user will deliver the CSR to the CA in any preferred way CSR is DER encoded User Public Key The yellow part of the The CA will return a complete X.509 certiﬁcate to the user CSR is hashed Attributes If you need to setup a CA, you’ll ﬁnd the Easy-RSA set of scripts The hash of the yellow handy https://github.com/OpenVPN/easy-rsa part is signed with the Signature Algorithm user’s private key and PKCS#1 Sign the signature is stored Signature

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 21 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 22 / 47

PKI Actions PKI Actions

Checking the authenticity of a digital object Checking the authenticity of a digital object Client Server 1 The client receives an object from a server together with a certiﬁcate Sign a digital object to be distributed Check if the CA certiﬁcate is available and check CA ID signed with of the public key to verify the signature

Dev ID 2 CA ID Send object and the certiﬁcate The client checks whether the CA of the certiﬁcate is among the ones CA ID

User2 ID he trusts (i.e. has an authentic public key for it)

CA ID 3 The client checks that the server-supplied certiﬁcate is authentic, i.e. Use the CA's Public key to check the signature veriﬁes the signature made by the CA on the server public key

User2 ID CA ID CA ID 4 If the certiﬁcate is authentic, the client veriﬁes the signature on the

If the certiﬁcate is good, use the user's public object with the public key contained in the certiﬁcate key to verify the object 5 Dev ID If the signature of the object is correct, the object is authentic, if any CA ID single one of the previous step fails it is not

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 23 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 24 / 47 PKI Actions PKI Actions

CRL Method - Format Compromised certificates: how to deal with them Version A keypair can be compromised (e.g. by theft, blackmail) The revoked certificates list is a sequence of A way to invalidate the certificate emitted by a CA is needed to Signature Algorithm prevent signatures on forged objects Revoked certificate Issuer identifier This action, namely the revocation of a certificate can be notified Date of revoking via: Optional extensions CRLs: Certificate Revocation Lists are lists of certificate IDs containing all Time of Update the compromised certificates of the CA, available for download The CRL may optionally OCSP: Online Certificate Status Protocol is an online protocol which allows Revoked Certs List contain the next update date a user to query the CA which has signed a certificate to ascertain its URL where the CRL is Signature Algorithm revocation state. PKCS#1 distributed contained in the Sign CA certificate Signature

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 25 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 26 / 47

PKI Actions PKI Actions

OCSP Method OCSP Method - OCSP Request and Response Formats The size of the CRLs increased, and due to the fact that they may not be updated in realtime when certificates are revoked, the Online The OCSP request is Certificate Status Protocol was developed (RFC 2560). only optionally signed Hash Algorithm ID Version by the requester The OCSP verification of the status of a certificate takes place as an Issuer Name Hash Requestor Name online request-response between the user and the signer CA The hashes are Issuer PubKey Hash Status Request List performed from the The user queries the CA for the status of the certificate, and the CA DER encoding of the Certificate Serial No. answers with a message notifying the current state of the certificate Extensions names PKCS#1 Extensions The information is fresher, at the cost of mantaining a relatively small Signature Algorithm w/ request. RFC2459 mandates the sized database at the CA’s side, which is no longer an issue Public Key Fields are optional Signature inclusion of a nonce in To avoid bandwidth waste and latencies, usually a local cache of the the extensions [X.509 most recent OCSP transactions is mantained by the user v3 only]

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 27 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 28 / 47 PKI Hierarchical structure PKI Hierarchical structure

Hierarchical authenticity verification Hierarchical structure The differences from a flat CA structure are the following ones: Up to now, we have assumed that the CA was the ultimate authority Issuing: Certificates are issued to the users only by the leaf CA for warranting the authenticity of its certificates Revocation: Certificates are revoked by the CA which emitted them Verification: The verification step is performed as follows: As the PKI system was designed to scale up to a large number of 1 User checks if the certificate he wants to authenticate is signed by one users a hierarchy among CA was established of the CAs trusted by him (he has a copy of their cert.s) A CA certificates the public key of the ones one level below it, and 2 Yes (Base case): The authenticity is checked with the public key of the trusted CA. If the certificate is authentic, he goes back to what he has its public key certified by the one which is one level above it was checking before. This effectively builds a tree-based structure where the leaves are the 3 No (Recursion step): User obtains the certificate of the CA which users and the root is represented by the so-called root CAs. signed the certificate currently under exam, and tries to authenticate it. Go to 1. When the user knows the certificate is authentic, he can check the one currently under exam and go back to what it was checking before.

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 29 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 30 / 47

PKI Actions Automating Certiﬁcate management

PKI Hierarchical structure - Common Pitfalls The ACME protocol Root CAs are a single point of failure for the whole infrastructure: Asking for the issuance or revocation of a certificate requires if a Root CA gets its key compromised, all the certificates issued from procedures which have typically a human-in-the-loop offspring CAs become forgeable. This may be effective for highly valuable assets (e.g. bank websites), but slows makes prompt certificate renewal/revocation slower The scheme still needs to distribute the certificates of the Root The ACME Protocola was designed to automate the request, renewal CAs in a safe way and promptly remove Root CA compromised keys and revocation of certificates employing the ability of serving a given Since the chain of trust is indicated in the extensions field of the content over HTTPS as a proof-of-identity certificate, all the extensions should be properly parsed A fully working implementation is Certbot, which uses the Let’s The signature keys employed should match or exceed the advised key encrypt CA to provide 90-days lasting X.509 certificates length by NIST a CAs should work at a equal- or higher- security level than the users Currently, an Internet-Draft https://tools.ietf.org/html/draft-ietf-acme-acme-06

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 31 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 32 / 47 Web Of Trust Web Of Trust

Actors A distributed alternative Users: The only actor of the scheme are users, they : The alternate model to provide authentication for unknown public key Encrypt/sign/verify a digital object (file/mail message) is the Web-of-Trust scheme Acts as a CA signing someone else’s key/id pair In this scheme, invented for private mail communication by Phil Keep a local key/id keyring where all the certificates are kept Choose which users they trust to be acting as a CA Zimmermann, everyone may act as a CA Keyservers: Provide a globally synchronized, trusted archive of An user may pick the one he favours to act as CAs: the key/identity public certificates. bindings signed by them will be deemed authentic Public lookup is provided via either key ID or user ID It is possible to extend the trust to trusted-users-by-trusted users The archive is append only, no practical removal is possible The scheme works on the “small world assumption”: there are ≈ 6 Anyone can run a keyserver, provided he has enough resources. A list of keyservers is available here : degrees of separation among two random person on the planet. http://www.pgpi.org/services/keys/keyservers/ We run one at pgp-srv.deib.polimi.it

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 33 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 34 / 47

Web Of Trust Web Of Trust

Certificate Format Certificate contents and creation The key/identity pairs are not stored in a X.509 compliant certificate, but rather in a format specified by RFC4880 An OpenPGP certificate contains a primary Primary Public key public key and a textual ID The format is a sequence of data blocks (packets) which contain: A one-byte identifier of the content of the packet (identity, public Textual user-ID Upon creation, the owner self-signs it and key, signature, private key, object being signed) appends the signature A one to four bytes value specifying the length of the object (big ID- binding sig Secondary public keys may be included endian byte ordering) (one-key-per-purpose principle) The actual packet content Subkey public key Subkeys are bound to the main key via The format is binary but it is common to encode it in a printable form both a self verifiable signature, and one The encoding chosen is Radix-64, a variant of Base64 encompassing a Subkey binding sig verifiable with the public key mandatory, per line, CRC to allow the end user to check the integrity Signatures from users acting as CAs are of the message (against accidental transmission errors) Primary key bind sig appended to the certificate

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 35 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 36 / 47 Web Of Trust Web Of Trust

Authenticity management A certificate is deemed to be authentic depending on the level of trust Certificate management and differences from classic PKI assigned to the CA-user signed it The typical lifecycle of a certificate in the web of trust model is: Trust levels for a CA-user are stored locally in the so called trust-db The user generates a keypair, and stores it in his own keyring, self signing the public key The default trust levels in the WoT scheme are : The user exports a self-signed certificate to the public keyservers ultimate: It’s the user’s own key trust level. Every key you sign with The user meets other users, and, after checking mutually their an “ultimate” trusted key becomes authentic. identities, they cross-sign their public key certificates complete: One signature by a key with this level of trust makes the The newly signed certificates are uploaded on the public keyservers, key/id pair authentic. which merge them with the old ones marginal: At least 2 keys with marginal trust have to sign a key/id pair to make it authentic. The key/identity verification before a certificate is signed is demanded untrusted: Untrusted key signatures do not contribute to mark a to the users, assuming that they are careful in the process key/id pair as authentic The aforementioned criteria are the default ones for GPG, the actual number of signatures/trust levels can be customized

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 37 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 38 / 47

Web Of Trust Web Of Trust

Certificate Revocation Since anyone can be a CA, the revocations are issued on a per-signature basis Pitfalls and Issues To revoke a signature, a so-called revocation signature is performed Direct verification of the authenticity of a certificate should be and appended to the certificate. Typically : performed in person in order to bootstrap the scheme The owner of the certificate may revoke the self signature on it A CA-user may revoke its signature to the certificate individually: the Prompt revocation of compromised certificates is not easy if a user other signatures will still be valid does not update regularly the keys in his keyring For the revocation to be public, the updated certificate should be The certificates are identified by a unique ID: the original choice for uploaded on the keyservers (and downloaded by the clients) the ID length was insufficient (32 b), thus it is possible to have collisions on certificate IDs (this has been solved with longer IDs) The OpenPGP specifications suggest that a revoked signature should carry almost the same weight of a revoked certificate Issue: what if I sign and then revoke the signature on someone else’s certificate to discredit him?

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 39 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 40 / 47 A practical demonstration The PGP/GPG Encrypted Mail Protocol

Message preparation The PGP/GPG Encrypted Mail Protocol PGP/GPG messages encrypted and signed with an hybrid symmetric+asymmetric scheme for efficiency Pretty Good Privacy, a.k.a. PGP was designed back in 1995 by Phil The signature and encryption actions are disjoint and the user may Zimmermann as the first attempt to provide strong crypto to anyone select whether to perform both of them, or only one Gnu Privacy Guard, a.k.a. GPG was developed by Werner Koch as a The procedure goes as follows: free alternative to PGP, and supports the same features. 1 The message is compressed (zip and bz2 algorithm supported) Possible to encrypt and sign any file, the most typical use is to 2 A random symmetric session key is generated for each recipient encrypt and sign e-mail messages 3 A copy of the message is encrypted for each symmetric key GPG is CLI only, but GUIs are available for all the most common mail 4 Each symmetric key is encrypted with the recipient public key 5 The messages are bundled together and the hash of the bundle is signed clients: Thunderbird→Enigmail, Apple Mail→GPGSuite, Outlook→GPGOl Current implementations support (default in red) Asymm. Ciphers: RSA,ElGamal/DSA Symm. Ciphers: AES,Camellia,3DES,CAST5,Twofish,Blowfish Hashes: SHA-1,SHA-2,RIPEMD-160

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 41 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 42 / 47

The PGP/GPG Encrypted Mail Protocol The PGP/GPG Encrypted Mail Protocol

E-mail Message preparation Small practical manual PGP/GPG messages are expressed in the same packet-based format You can generate a key interactively with as the WoT certificates gpg --gen-key Encrypt a file gpg --recipient "John Doe" -e Once the signed message bundle is ready, its encoding is ready to be Add --armor if you need the output to be printable (e.g. mail) embedded in a common e-mail (all characters are 7-bit ASCII) Add -s if you also want to sign the file The first way to embed the message bundle in an e-mail is to enclose Decrypt with , gpg will pick the correct private key a gpg -d between two text marker : the PGP/GPG mail client will match it automatically As this tends to clutter the message, especially in the signature-only Export a key to a keyserver with gpg --send-key --keyserver case, it is possible to employ a application/pgp-encrypted MIME , import with gpg --recv-key section followed by an application/octet-stream one for --keyserver encrypted messages and an application/pgp-signature to delimit List all the certificates in your keyring with , check the signature gpg --list-keys the certificate validity with gpg --check-sigs alooking like -----BEGIN PGP SIGNED MESSAGE-----

G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 43 / 47 G. Pelosi, A. Barenghi (DEI) Hybrid Cryptoschemes and Public Key Authentication 44 / 47