WyzGuys Tech Talk

By Bob Weiss

If you missed Part 1 of this article, it can be found at last week’s post on May 5

Hybrid Cryptography

When we use two or more cryptographic methods together, it is called Hybrid Cryptography.  Common forms of Hybrid Cryptography included the creation and sharing of Symmetric session keys, through using Asymmetric Encryption.

Not all key exchange methods require using the PKI.  Diffey-Helman, Oakley and other non-PKI key exchange methods exist.  Most Wi-Fi access points use a non-PKI key exchange method to create a shared Symmetric session key.

Session Key Exchange

The sender connecting to the access point generates a symmetric key.  The sender encrypts the session key using the recipients Public Key.  The recipient decrypts the encrypted session key using the recipient’s (their own) Private Key.  Bothe the sender and the recipient have a shared Symmetric key for this session.  At the end of the sessions, both keys are destroyed.  Session keys are good for a single use, and make decrypting session keys fairly pointless.

HTTPS TLS Key Exchange

This is probably the most used cryptographic process, as it is how we connect to any web server or web application that is using HTTPS.  The first step is for the web site to apply and receive a digital certificate.  This certificate of course is the web site’s Private Key

The entire conversation runs between the client’s web browser application, and the server’s web site or web application.  First my browser requests a copy of the Server’s Digital Certificate, or Private Key.  Second the Certificate is verified by the browser with the Certificate Authority that issued the certificate.  Third, the client’s browser generates a 128-bit AES Symmetric session key.  Fourth, the browser encrypts the AES session key with the web server’s Public Key, and sends it to the web server.  Fifth, the web server decrypts the session key using it’s own Private Key.  The web server responds using the session key to encrypt communications.  The browser recognizes the encryption method and replies using the shared session key.

This is called “end-to-end” encryption.  The entire session between the web browser and the web server is encrypted.  At the end, the shared session key is destroyed.

Hashing and Message Integrity

So far we have been discussing sending and receiving secret messages and shared encryption keys.  But as a recipient, how do I know that they message has not ben altered or changed in any way?  This is the cryptographic concept of Integrity.  The principle method for guaranteeing message integrity is called Hashing.

• A hash or message digest is like a fingerprint. It is a unique hexadecimal value that identifies a plaintext.
• Even trivial changes to the plaintext will dramatically change the hash value.
• A hash can guarantee that a file has not been modified (Integrity)
• Hashing is commonly used to protect passwords (Authentication)
• Hashing provides “signature-based” malware detection
• Hashing supports the integrity and authentication functions of encryption

A hashing algorithm has to allow plaintext inputs of any length, provide a short fixed length output.  Hashing needs to be a “one-way” function, which can not be reversed or “decrypted”.  It should never allow the same hash value output from two different plaintext inputs.  This is called a “collision”

Digital Signatures

A digital signature is an encrypted hash that provides proof of origin identity and authentication, which results in non-repudiation.  Digital signatures are legally binding.  Software application, device drivers, files, documents, and emails can be digitally signed.  This process usually uses asymmetric public/private keys and hashing.  Hashing usually creates a unique hexadecimal value.  It should be easy to compare two hash values

The correct way to create and use a digital signature is to first create a hash value from your plaintext document.  Then encrypt the hash value with the Sender’s Private Key.  (This proves source identity and authentication).  Send both the plaintext and the encrypted hash to the recipient.  The recipient uses the Sender’s Public Key to decrypt the hash value.  Then the recipient hashes the plaintext document, and compares the two hash values.  If they are identical, the plaintext document has not been altered This proves message integrity.  The use of the Sender’s Private Key proves Sender’s Identity, Authentication, and provides Non-Repudiation

Let’s say we want the whole shebang:  message secrecy (confidentiality), message integrity (integrity), proof of sender identity, (authentication), and (non-repudiation.)  Here is the process:

Process for the Sender

• Select a plaintext document or message.
• Hash the plaintext document and create a unique hash value, providing message integrity
• To prove the identity of the sender, encrypt hash with sender’s private key. This provides authentication, and non-repudiation.
• Encrypt the encrypted hash and the message with the recipients public key. This provides confidentiality.

Process for the Recipient

• Receive encrypted message from sender
• Using your private key, decrypt the encrypted message and the hash. This allows you to read the message knowing that it was sent confidentially.
• Use the sender’ public key to decrypt the hash value. This proves who sent the message and provides authentication
• Hash the message yourself, and compare hash values. If identical, you can be assured the message was unchanged. This provides message integrity.

There could be more, but this gives you the basics of the encryption topics likely to appear on any of the cybersecurity certification exams.  Hope this was helpful.  Good luck with your exam!