Cryptology complementary. Introduction

Transcription

1 Cryptology complementary ] Introduction Pierre Karpman pierre.karpman@univ-grenoble-alpes.fr Introduction /21

2 First things first Main goals of this course: practical complement to the other half Introduce some constructions (what s a block cipher, a key exchange?...) Introduce some implementation aspects (how do you do finite field arithmetic?...) Introduce some attacks (how do yo compute a discrete logarithm?...) Introduce some real-life usage (e.g. SSH) Introduction /21

3 Organisation Course format: mix of lectures/tds/tps (Probably) A contrôle continu evaluation (lab session/homework, details T.B.D.) A final exam (ditto) Introduction /21

4 What s crypto? Quick answer: it s about protecting secret data from adversaries In a communication (encrypted , text messages; on the web; when paying by credit card) On a device (encrypted hard-drive) During a computation (online voting) Etc. Introduction /21

5 Where does crypto run? Crypto needs on various platforms High-end CPUs (Server/Desktop/Laptop computers,...) Mobile processors (Phones,...) Microcontrollers (Smartcards,...) Dedicated hardware (accelerating coprocessors, cheap chips,...) Introduction /21

6 Techno constraints Varying contexts, varying requirements Speed (throughput) Speed (latency) Code/circuit size Energy/power consumption Protection v. physical attacks Implementation plays a big part in crypto Introduction /21

7 Quick example A protocol (e.g. TLS) uses among others A key exchange algorithm (e.g. Di e-hellman) public-key cryptography instantiated with a secure group (e.g. ANSSI FRP256V1) An authenticated-encryption mode of operation (e.g. GCM) symmetric-key cryptography instantiated with a secure block cipher (e.g. the AES) A digital signature algorithm (e.g. ECDSA) public-key + symmetric-key cryptography instantiated with a secure group and a secure hash function (e.g. SHA-3) Introduction /21

8 Protocols can be complex 552 Fig. 9. Message sequences for the ciphersuites commonly enabled in OpenSSL (abbreviated handshake) ntick =1 ntick =0ServerNewSessionTicket ServerCCS ServerFinished ClientCCS ClientFinished ApplicationData ClientHello ServerHello(v, kx, rid) rid =1 rtick =1 rid =0&rtick =0 rid =0&rtick =0 (full handshake) (full handshake) (full handshake) kx = RSA DHE ECDHE RSA EXPORT DHE EXPORT kx = DH DH anon ECDH ECDH anon kx = PSK RSA PSK DHE PSK SRP SRP RSA kx = RSA PSK SRP RSA ServerCertificate kx = DH anon kx= SRP DHE PSK ServerCertificate ServerCertificate ECDH anon (kx = PSK & kx = DHE ECDHE chint = 1) kx = SRP RSA RSA EXPORT DHE EXPORT chint =1 kx = PSK kx = RSA PSK & chint =0 kx = RSA ServerKeyExchange ServerKeyExchange ServerKeyExchange & chint =0 kx = DH ECDH (authenticate client?) (authenticate client?) ServerHelloDone cask =1& cask =1 kx = DH ECDH cask =0 cask =0 CertificateRequest CertificateRequest kx = DH anon ClientKeyExchange ECDH anon ServerHelloDone ServerHelloDone ClientCCS cask =1 cask =1 cask =0 ClientCertificate(co er ) ClientCertificate(co er ) cask =0 ClientFinished co er =1 ntick =1 ClientKeyExchange ClientKeyExchange ServerNewSessionTicket ntick =0 cask =1& cask =1& co er =1 co er =2 co er =1 cask =0 cask =0 ClientCertificateVerify ClientCertificateVerify ServerCCS co er =0 co er =0 ClientCCS ClientCCS ServerFinished ClientFinished ntick =1 ntick =0 ServerNewSessionTicket ClientFinished ntick =1 ntick =0 ServerNewSessionTicket ApplicationData ServerCCS ServerCCS ServerFinished ServerFinished ApplicationData ApplicationData Figure: Part of the TLS state machine, Beurdouche et al., 2015 Introduction /21

9 Doing crypto Designing new primitives/constructions(/protocols) Analysing existing primitives/... Deploying crypto in products Di erent goals, di erent techniques Ad-hoc analysis, discrete mathematics, algorithmics Computational number theory/algebraic geometry Low-level implementation (assembly, hardware) Formal methods Following good practice Introduction /21

10 Scope of an analysis Many types of adversary Passive ( eavesdropper = Eve ) Not passive, i.e. active With or w/o physical access Side channels Fault attacks With varying scenarios ( one-time or long-term secret?) With varying objectives Introduction /21

11 Security objectives? Introduction /21

12 Security objectives? Hard to find the secret (the key) Hard to find the message (confidentiality) Hard to change/forge a message (integrity/authenticity) Etc. Introduction /21

13 Small informal focus Example: indistiguishability (IND-CPA) 1 Submit messages to an oracle O to be encrypted, & get the result 2 Choose, m 0, m 1, send both to O 3 Receive O(m b ) for a random b {0, 1} 4 Goal: determine the value of b (better than by guessing) O has to be randomized Introduction /21

14 Acodethat snotind-cpa Figure: Calvin & Hobbes code (Watterson) Introduction /21

15 Randomness is key in crypto Random numbers always needed To generate keys To generate initialization vectors (IVs) or nonces To generate random masks (to protect against some attacks) Etc. Introduction /21

16 Random number generation is not easy Lead to severe vulnerabilities, several times. For instance: Debian s OpenSSL key generation ( ) WWW RSA private keys with shared factors (Lenstra et al., 2012) Smartcard RSA w/ biased private keys (Bernstein et al., 2013) Smartcard RSA w/ biased private keys (Nemec et al., 2017) Introduction /21

17 How not to generate random numbers Figure: XKCD s PRNG (Munroe) Introduction /21

18 How not to generate random numbers Figure: Dilbert s PRNG (Adams) Terrible Kolmogorov complexity! Introduction /21

19 How to generate them, then? A basic idea (e.g. /dev/random) Set up a random state (from e.g. physical sources) Refresh it continuously as randomness comes by Extract and refresh when outputs are needed Introduction /21

20 Random numbers are all you need? A perfect encryption scheme, the one-time pad 1 Let the message m be in {0, 1} n, n maybe large (say, 2 40 ) 2 Let the key k be $ {0, 1} n 3 The ciphertext c = m k Knowing c does not give information about m (Exercise) Problems: Integrity not guaranteed Needs very large keys Needs perfect randomness too! Later, we ll see how to solve such issues practically Introduction /21

21 Keys: secret, private, public... What are crypto keys like? Stream/Block cipher: a binary string Hash functions: RSA: a prime number (secret), an integer (public) Di e-hellman: an integer (secret), a group element (public) Code-based: a (generating) matrix (of a code) (one secret, one public) Etc. Introduction /21

22 Secrets large and small What should the secret/public key size be (in bits)? Stream ciphers? Block ciphers? RSA? Di e-hellman (well-chosen F q )? Di e-hellman (well-chosen E(Fq ))? Code-based (McEliece, Binary Goppa codes)? Introduction /21

23 Secrets large and small What should the secret/public key size be (in bits)? Stream ciphers: e.g. 128 bits (+ a large (e.g. 128 bits) IV necessary) Block ciphers: e.g. 128 bits RSA: e.g bits Di e-hellman (well-chosen F q ): e.g bits Di e-hellman (well-chosen E(Fq )): e.g. 256 bits Code-based (McEliece, Binary Goppa codes)? e.g bytes Introduction /21

24 Secrets large and small What should the secret/public key size be (in bits)? Quite a complex matter! (Follow recommendations, e.g. from ANSSI!) Introduction /21

25 What s 128 bits anyway? Objective: run a function times within 34 years ( 2 30 seconds), assuming: Hardware at 2 50 iterations/s (that s pretty good) Trivially parallelizable (that s not always the case in practice) 1000 W per device, no overhead (that s pretty good) machines needed GW round the clock EPR nuclear power plants (Of course, technology may improve, but here s quite a safe margin) Introduction /21