Network Security CS 5490/6490 Fall 2015 Lecture Notes 8/26/2015 Chapter 2: Introduction to Cryptography What is cryptography? It is a process/art of mangling information in such a way so as to make it very hard to decipher but allowing a secret method of unmangling. Should cryptographic algorithms be secret? No, if we want to check whether these are robust against vulnerabilities or not. The more these are used and tested, the more are the chances of pitfalls getting exposed. The longer these are kept secret, the longer it will take to know the vulnerabilities fully and hence longer it will take to test the robustness against various types of attacks. [E.g., 2G GSM security algorithms were easily reverse engineered.] Though there are certain exceptions (Government and military sometimes like to not disclose their cryptographic algorithms). Might make business sense to keep the algorithm secret in some cases. Good cryptographic algorithms: Easy to use by good guy Hard for bad guy to break Who benefits from increasing processing power? Good guys can benefit from increasing processing power as long as the key sizes are increased appropriately. Increasing a bit only increases the work for the good guys by a little bit but doubles the amount of work for the bad guys (for brute force attacks). Comments in the class the good guys could guys could perform more computations for higher security good guys could perform faster crytanalysis Monoalphabetic cipher: replacing an alphabet with another alphabet. Brute force attack with 26! trials
Vulnerable to analysis attacks which letters occur most commonly, etc., newspaper puzzles Very easy to break with chosen plaintext attack Breaking an encryption (what is available to an adversary): Ciphertext only: Trudy has access to some cipher text Known Plaintext : has some <plaintext, ciphertext> pairs these can be used for an offline dictionary attack (most of the time the secret keys are based on passwords so one can try to figure out the password by trying out a dictionary of passwords, for every guess try to see if the encrypted plaintext matches the ciphertext) Chosen plaintext: Trudy is able to get cipher text for a chosen plaintext, i.e. has < chosen plaintext, cipher text> pair or pairs. She uses this to figure out the secret key (e.g., by choosing The quick brown fox jumps over the lazy dog in a telegraph office that encrypts the messages that it sends out using a monoalphabetic cipher). When designing encryption methods and protocols, we must be cognizant of the above Cryptofunctions: Secret key functions: same key used for encryption and decryption Public key functions: 2 different keys used (public key for encryption, private key for decryption) Hash functions/message digests (MD*) Secret Key Encryption 1. Encrypting data 2. Securely storing data o You can store the encrypted data securely and decrypt it when you want with the knowledge of the secret key (do not loose the secret key) 3. Authentication challengeresponse authentication (r A and r B are nonces) Alice Bob r A > < K AB {r A } < r B K AB {r B } > The challenges must not be repeated (at least until the keys are changed). The above protocol is vulnerable to different types of attacks. One such attack is called the reflection attack where Trudy impersonates Alice by starting two connections to Bob. For the first connection she sends r A to Bob as her first message. For the second connection, she sends r B and then uses the response of Bob K AB {r B } in her response over the first connection and hence successfully impersonates Alice. Trudy ignore K AB {r A }. We will look at this attack in more details later.
Public Key Encryption 1. Encrypting data 2. Agreeing upon a shared secret key Encrypting data with public key is orders of magnitude slower than with a secret key and hence generally avoided. Public Key Encryption is used primarily for encrypting a secret key rather than data. It is used to send a key to other party in a secure way. 3. Digital signatures One cannot create a digital signature scheme with secret key functions because at least two parties know the shared secret. In case of digital signatures using private keys, the private key is (expected to be) known only to one party. You cannot achieve nonrepudiation using secret keys. This must be achieved through public/private keys. 4. Authentication Alice will send a nonce encrypted with Bob s public key key, Bob will decrypt it using his private key and send it back to Alice. Alice Bob K B +{r A } > < r A < K A +{r B } r B >
Alice can have Bob decrypt any message that was in the past encrypted using Bob s public key that Alice had recorded. In the above diagram such a message is represented by r A. Hash Functions Characteristics: Always produces same length output (whatever be the input length) it should be computationally infeasible to find 2 messages M1 and M2 such that H(M1) = H(M2) It should be computationally infeasible to find M, given H(M) Manytoone, multiple inputs maps to a single output Integrity protection: Alice sends {M,H(M)} over the network, Bob computes H(M) from M and checks if its same as received H(M) from Alice. Problem: Person in the middle > Trudy replaces M,H(M)with his own message M and hash H(M ). o Better to send M, H(M, S) where S is the shared secret between A and B, or o sign H(m) with Alice s private key and send M and the signed hash. Data integrity: Store hash of data D and store it along with it. Every time data is accessed, find hash of data D and compare it with stored H(D). Problem: Trudy may change the program to always produce the right hash and hence fool Alice into believing that data is always right (or never tempered with). Chapter 3: Secret Key Cryptography We will first learn about block encryption. Two key questions what is the right key size? What is the right block size? Key size cannot be too small. Small keys could be bruteforced. The Perlman book suggests that 64bit security is pretty good. So a 64bit key must be strong enough against brute force attacks (requires the adversary to try 2^64 keys in the worst case). Block size a small block size (say k bits) allows an adversary to create and effectively search through a table of <plain text, cipher text> pairs. Here the cipher text output for a plain text input is obtained through random substitution that corresponds to tossing a coin k times with a head outcome represented by a 1 and a tail outcome represented by a 0. A block size of 64 bits would be good because it will be computationally infeasible for an adversary to create and maintain a <plain text, cipher text> table with 2^64 entries. The goal is to obtain an output that appears to be uncorrelated to the input. Any change in any bit location in the input should not just appear in specific locations of the output. The change in the input should be reflected on all bits of the output. A block size of 64 bits and a substitution table created for all possible 64 bit inputs by tossing coins will be perfect in terms of meeting this goal. However, this huge table is also the shared key. This cannot be efficiently or realistically exchanged between two parties.
Substitution memory requirement: for each of the 2 k inputs, there is a kbit output obtained by tossing a coin ktimes. Total entries are 2 k, and size of the table = k.2 k On the other hand, a permutation can be very effectively represented and can be agreed upon between two parties. The problem is that, a permutation is not very secure. One can figure it out by seeing which bits of the output change as a result of changes in the specific input bit patterns. Permutation memory requirement: each input bit is placed at specific location in output. Input= kbits, permutation mapping memory = k.log 2 k bits. Some mix of substitutions and permutations perhaps could help?