Preview question Which of the following would have to be completely - PDF document

Preview question Which of the following would have to be completely abandoned if scalable quantum computers become widely available? CSci 5271 A. one-time pads Introduction to Computer Security Crypto and protocols combined slides B. RSA Stephen McCamant C. AES University of Minnesota, Computer Science & Engineering D. ROT-13 E. SHA-3 Outline General description Public key encryption and signatures Cryptographic protocols, pt. 1 Public-key encryption (generalizes block cipher) Separate encryption key EK (public) and decryption key Announcements intermission DK (secret) Key distribution and PKI Signature scheme (generalizes MAC) SSH Separate signing key SK (secret) and verification key VK (public) SSL/TLS DNSSEC RSA setup RSA encryption Choose ♥ ❂ ♣q , product of two large primes, as modulus Public key is ✭ ♥❀ ❡ ✮ ♥ is public, but ♣ and q are secret Encryption of ▼ is ❈ ❂ ▼ ❡ ✭ mod ♥ ✮ Compute encryption and decryption exponents ❡ Private key is ✭ ♥❀ ❞ ✮ and ❞ such that Decryption of ❈ is ❈ ❞ ❂ ▼ ❡❞ ❂ ▼ ✭ mod ♥ ✮ ▼ ❡❞ ❂ ▼ ✭ mod ♥ ✮ RSA signature RSA and factoring Signing key is ✭ ♥❀ ❞ ✮ We’re not sure factoring is hard (likely not even Signature of ▼ is ❙ ❂ ▼ ❞ ✭ mod ♥ ✮ NP-complete), but it’s been unsolved for a long time Verification key is ✭ ♥❀ ❡ ✮ If factoring is easy (e.g., in P), RSA is insecure Check signature by ❙ ❡ ❂ ▼ ❞❡ ❂ ▼ ✭ mod ♥ ✮ Converse might not be true: RSA might have other Note: symmetry is a nice feature of RSA, not shared problems by other systems

Homomorphism Problems with vanilla RSA Multiply RSA ciphertexts ✮ multiply plaintexts Homomorphism leads to chosen-ciphertext attacks This homomorphism is useful for some interesting If message and ❡ are both small compared to ♥ , can applications compute ▼ ✶❂❡ over the integers Even more powerful: fully homomorphic encryption Many more complex attacks too (e.g., both ✰ and ✂ ) First demonstrated in 2009; still very inefficient Hybrid encryption Padding, try #1 Need to expand message (e.g., AES key) size to Public-key operations are slow match modulus In practice, use them just to set up symmetric PKCS#1 v. 1.5 scheme: prepend 00 01 FF FF .. FF session keys Surprising discovery (Bleichenbacher’98): allows ✰ Only pay RSA costs at setup time adaptive chosen ciphertext attacks on SSL ✲ Breaks at either level are fatal Variants recurred later (c.f. “ROBOT” 2018) Modern “padding” Simpler padding alternative “Key encapsulation mechanism” (KEM) Much more complicated encoding schemes using For common case of public-key crypto used for hashing, random salts, Feistel-like structures, etc. symmetric-key setup Common examples: OAEP for encryption, PSS for Also applies to DH signing Choose RSA message r at random mod ♥ , Progress driven largely by improvement in random symmetric key is ❍ ✭ r ✮ oracle proofs ✲ Hard to retrofit, RSA-KEM insecure if ❡ and r reused with different ♥ Post-quantum cryptography Box and locks revisited One thing quantum computers would be good for is breaking crypto Alice and Bob’s box scheme fails if an intermediary can set up two sets of boxes Square root speedup of general search Man-in-the-middle (or middleperson) attack Countermeasure: double symmetric security level Factoring and discrete log become poly-time Real world analogue: challenges of protocol design DH, RSA, DSA, elliptic curves totally broken and public key distribution Totally new primitives needed (lattices, etc.) Not a problem yet, but getting ready

Outline A couple more security goals Public key encryption and signatures Non-repudiation: principal cannot later deny having Cryptographic protocols, pt. 1 made a commitment Announcements intermission I.e., consider proving fact to a third party Key distribution and PKI Forward secrecy: recovering later information does not reveal past information SSH Motivates using Diffie-Hellman to generate fresh keys for SSL/TLS each session DNSSEC Abstract protocols Protocol notation Outline of what information is communicated in ❆ ✦ ❇ ✿ ◆ ❇ ❀ ❢ ❚ ✵ ❀ ❇❀ ◆ ❇ ❣ ❑ ❇ messages Omit most details of encoding, naming, sizes, choice of ❆ ✦ ❇ : message sent from Alice intended for Bob ciphers, etc. ❇ (after :): Bob’s name Describes honest operation ❢ ✁ ✁ ✁ ❣ ❑ : encryption with key ❑ But must be secure against adversarial participants Seemingly simple, but many subtle problems Example: simple authentication Nonce ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ ◆ is a nonce : a value chosen to make a message E.g., Alice is key fob, Bob is garage door unique Alice proves she possesses the pre-shared key ❑ ❆ Best practice: pseudorandom Without revealing it directly In constrained systems, might be a counter or Using encryption for authenticity and binding, not device-unique serial number secrecy Replay attacks Man-in-the-middle attacks Gender neutral: middleperson attack A nonce is needed to prevent a verbatim replay of a Adversary impersonates Alice to Bob and previous message vice-versa, relays messages Garage door difficulty: remembering previous nonces Powerful position for both eavesdropping and Particularly: lunchtime/roommate/valet scenario modification Or, door chooses the nonce: challenge-response authentication No easy fix if Alice and Bob aren’t already related

Chess grandmaster problem Anti-pattern: “oracle” Variant or dual of MITM Any way a legitimate protocol service can give a Adversary forwards messages to simulate capability to an adversary capabilities with his own identity Can exist whenever a party decrypts, signs, etc. How to win at correspondence chess “Padding oracle” was an instance of this at the Anderson’s MiG-in-the-middle implementation level Outline Upcoming assignments Public key encryption and signatures Cryptographic protocols, pt. 1 Exercise set 3: Wednesday night Announcements intermission All relevant lecture material now presented Key distribution and PKI Next progress reports: week from Wednesday SSH SSL/TLS DNSSEC Other FYIs Outline Public key encryption and signatures Cryptographic protocols, pt. 1 Midterm solutions now posted Announcements intermission My Monday 11/11 office hours will be 9:45-10:45 Key distribution and PKI instead of 10-11 SSH SSL/TLS DNSSEC Public key authenticity Symmetric key servers Users share keys with server, server distributes Public keys don’t need to be secret, but they must session keys be right Symmetric key-exchange protocols, or channels Wrong key ✦ can’t stop MITM Standard: Kerberos So we still have a pretty hard distribution problem Drawback: central point of trust

Certificates Certificate authorities A name and a public key, signed by someone else “CA” for short: entities who sign certificates ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ Simplest model: one central CA Basic unit of transitive trust Works for a single organization, not the whole world Commonly use a complex standard “X.509” Web of trust CA hierarchies Organize CAs in a tree Pioneered in PGP for email encryption Distributed, but centralized (like DNS) Everyone is potentially a CA: trust people you know Check by follow a path to the root Works best with security-motivated users Best practice: sub CAs are limited in what they Ever attended a key signing party? certify PKI for authorization The revocation problem Enterprise PKI can link up with permissions How can we make certs “go away” when needed? One approach: PKI maps key to name, ACL maps Impossible without being online somehow name to permissions 1. Short expiration times Often better: link key with permissions directly, name 2. Certificate revocation lists is a comment 3. Certificate status checking More like capabilities Outline Short history of SSH Public key encryption and signatures Cryptographic protocols, pt. 1 Started out as freeware by Tatu Yl¨ onen in 1995 Announcements intermission Original version commercialized Key distribution and PKI Fully open-source OpenSSH from OpenBSD SSH Protocol redesigned and standardized for “SSH 2” SSL/TLS DNSSEC