Lecture 4

Message Authentication Code (MAC)

A short piece of information used to authenticity in order to confirm that the message came from the stated sender, to ensure that its authenticity had not been changed. The MAC value protects a message's data integrity, as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.

When learning about network security, some common names, originating from the original paper on RSA are used. These include Alice and Bob, the original two characters who are trying to have a secret conversation. A couple of characters I liked that they added were Trudy and Eve. They don't want their friend Eve to be able to eavesdrop, and they don't want Trudy to be able to read the message when she intrudes on their private inbox.

It's important not to conflate encryption with authentication. They're two separate things. We use encryption to hide the content of a message in transit. We use authentication to verify the integrity of messages we receive.

Full Domain Hash (FDH)

A signature scheme based on RSA that follows the hash-and-sign paradigm. It is provably secure. FDH involves hashing a message using a function whose image size equals the size of the RSA modulus, and then raising the result to the secret of the RSA exponent.

We don't sign the message, we sign the computed hash of the message derived by the hash function. Secure Hash Algorithms are what are used for this purpose.

Pretty Good Privacy (PGP) was pretty much a singlehanded undertaking of Phil Zimmermann.

There are four main goals in cryptography:

1. Confidentiality: a service used to keep the content of information from everyone except those authorized to have it. Secrecy is a term synonymous with confidentiality and privacy.There are numerous approaches to providing confidentiality, ranging from physicalprotection to mathematical algorithms which render data unintelligible.

2. Data integrity: a service which addresses the unauthorized alteration of data. To assure data integrity, one must have the ability to detect data manipulation by unau-thorized parties. Data manipulation includes such things as insertion, deletion, and substitution.

3. Authentication: a service related to identification. This function applies to both entities and information itself. Two parties entering into a communication should identify each other. Information delivered over a channel should be authenticated as to origin, date of origin, data content, time sent, etc. For these reasons this aspect of cryptography is usually subdivided into two major classes: entity authentication and data origin authentication. Data origin authentication implicitly provides data integrity (for if a message is modified, the source has changed).

4. Non-repudiation: a service which prevents an entity from denying previous commitments or actions. When disputes arise due to an entity denying that certain actions were taken, a means to resolve the situation is necessary. For example, one entity may authorize the purchase of property by another entity and later deny such authorization was granted. A procedure involving a trusted third party is needed to resolvethe dispute.

Notation:

• m: the message

• c: the cyphertext

• E(): encryption function

• D(): decryption function

• H(m): hash function, generates the fingerprint / checksum / digest of a message. All three of those words mean the same thing, but are used interchangeably.

• pk_X: public key "X"

• sk_X: secret key "X"

• K_s: symmetric key

• S(): signature function

• σ: signature σ := S(sk_i,H(m))

In practice, although messages can be encrypted with public-key cryptography, the process is orders of magnitude more computationally expensive than symmetric-key cryptography. For this reason, private keys are usually just used to create digital signatures, (a functionality that symmetric keys are unable to replicate), and to encrypt the symmetric key used for the remainder of the transaction.

When Alice uses public-key encryption to send a message to Bob, he will perform the following procedure to authenticate the sender and verify the integrity of the message.

1. Alice generates a new symmetric key K_s
2. Alice encrypts K_s with Bob's public key pk_B
3. Alice computes the hash H(m) of the message "m", and creates a signature "σ" by encrypting the hash of message "m" using her secret key sk_A
4. Alice sends these two items to Bob
5. Using his secret key (sk_B), Bob will decrypt the symmetric key K_s that Alice encrypted using Bob's public key pk_B.
6. Bob will then use the symmatric key K_s to decrypt the signature "σ", and the original message "m"
7. Bob will then compute the hash of message "m" using the same hash function used by Alice when she created her signature.
8. Bob will then verify Alice's signature "σ". To do this, he will decrypt the signature "σ" using Alice's public key pk_A, compare it with the hash of the message "m", and verify that the two values are equal.

SSL vs. TLS

When SSL was originally created, there were still some security problems. When they were discovered in RFC 5746, new versions of SSL were created, and the scope of SSL expanded. In 1996, SSL v3.0 was released, and was replaced by TLS 1.0 in RFC2246 in 1999, which was itself replaced by TLS 1.2, published in 2008 was the version recommended by RFC 7568, the document that deprecates SSL v3.0 and prohibits any version of TLS from falling back to it. TLS 1.0 was deprecated in 1999, and TLS 1.1 was deprecated in 2006, so ideally TLS 1.2 would not fall back to any of those.

TLS 1.3 was published in 2018 by RFC 8446, making TLS 1.2 obsolete, but not deprecated (yet).

Although by 2008, SSLv3 was deprecated, (with RFC 7568 using the phrase MUST NOT rather deliberately), a separate publication, RFC 6176 prohibits the usage of SSLv2 as well.

Despite this migration from SSL to TLS, all security professionals seem to discourage the widespread usage of the term "TLS" with audiences outside of security/engineering, likely because some people already recognize the term SSL, and the differences aren't worth confusing people over.

SSL/TLS Concepts

A TLS connection is a transient, peer-to-peer communications link that is associated with one TLS session.

A TLS session is an association between a client and a server. In order to avoid multiple handshakes between the same two parties (awkward), a single TLS session may be shared among one or more TLS connections.

There are two steps to a SSL/TLS connection, the handshake protocol and the record-layer protocol.

1. The handshake protocol:

   • The handshake protocol is where the users authenticate one another, figure out which algorithms to use for encryption and MACs, and which cryptographic keys to use for future communciations.

2. The record-layer protocol:

   • The record-layer protocol is the part where secure communication begins, using the shared key established during the handshake protocol.

Some terminology included below

Nonce

In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. They can also be useful as initialisation vectors and in cryptographic hash functions.

• KDF: key derivation function

• G: pseudorandom number

• N_c, nonces

• N_b, nonces

For a thorough look at SSL/TLS, HTTPS, and SSH, including the protocols used for each, the parameters, diagrams, definitions, and everything else you could dream of knowing, read chapter 17 of Cryptography and Network Security]