SLIDE 1 Goals of authenticated encryption Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven More details, credits: competitions.cr.yp.to /features.html Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 2
authenticated encryption
University of Illinois at Chicago & echnische Universiteit Eindhoven details, credits: competitions.cr.yp.to /features.html Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Authenticated sender
k: secret m: variable-length c: variable-length
SLIDE 3 encryption Bernstein Illinois at Chicago & Universiteit Eindhoven credits: competitions.cr.yp.to Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length c: variable-length
SLIDE 4 Chicago & Eindhoven Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 5 Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 6 Encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Same picture! But now c is slightly longer than m: includes an “authentication tag”.
SLIDE 7 Encryption sender k rk secret key. riable-length plaintext. riable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Same picture! But now c is slightly longer than m: includes an “authentication tag”. Message
k: secret n: public m: variable-length c: variable-length Changes hide repetitions
SLIDE 8 riable-length plaintext. riable-length ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Same picture! But now c is slightly longer than m: includes an “authentication tag”. Message numbers sender
k: secret key. n: public message m: variable-length c: variable-length Changes in message hide repetitions of
SLIDE 9 plaintext. ciphertext. Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Same picture! But now c is slightly longer than m: includes an “authentication tag”. Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext.
SLIDE 10 Authenticated encryption sender
k: secret key. m: variable-length plaintext. c: variable-length ciphertext. Same picture! But now c is slightly longer than m: includes an “authentication tag”. Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext.
SLIDE 11 Authenticated encryption sender k rk secret key. riable-length plaintext. riable-length ciphertext. picture! But now slightly longer than m: includes an “authentication tag”. Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext. Associated
k: secret n: public a: variable-length m: variable-length c: variable-length
SLIDE 12 encryption riable-length plaintext. riable-length ciphertext. But now longer than m: “authentication tag”. Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext. Associated data sender
k: secret key. n: public message a: variable-length m: variable-length c: variable-length
SLIDE 13 plaintext. ciphertext. : ation tag”. Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext. Associated data sender
k: secret key. n: public message number. a: variable-length associated m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 14 Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext. Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 15 Message numbers sender
k: secret key. n: public message number. m: variable-length plaintext. c: variable-length ciphertext. Changes in message number hide repetitions of plaintext. Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. No problem repeating a.
SLIDE 16 Message numbers sender
secret key. public message number. riable-length plaintext. riable-length ciphertext. Changes in message number repetitions of plaintext. Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. No problem repeating a. Secret me
k: secret n: secret a: variable-length m: variable-length c: variable-length
SLIDE 17 ers k message number. riable-length plaintext. riable-length ciphertext. message number
Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. No problem repeating a. Secret message numb sender
k: secret key. n: secret message a: variable-length m: variable-length c: variable-length
SLIDE 18 er. plaintext. ciphertext. er plaintext. Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. No problem repeating a. Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 19 Associated data sender
k: secret key. n: public message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. No problem repeating a. Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext.
SLIDE 20 ciated data sender
secret key. public message number. riable-length associated data. riable-length plaintext. riable-length ciphertext. roblem repeating a. Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. What is Plaintext associat message-numb Forge (n receiver legitimate “INT-PTXT” (integrity protection Stronger Forge at
SLIDE 21 a k message number. riable-length associated data. riable-length plaintext. riable-length ciphertext. eating a. Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. What is the attack Plaintext corruption, associated-data co message-number Forge (n; m; a) that receiver accepts but legitimate sender never “INT-PTXT” (integrity of plaintexts) protection against Stronger goal: Forge at least f messages.
SLIDE 22 er. ciated data. plaintext. ciphertext. Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages.
SLIDE 23 Secret message numbers sender
k: secret key. n: secret message number. a: variable-length associated data. m: variable-length plaintext. c: variable-length ciphertext. What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages.
SLIDE 24 message numbers sender
secret key. secret message number. riable-length associated data. riable-length plaintext. riable-length ciphertext. What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext Forge c receiver legitimate “INT-CTXT” (integrity protection
SLIDE 25
numbers a k ssage number. riable-length associated data. riable-length plaintext. riable-length ciphertext. What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext corruption. Forge c that receiver accepts but legitimate sender never “INT-CTXT” (integrity of ciphertexts) protection against
SLIDE 26
er. ciated data. plaintext. ciphertext. What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks.
SLIDE 27
What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks.
SLIDE 28
What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string.
SLIDE 29
What is the attacker’s goal? Plaintext corruption, associated-data corruption, message-number corruption. Forge (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means protection against such attacks. Stronger goal: Forge at least f messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits?
SLIDE 30
is the attacker’s goal? Plaintext corruption, ciated-data corruption, message-number corruption. (n; m; a) that receiver accepts but that legitimate sender never encrypted. “INT-PTXT” (integrity of plaintexts) means rotection against such attacks. Stronger goal: at least f messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince legitimate than legitimate
SLIDE 31
attacker’s goal? rruption, data corruption, er corruption. that but that der never encrypted. plaintexts) means nst such attacks. messages. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to legitimate (n; m; a) than legitimate sender
SLIDE 32
goal? rruption, rruption. encrypted. means attacks. Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it.
SLIDE 33
Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it.
SLIDE 34
Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order.
SLIDE 35
Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc.
SLIDE 36
Ciphertext corruption. Forge c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means protection against such attacks. Ciphertext prediction. Distinguish c from uniform random string. Is it better to randomly pad or zero-pad a strong 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal?
SLIDE 37
Ciphertext corruption. c that receiver accepts but that legitimate sender never produced. “INT-CTXT” (integrity of ciphertexts) means rotection against such attacks. Ciphertext prediction. Distinguish c from random string. etter to randomly pad or zero-pad a 112-bit MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext Figure out
SLIDE 38
rruption. but that der never produced. ciphertexts) means nst such attacks. rediction. from string. r zero-pad a MAC to 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret
SLIDE 39
roduced. means attacks. a 128 bits? Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret message.
SLIDE 40
Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret message.
SLIDE 41
Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number.
SLIDE 42
Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway.
SLIDE 43
Replay. Convince receiver to accept legitimate (n; m; a) more times than legitimate sender sent it. Reordering. Convince receiver to accept legitimate messages out of order. Sabotage. Prevent receiver from seeing (n; m; a) as often as sender sent it: flood radio, switch, CPU, etc. Typically delegate solutions to higher-level protocols, but is this optimal? Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default.
SLIDE 44 y. Convince receiver to accept legitimate (n; m; a) more times legitimate sender sent it. dering. Convince receiver to accept legitimate messages out of order.
Prevent receiver from seeing a) as often as sender sent
- d radio, switch, CPU, etc.
ypically delegate solutions higher-level protocols, this optimal? Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are Extensive Are 80-bit Are 128-bit
SLIDE 45 r to accept ; a) more times sender sent it. r to accept ssages out of order. from seeing
switch, CPU, etc. delegate solutions rotocols,
Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are the attack Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate?
SLIDE 46 accept times sent it. accept
seeing sender sent CPU, etc. solutions Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate?
SLIDE 47
Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate?
SLIDE 48 Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
SLIDE 49 Plaintext espionage. Figure out user’s secret message. Message-number espionage. Figure out user’s secret message number. Traditional crypto view: It’s okay to use a counter as a message number. Count is public anyway. Counterarguments: Did attacker see everything? Maybe timestamp is better, but how much does it leak? Should encrypt by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough.
SLIDE 50 Plaintext espionage.
- ut user’s secret message.
Message-number espionage.
message number. raditional crypto view: ay to use a counter message number. is public anyway. Counterarguments: attacker see everything? timestamp is better, w much does it leak? encrypt by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main countera
User doesn’t better perfo
SLIDE 51 espionage. user’s secret message. er espionage. user’s secret er. crypto view: a counter number. anyway. rguments: everything? timestamp is better, does it leak? by default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main counterarguments
User doesn’t actually better performance.
SLIDE 52 message. espionage. everything? etter, leak? default. What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
SLIDE 53 What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
SLIDE 54 What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
SLIDE 55 What are the attacker’s resources? Extensive computation. Are 80-bit keys adequate? Are 128-bit keys adequate? Main arguments for small keys:
- 1. Smaller keys are cheaper.
- 2. Attack cost outweighs
economic benefit of breaking key, so no sensible attacker will carry out a 280 attack. Maybe 64-bit keys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible?
SLIDE 56 are the attacker’s resources? Extensive computation. 80-bit keys adequate? 128-bit keys adequate? arguments for small keys: Smaller keys are cheaper. ttack cost outweighs economic benefit of breaking key, sensible attacker will
64-bit keys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible? Back-of-the-envelop 257 watts: atmosphere 244 watts: 226 watts: costing 2 1 watt: p 268 bit op using mass-ma
SLIDE 57 attacker’s resources? computation. adequate? adequate? for small keys: are cheaper.
enefit of breaking key, attacker will attack. eys are enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible? Back-of-the-envelop 257 watts: received atmosphere from the 244 watts: world p 226 watts: one computer costing 230 dollars. 1 watt: power for 268 bit operations using mass-market
SLIDE 58 resources? adequate? keys: er. reaking key, will enough. Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible? Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs.
SLIDE 59 Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible? Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs.
SLIDE 60 Main counterarguments:
- 1. Larger keys are cheap enough.
User doesn’t actually need better performance.
- 2. Attacker’s cost-benefit ratio
is improved by multiple-user attacks, multiple forgeries, etc.
- 3. Some attackers carry out
attacks that are feasible but not economically rational. What attacks are feasible? Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm.
SLIDE 61
counterarguments: rger keys are cheap enough. doesn’t actually need performance. ttacker’s cost-benefit ratio roved by multiple-user attacks, multiple forgeries, etc. Some attackers carry out attacks that are feasible not economically rational. attacks are feasible? Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm. Many messages. Some designers “switch k Other designers eliminating adds robustness.
SLIDE 62
rguments: re cheap enough. actually need rmance. cost-benefit ratio attacks, rgeries, etc. ers carry out feasible economically rational. re feasible? Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm. Many messages. Some designers blame “switch keys after Other designers argue eliminating such requirements adds robustness.
SLIDE 63 enough. ratio
rational. Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm. Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness.
SLIDE 64
Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm. Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness.
SLIDE 65
Back-of-the-envelope figures: 257 watts: received by Earth’s atmosphere from the Sun. 244 watts: world power usage. 226 watts: one computer center costing 230 dollars. 1 watt: power for 268 bit operations per year using mass-market GPUs. Scalable quantum computers. 264 simple quantum operations to find a 128-bit key using Grover’s algorithm. Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks.
SLIDE 66
Back-of-the-envelope figures: atts: received by Earth’s atmosphere from the Sun. atts: world power usage. atts: one computer center costing 230 dollars. att: power for bit operations per year mass-market GPUs. Scalable quantum computers. simple quantum operations a 128-bit key Grover’s algorithm. Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. degrade
SLIDE 67
Back-of-the-envelope figures: received by Earth’s the Sun. power usage. computer center rs. r erations per year et GPUs. quantum computers. quantum operations key algorithm. Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. How degrade with numb
SLIDE 68
figures: rth’s usage. center r computers. erations Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. How does securit degrade with number of keys?
SLIDE 69
Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. How does security degrade with number of keys?
SLIDE 70
Many messages. Some designers blame the user: “switch keys after 220 messages”. Other designers argue that eliminating such requirements adds robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. All ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′.
SLIDE 71
messages. designers blame the user: “switch keys after 220 messages”. designers argue that eliminating such requirements robustness. Chosen plaintexts, chosen ciphertexts, chosen message numbers. Consensus: Unacceptable to blame the user. ciphers must be safe against chosen-plaintext attacks and against chosen-ciphertext attacks. Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software Typical culp secret branches, secret m Also, on secret m
SLIDE 72
messages. blame the user: after 220 messages”. argue that requirements robustness. plaintexts, ciphertexts, message numbers. blame the user. be safe against attacks and chosen-ciphertext attacks. Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication
SLIDE 73
user: messages”. that requirements ers. the user. against and attacks. Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs.
SLIDE 74
Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs.
SLIDE 75
Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
SLIDE 76 Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
SLIDE 77 Many users. How does security degrade with number of keys? Repeated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact for many ciphers: Leak number of shared initial blocks of plaintext. Leak xor of first non-shared block. Allow forgery under this n. Allow forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
Thefts and monitors. Attacker steals secret keys. Can we still protect past communication?
SLIDE 78
degrade with number of keys? eated message numbers. Minimum impact: Attacker sees whether (n; m; a) is repeated. Examples of larger impact ny ciphers: number of shared initial
xor of first non-shared block. forgery under this n. forgery under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
Thefts and monitors. Attacker steals secret keys. Can we still protect past communication? What perfo Typical p for ASICs: Low energy Low pow Low area loosely p “gate equivalents”). High throughput (bytes per Low latency very loosely
SLIDE 79 How does security number of keys? message numbers. impact: Attacker sees ) is repeated. rger impact ciphers: shared initial plaintext. non-shared block. under this n. under any n′. Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
Thefts and monitors. Attacker steals secret keys. Can we still protect past communication? What performance Typical performance for ASICs: Low energy (joules) Low power (watts). Low area (square m loosely predicted b “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted
SLIDE 80 security eys? numbers. er sees eated. initial red block. . . Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
Thefts and monitors. Attacker steals secret keys. Can we still protect past communication? What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles).
SLIDE 81 Software side channels. Typical culprits: secret branches, secret memory addresses. Also, on some CPUs, secret multiplication inputs. Hardware side channels. Power consumption, electromagnetic radiation, etc.
- Faults. Flip bits in computation.
Thefts and monitors. Attacker steals secret keys. Can we still protect past communication? What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles).
SLIDE 82 are side channels. ypical culprits: branches, memory addresses.
multiplication inputs. are side channels. consumption, electromagnetic radiation, etc.
- ts. Flip bits in computation.
Thefts and monitors. er steals secret keys. e still protect communication? What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles). Similar m FPGAs and For ASICs throughput is not a useful without Parallelize
for arbitra
SLIDE 83 channels. addresses. CPUs, plication inputs. channels. consumption, radiation, etc. in computation. monitors. secret keys. rotect communication? What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles). Similar metrics for FPGAs and softwa For ASICs and FPGAs, throughput per se is not a useful metric without limit on area Parallelize across blo
for arbitrarily high
SLIDE 84 inputs. etc. computation. eys. What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles). Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or pow Parallelize across blocks
- r across independent messages
for arbitrarily high throughput.
SLIDE 85 What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles). Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput.
SLIDE 86 What performance is measured? Typical performance metrics for ASICs: Low energy (joules) per byte. Low power (watts). Low area (square micrometers; loosely predicted by “gate equivalents”). High throughput (bytes per second). Low latency (seconds; very loosely predicted by cycles). Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte.
SLIDE 87 performance is measured? ypical performance metrics ASICs: energy (joules) per byte.
rea (square micrometers; predicted by equivalents”). throughput per second). latency (seconds;
- sely predicted by cycles).
Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte. What op Authenticate encrypt Cost per far below Send valid data, or “Encrypt cost of decryption
SLIDE 88 rmance is measured? rmance metrics (joules) per byte. atts). re micrometers; by equivalents”). throughput second). (seconds; redicted by cycles). Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte. What operations a Authenticate only encrypt and authenticate? Cost per byte of a far below cost per Send valid data, data, or receive invalid “Encrypt then MA cost of decryption
SLIDE 89 measured? metrics yte. icrometers; cycles). Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries.
SLIDE 90 Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries.
SLIDE 91 Similar metrics for FPGAs and software. For ASICs and FPGAs, throughput per se is not a useful metric without limit on area (or power). Parallelize across blocks
- r across independent messages
for arbitrarily high throughput. Fix: measure ratio of area and throughput, i.e., product of area and time per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation.
SLIDE 92 r metrics for FPGAs and software. ASICs and FPGAs, throughput per se a useful metric without limit on area (or power). rallelize across blocks ross independent messages rbitrarily high throughput. measure
- f area and throughput, i.e.,
duct of area and time per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation. Plaintext and asso Huge impact Warning: “overhead” Cipher with can be consiste
SLIDE 93
for ware. FPGAs, se metric area (or power). across blocks endent messages high throughput. throughput, i.e., and time per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation. Plaintext length and associated-data Huge impact on perfo Warning: Do not solely “overhead” of two Cipher with larger can be consistently
SLIDE 94
messages throughput. throughput, i.e., per byte. What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation. Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compa “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster.
SLIDE 95
What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation. Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster.
SLIDE 96
What operations are measured? Authenticate only, or encrypt and authenticate? Cost per byte of a can be far below cost per byte of m. Send valid data, receive valid data, or receive invalid data? “Encrypt then MAC” skips cost of decryption for forgeries. Different area targets: encryption/authentication circuit; verification/decryption circuit; circuit that can dynamically select either operation. Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length.
SLIDE 97
Authenticate only, or encrypt and authenticate? er byte of a can be elow cost per byte of m. valid data, receive valid
“Encrypt then MAC” skips
- f decryption for forgeries.
Different area targets: encryption/authentication circuit; verification/decryption circuit; that can dynamically select
Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length. Number Most (not expect p “expanded Warning: “agility” Cipher with can be consiste
SLIDE 98 are measured?
authenticate? a can be er byte of m. data, receive valid receive invalid data? MAC” skips decryption for forgeries. rgets: encryption/authentication circuit; verification/decryption circuit; dynamically select eration. Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length. Number of times Most (not all) ciphers expect precomputation “expanded keys”. Warning: Do not solely “agility” of two ciphers. Cipher with better can be consistently
SLIDE 99
measured? authenticate? m. valid data? skips rgeries. circuit; circuit; dynamically select Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length. Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compa “agility” of two ciphers. Cipher with better “agility” can be consistently slower.
SLIDE 100
Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length. Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower.
SLIDE 101
Plaintext length and associated-data length. Huge impact on performance. Warning: Do not solely compare “overhead” of two ciphers. Cipher with larger “overhead” can be consistently faster. Number of inputs. e.g. reduce latency by processing several AES-CBC messages in parallel. Simplest if many messages have the same length. Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext.
SLIDE 102
Plaintext length associated-data length. impact on performance. rning: Do not solely compare “overhead” of two ciphers. with larger “overhead” consistently faster. er of inputs. reduce latency by cessing several AES-CBC messages in parallel. Simplest if many messages the same length. Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext. Scheduling scheduling Typically to right. processing (“Incrementalit Update output when input
SLIDE 103 length ciated-data length. performance. not solely compare
rger “overhead” ntly faster. inputs. latency by ral AES-CBC rallel. messages length. Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext. Scheduling within scheduling within Typically receive data to right. Reduce latency processing earlier pa (“Incrementality”: Update output efficiently when input is modified.)
SLIDE 104
length. rmance. compare ciphers. “overhead” AES-CBC messages Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.)
SLIDE 105
Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.)
SLIDE 106
Number of times a key is used. Most (not all) ciphers expect precomputation of “expanded keys”. Warning: Do not solely compare “agility” of two ciphers. Cipher with better “agility” can be consistently slower. General input scheduling. Reduce latency by processing key and nonce before seeing associated data; associated data before plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext.
SLIDE 107
er of times a key is used. (not all) ciphers precomputation of “expanded keys”. rning: Do not solely compare y” of two ciphers. with better “agility” consistently slower. General input scheduling. Reduce latency by cessing key and nonce seeing associated data; ciated data before plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate Higher-level long plaintext each sepa ⇒ small Do better similar featu
SLIDE 108
times a key is used. ciphers tation of ys”. not solely compare ciphers. etter “agility” ntly slower. scheduling. by and nonce associated data; before plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol long plaintext into each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into
SLIDE 109
is used. compare y” er. scheduling. data; plaintext. Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher?
SLIDE 110
Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher?
SLIDE 111
Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc.
SLIDE 112
Scheduling within plaintext; scheduling within ciphertext. Typically receive data from left to right. Reduce latency by processing earlier parts first. (“Incrementality”: Update output efficiently when input is modified.) Also save area if large plaintext does not need large buffer. Warning: Large ciphertext needs large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory?
SLIDE 113 Scheduling within plaintext; scheduling within ciphertext. ypically receive data from left
cessing earlier parts first. (“Incrementality”: date output efficiently input is modified.) save area if large plaintext not need large buffer. rning: Large ciphertext large buffer or analysis of security impact of releasing unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support Simplicit Cryptanalysts that are
SLIDE 114
within plaintext; within ciphertext. data from left latency by rlier parts first. y”: efficiently modified.) large plaintext rge buffer. ciphertext buffer or security impact of unverified plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support for cryptanalysis Simplicity. Cryptanalysts prioritize that are easy to understand.
SLIDE 115 plaintext; ciphertext. left y first. plaintext buffer.
plaintext. Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support for cryptanalysis Simplicity. Cryptanalysts prioritize targets that are easy to understand.
SLIDE 116
Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support for cryptanalysis Simplicity. Cryptanalysts prioritize targets that are easy to understand.
SLIDE 117
Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support for cryptanalysis Simplicity. Cryptanalysts prioritize targets that are easy to understand. Scalability. Reduced-round targets, reduced-word targets, etc.
SLIDE 118
Intermediate tags. Higher-level protocol splits long plaintext into packets, each separately authenticated. ⇒ small buffer is safe. Do better by integrating similar feature into cipher? Other operations. Single circuit for, e.g., hash and authenticated cipher; for different key sizes; etc. Cache context. How well does the system fit into fast memory? Support for cryptanalysis Simplicity. Cryptanalysts prioritize targets that are easy to understand. Scalability. Reduced-round targets, reduced-word targets, etc. Proofs. The phrase “proof of security” is almost always fraudulent. Proof says that attacks meeting certain constraints are difficult, or as difficult as another problem. Can be useful for cryptanalysts.
