The post-quantum Internet Risk management Daniel J. Bernstein - - PowerPoint PPT Presentation

1

The post-quantum Internet Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven Includes joint work with: Tanja Lange Technische Universiteit Eindhoven

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS.

1

• st-quantum Internet
• J. Bernstein

University of Illinois at Chicago & echnische Universiteit Eindhoven Includes joint work with: Lange echnische Universiteit Eindhoven

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS. Also many >100 scientific Costs of breaking ≈2120, ≈ ≈2110, ≈ ≈2100, ≈ ≈280, ≈ (FFS is not

1

• st-quantum Internet

Bernstein Illinois at Chicago & Universiteit Eindhoven rk with: Universiteit Eindhoven

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS. Also many smaller >100 scientific pap Costs of these algo breaking RSA-1024, ≈2120, ≈2170, CFRA ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant

1

Internet Chicago & Eindhoven Eindhoven

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS. Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.)

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.)

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

2

Risk management “Combining congruences”: state-of-the-art pre-quantum attack against original DH, RSA, and some lattice systems. Long history, including many major improvements: 1975, CFRAC; 1977, linear sieve (LS); 1982, quadratic sieve (QS); 1990, number-field sieve (NFS); 1994, function-field sieve (FFS); 2006, medium-prime FFS/NFS; 2013, xq − x FFS.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

2

management “Combining congruences”: state-of-the-art pre-quantum against original DH, and some lattice systems. history, including major improvements: CFRAC; linear sieve (LS); quadratic sieve (QS); number-field sieve (NFS); function-field sieve (FFS); medium-prime FFS/NFS; xq − x FFS.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

If we put exploring will we find At least

2

management congruences”: pre-quantum riginal DH, lattice systems. including rovements: sieve (LS); sieve (QS); er-field sieve (NFS); function-field sieve (FFS); rime FFS/NFS; FFS.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

If we put enough effo exploring Attack Mountain, will we find the highes At least within ›?

2

congruences”: re-quantum DH, systems. rovements: (QS); (NFS); (FFS); FFS/NFS;

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›?

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›?

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet.

3

Also many smaller improvements: >100 scientific papers. Costs of these algorithms for breaking RSA-1024, RSA-2048: ≈2120, ≈2170, CFRAC; ≈2110, ≈2160, LS; ≈2100, ≈2150, QS; ≈280, ≈2112, NFS. (FFS is not relevant to RSA.) How much risk is there

• f future breakthroughs?

How much risk is there

• f secret breakthroughs?

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms.

3

many smaller improvements: scientific papers.

• f these algorithms for

reaking RSA-1024, RSA-2048: , ≈2170, CFRAC; , ≈2160, LS; , ≈2150, QS; , ≈2112, NFS. is not relevant to RSA.) much risk is there future breakthroughs? much risk is there secret breakthroughs?

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms. Conservative prefer mounta less huge, more tho

3

smaller improvements: papers. algorithms for RSA-1024, RSA-2048: CFRAC; LS; QS; NFS. relevant to RSA.) is there reakthroughs? is there reakthroughs?

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms. Conservative cryptographers prefer mountains that less huge, less foggy more thoroughly explo

3

rovements: for RSA-2048: RSA.)

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms. Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored.

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored.

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.”

4

If we put enough effort into exploring Attack Mountain, will we find the highest peak? At least within ›? Combining-Congruences Mountain is a huge, foggy, high-dimensional mountain with many paths up. Scary: easy to imagine that we’re not at the top yet. 18-year bet announced in 2014: Joux wins if RSA-2048 is broken first by pre-quantum algorithms; I win if RSA-2048 is broken first by quantum algorithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.” This is the core argument for

• ECC. Exceptions: rare curves with

special structure—e.g., pairings.

4

put enough effort into ring Attack Mountain, find the highest peak? least within ›? Combining-Congruences Mountain huge, foggy, high-dimensional mountain with many paths up. easy to imagine that not at the top yet. r bet announced in 2014: wins if RSA-2048 is broken y pre-quantum algorithms; if RSA-2048 is broken y quantum algorithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.” This is the core argument for

• ECC. Exceptions: rare curves with

special structure—e.g., pairings. 2015 Lange: bet your

4

effort into Mountain, highest peak? ? Combining-Congruences Mountain high-dimensional many paths up. imagine that top yet. announced in 2014: RSA-2048 is broken re-quantum algorithms; RSA-2048 is broken algorithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.” This is the core argument for

• ECC. Exceptions: rare curves with

special structure—e.g., pairings. 2015 Lange: “Would bet your kidneys on

4

into Mountain, eak? Mountain high-dimensional paths up. that 2014: broken rithms; en rithms.

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.” This is the core argument for

• ECC. Exceptions: rare curves with

special structure—e.g., pairings. 2015 Lange: “Would you bet your kidneys on that?”

5

Conservative cryptographers prefer mountains that seem less huge, less foggy, more thoroughly explored. 1986 Miller “Use of elliptic curves in cryptography”: “It is extremely unlikely that an ‘index calculus’ attack [combining-congruences attack]

• n the elliptic curve method

will ever be able to work.” This is the core argument for

• ECC. Exceptions: rare curves with

special structure—e.g., pairings.

6

2015 Lange: “Would you bet your kidneys on that?”

5

Conservative cryptographers mountains that seem huge, less foggy, thoroughly explored. Miller “Use of curves in cryptography”: extremely unlikely an ‘index calculus’ attack [combining-congruences attack] elliptic curve method ever be able to work.” the core argument for Exceptions: rare curves with ecial structure—e.g., pairings.

6

2015 Lange: “Would you bet your kidneys on that?” Risk of future big universal noticeable terrifying

5

cryptographers ins that seem foggy, explored. “Use of cryptography”: unlikely calculus’ attack [combining-congruences attack] curve method to work.” argument for Exceptions: rare curves with structure—e.g., pairings.

6

2015 Lange: “Would you bet your kidneys on that?” Risk of future attack big universal quantum noticeable probabilit terrifying impact.

5

cryptographers cryptography”: attack attack] d for curves with pairings.

6

2015 Lange: “Would you bet your kidneys on that?” Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact.

6

2015 Lange: “Would you bet your kidneys on that?”

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact.

6

2015 Lange: “Would you bet your kidneys on that?”

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact. Fortunately, we already know some confidence-inspiring post-quantum systems, including

• hash-based signatures;
• McEliece public-key encryption;
• AES-256 etc.

https://pqcrypto.eu.org/docs/ initial-recommendations.pdf

6

Lange: “Would you

• ur kidneys on that?”

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact. Fortunately, we already know some confidence-inspiring post-quantum systems, including

• hash-based signatures;
• McEliece public-key encryption;
• AES-256 etc.

https://pqcrypto.eu.org/docs/ initial-recommendations.pdf Application: Your computer new version Your computer signature from the Critical use Otherwise insert malw e.g. OpenBSD signed using ECC signature

6

• uld you
• n that?”

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact. Fortunately, we already know some confidence-inspiring post-quantum systems, including

• hash-based signatures;
• McEliece public-key encryption;
• AES-256 etc.

https://pqcrypto.eu.org/docs/ initial-recommendations.pdf Application: softw Your computer dow new version of its Your computer checks signature on the do from the OS manufacturer. Critical use of crypto! Otherwise criminals insert malware into e.g. OpenBSD updates signed using state-of-the-a ECC signature system:

6

that?”

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact. Fortunately, we already know some confidence-inspiring post-quantum systems, including

• hash-based signatures;
• McEliece public-key encryption;
• AES-256 etc.

https://pqcrypto.eu.org/docs/ initial-recommendations.pdf Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519.

7

Risk of future attacker having big universal quantum computer: noticeable probability; terrifying impact. Fortunately, we already know some confidence-inspiring post-quantum systems, including

• hash-based signatures;
• McEliece public-key encryption;
• AES-256 etc.

https://pqcrypto.eu.org/docs/ initial-recommendations.pdf

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519.

7

• f future attacker having

universal quantum computer: noticeable probability; terrifying impact. nately, we already know confidence-inspiring

• st-quantum systems, including

hash-based signatures; McEliece public-key encryption; AES-256 etc. https://pqcrypto.eu.org/docs/ initial-recommendations.pdf

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519. Pre-quantum needs to post-quantum

7

attacker having antum computer: ability; impact. already know e-inspiring systems, including signatures; ublic-key encryption; https://pqcrypto.eu.org/docs/ initial-recommendations.pdf

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519. Pre-quantum signature needs to be replaced post-quantum signature

7

having computer: know including encryption; https://pqcrypto.eu.org/docs/ initial-recommendations.pdf

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519. Pre-quantum signature system needs to be replaced with post-quantum signature system

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q.

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature.

8

Application: software updates Your computer downloads new version of its OS. Your computer checks signature on the download from the OS manufacturer. Critical use of crypto! Otherwise criminals could insert malware into the OS. e.g. OpenBSD updates are signed using state-of-the-art ECC signature system: Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature.

8

Application: software updates computer downloads version of its OS. computer checks signature on the download the OS manufacturer. Critical use of crypto! Otherwise criminals could malware into the OS. OpenBSD updates are using state-of-the-art signature system: Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature. e.g. Ed25519+SPHINCS-256. SPHINCS-256 ≈50 million ≈1 million Negligible verify compa

8

software updates downloads its OS. checks download manufacturer. crypto! nals could into the OS. updates are state-of-the-art system: Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature. e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature ≈50 million cycles ≈1 million cycles to Negligible cost to sign, verify compared to

8

dates manufacturer. OS. re rt Ed25519.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature. e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway.

9

Pre-quantum signature system P needs to be replaced with post-quantum signature system Q. Make auditors happier: Replace P with P + Q. P + Q public key concatenates P public key, Q public key. P + Q signature concatenates P signature, Q signature. Want a tiny public key? Replace public key with hash. Include missing information (≤ entire key) inside signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security.

9

Pre-quantum signature system P to be replaced with

• st-quantum signature system Q.

auditors happier: Replace P with P + Q. public key concatenates public key, Q public key. signature concatenates signature, Q signature. a tiny public key? Replace public key with hash. Include missing information entire key) inside signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security. Does deplo mean that On the contra Pre-quantum Hash-based even more than ECC But understanding takes extra

9

signature system P replaced with signature system Q. happier: P + Q. ey concatenates public key. concatenates signature. public key? ey with hash. information inside signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security. Does deployment of mean that we don’t On the contrary! Pre-quantum situation: Hash-based signatures even more confidence-inspiring than ECC signature But understanding takes extra work fo

9

system P system Q. concatenates . concatenates sh. rmation signature.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security. Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security.

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor.

10

e.g. Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; ≈50 million cycles to generate; ≈1 million cycles to verify. Negligible cost to sign, transmit, verify compared to OS update. +Ed25519: unnoticeable cost. Some extra system complexity, but the system includes Ed25519 code anyway. Auditor sees very easily that Ed25519+SPHINCS-256 security ≥ Ed25519 security.

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor. Long-term situation: Users see quantum computers easily breaking P. Simplify system by switching from P + Q to Q.

10

Ed25519+SPHINCS-256. SPHINCS-256 signature is 41KB; million cycles to generate; million cycles to verify. Negligible cost to sign, transmit, compared to OS update. +Ed25519: unnoticeable cost. extra system complexity, the system includes Ed25519 code anyway. r sees very easily Ed25519+SPHINCS-256 y ≥ Ed25519 security.

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor. Long-term situation: Users see quantum computers easily breaking P. Simplify system by switching from P + Q to Q. IP: Internet IP communicates limited-length Each computer has a 4-b e.g. www.pqcrypto.org address 131.155.70.11 Your bro addressed gives pack Hopefully that pack

10

Ed25519+SPHINCS-256. signature is 41KB; cycles to generate; cycles to verify. to sign, transmit, to OS update. unnoticeable cost. system complexity, includes anyway. very easily Ed25519+SPHINCS-256 Ed25519 security.

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor. Long-term situation: Users see quantum computers easily breaking P. Simplify system by switching from P + Q to Q. IP: Internet Protocol IP communicates “pack limited-length byte Each computer on has a 4-byte “IP address”. e.g. www.pqcrypto.org address 131.155.70.11 Your browser creates addressed to 131.155.70.11 gives packet to the Hopefully the Internet that packet to 131.155.70.11

10

Ed25519+SPHINCS-256. 41KB; generate; . transmit, date. cost. complexity, Ed25519+SPHINCS-256 security.

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor. Long-term situation: Users see quantum computers easily breaking P. Simplify system by switching from P + Q to Q. IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11 gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11

11

Does deployment of P + Q mean that we don’t trust Q? On the contrary! Pre-quantum situation: Hash-based signatures are even more confidence-inspiring than ECC signatures. But understanding this fact takes extra work for auditor. Long-term situation: Users see quantum computers easily breaking P. Simplify system by switching from P + Q to Q.

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11.

11

deployment of P + Q that we don’t trust Q? the contrary! Pre-quantum situation: Hash-based signatures are more confidence-inspiring ECC signatures. understanding this fact extra work for auditor. Long-term situation: see quantum computers breaking P. Simplify system switching from P + Q to Q.

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11. DNS: Domain You actually connect Browser by asking the pqcrypto.org Browser “Where

11

t of P + Q don’t trust Q? ry! situation: signatures are confidence-inspiring signatures. understanding this fact for auditor. situation: quantum computers . Simplify system from P + Q to Q.

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11. DNS: Domain Name You actually told y connect to www.pqcrypto.org Browser learns “131.155.70.11 by asking a name server, the pqcrypto.org Browser → 131.155.71.143 “Where is www.pqcrypto.org?

11

Q? confidence-inspiring fact auditor. computers Simplify system to Q.

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11. DNS: Domain Name System You actually told your browser connect to www.pqcrypto.org Browser learns “131.155.70.11 by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143 “Where is www.pqcrypto.org?

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?”

12

IP: Internet Protocol IP communicates “packets”: limited-length byte strings. Each computer on the Internet has a 4-byte “IP address”. e.g. www.pqcrypto.org has address 131.155.70.11. Your browser creates a packet addressed to 131.155.70.11; gives packet to the Internet. Hopefully the Internet delivers that packet to 131.155.70.11.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11”

12

Internet Protocol communicates “packets”: limited-length byte strings. computer on the Internet 4-byte “IP address”. www.pqcrypto.org has address 131.155.70.11. rowser creates a packet addressed to 131.155.70.11; packet to the Internet. efully the Internet delivers packet to 131.155.70.11.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11” Browser address, by asking Browser “Where 199.19.54.1 “Ask the name server,

12

Protocol communicates “packets”: yte strings.

• n the Internet

address”. www.pqcrypto.org has 131.155.70.11. creates a packet 131.155.70.11; the Internet. Internet delivers 131.155.70.11.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11” Browser learns the address, “131.155.71.143 by asking the .org Browser → 199.19.54.1 “Where is www.pqcrypto.org? 199.19.54.1 → b “Ask the pqcrypto.org name server, 131.155.71.143

12

ets”: strings. Internet address”. has packet 131.155.70.11; Internet. delivers 131.155.70.11.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11” Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org? 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11”

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143”

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11”

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server.

13

DNS: Domain Name System You actually told your browser to connect to www.pqcrypto.org. Browser learns “131.155.70.11” by asking a name server, the pqcrypto.org name server. Browser → 131.155.71.143: “Where is www.pqcrypto.org?” IP packet from browser also includes a return address: the address of your computer. 131.155.71.143 → browser: “131.155.70.11”

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible.

13

Domain Name System actually told your browser to connect to www.pqcrypto.org. wser learns “131.155.70.11” asking a name server, pqcrypto.org name server. wser → 131.155.71.143: is www.pqcrypto.org?” packet from browser also includes a return address: address of your computer. 131.155.71.143 → browser: 131.155.70.11”

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible. TCP: Transmission Packets (Actually Oldest IP ≥576. Usually

• ften 1500,

13

Name System told your browser to www.pqcrypto.org. 131.155.70.11” name server, pqcrypto.org name server. 131.155.71.143: www.pqcrypto.org?” rowser also address:

• ur computer.

→ browser: ”

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible. TCP: Transmission Packets are limited (Actually depends Oldest IP standards ≥576. Usually 1492

• ften 1500, sometimes

13

System wser to www.pqcrypto.org. 131.155.70.11” server. 131.155.71.143: www.pqcrypto.org?” also computer. wser:

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible. TCP: Transmission Control Proto Packets are limited to 1280 b (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible.

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible.

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit.

14

Browser learns the name-server address, “131.155.71.143”, by asking the .org name server. Browser → 199.19.54.1: “Where is www.pqcrypto.org?” 199.19.54.1 → browser: “Ask the pqcrypto.org name server, 131.155.71.143” Browser learns “199.19.54.1”, the .org server address, by asking the root name server. Browser learned root address by consulting the Bible.

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit. Browser actually makes “TCP connection” to pqcrypto.org. Inside that connection: sends HTTP request, receives response.

14

wser learns the name-server address, “131.155.71.143”, asking the .org name server. wser → 199.19.54.1: is www.pqcrypto.org?” 199.19.54.1 → browser: the pqcrypto.org server, 131.155.71.143” wser learns “199.19.54.1”, .org server address, asking the root name server. wser learned root address consulting the Bible.

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit. Browser actually makes “TCP connection” to pqcrypto.org. Inside that connection: sends HTTP request, receives response. Browser “SYN 168bb5d9 Server → “ACK 168bb5da, Browser “ACK 747bfa42 Server no for this TCP Browser counting Server splits counting

14

the name-server 131.155.71.143”, .org name server. 199.19.54.1: www.pqcrypto.org?” browser: pqcrypto.org 131.155.71.143” 199.19.54.1”, address,

• t name server.

root address the Bible.

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit. Browser actually makes “TCP connection” to pqcrypto.org. Inside that connection: sends HTTP request, receives response. Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN Browser → server: “ACK 747bfa42” Server now allocates for this TCP connection. Browser splits data counting bytes from Server splits data into counting bytes from

14

name-server ”, server. : www.pqcrypto.org?” 131.155.71.143” 199.19.54.1”, server. address

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit. Browser actually makes “TCP connection” to pqcrypto.org. Inside that connection: sends HTTP request, receives response. Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41 Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into pack counting bytes from 168bb5da Server splits data into packets, counting bytes from 747bfa42

15

TCP: Transmission Control Protocol Packets are limited to 1280 bytes. (Actually depends on network. Oldest IP standards required ≥576. Usually 1492 is safe,

• ften 1500, sometimes more.)

The page you’re downloading from pqcrypto.org doesn’t fit. Browser actually makes “TCP connection” to pqcrypto.org. Inside that connection: sends HTTP request, receives response.

16

Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41” Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into packets, counting bytes from 168bb5da. Server splits data into packets, counting bytes from 747bfa42.

15

Transmission Control Protocol ts are limited to 1280 bytes. (Actually depends on network. IP standards required Usually 1492 is safe, 1500, sometimes more.) page you’re downloading pqcrypto.org doesn’t fit. wser actually makes “TCP connection” to pqcrypto.org. that connection: sends request, receives response.

16

Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41” Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into packets, counting bytes from 168bb5da. Server splits data into packets, counting bytes from 747bfa42. Main feature “reliable Internet

• r delivers

Doesn’t computer inside each Computer if data is Complicated retransmission avoiding

15

ransmission Control Protocol limited to 1280 bytes. ends on network. rds required 1492 is safe, sometimes more.) downloading pqcrypto.org doesn’t fit. makes “TCP pqcrypto.org. connection: sends receives response.

16

Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41” Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into packets, counting bytes from 168bb5da. Server splits data into packets, counting bytes from 747bfa42. Main feature adver “reliable data streams”. Internet sometimes

• r delivers packets

Doesn’t confuse T computer checks the inside each TCP pack Computer retransmits if data is not ackno Complicated rules retransmission schedule, avoiding network congestion.

15

Control Protocol 1280 bytes.

• rk.

required safe, re.) wnloading esn’t fit. “TCP pqcrypto.org. sends response.

16

Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41” Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into packets, counting bytes from 168bb5da. Server splits data into packets, counting bytes from 747bfa42. Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses pack

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion.

16

Browser → server: “SYN 168bb5d9” Server → browser: “ACK 168bb5da, SYN 747bfa41” Browser → server: “ACK 747bfa42” Server now allocates buffers for this TCP connection. Browser splits data into packets, counting bytes from 168bb5da. Server splits data into packets, counting bytes from 747bfa42.

17

Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion.

16

wser → server: 168bb5d9” → browser: 168bb5da, SYN 747bfa41” wser → server: 747bfa42” now allocates buffers is TCP connection. wser splits data into packets, counting bytes from 168bb5da. splits data into packets, counting bytes from 747bfa42.

17

Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion. Stream-level http://www.pqcrypto.org uses HTTP https://www.pqcrypto.org uses HTTP Your bro

• finds address
• makes
• inside

builds by exchangin

• inside

sends HTTP

16

server: ” wser: SYN 747bfa41” server: ” cates buffers connection. data into packets, from 168bb5da. data into packets, from 747bfa42.

17

Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion. Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP https://www.pqcrypto.org uses HTTP over TLS Your browser

• finds address 131.155.70.11
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto

• inside the TLS connection,

sends HTTP request

16

747bfa41” buffers packets, 168bb5da. packets, 747bfa42.

17

Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion. Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over T Your browser

• finds address 131.155.70.11
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc.

17

Main feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets

• r delivers packets out of order.

Doesn’t confuse TCP connections: computer checks the counter inside each TCP packet. Computer retransmits data if data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion.

18

Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over TCP. Your browser

• finds address 131.155.70.11;
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc.

17

feature advertised by TCP: “reliable data streams”. Internet sometimes loses packets delivers packets out of order. esn’t confuse TCP connections: computer checks the counter each TCP packet. Computer retransmits data is not acknowledged. Complicated rules to decide retransmission schedule, avoiding network congestion.

18

Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over TCP. Your browser

• finds address 131.155.70.11;
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc. What happ forges a pointing Or a TCP with bogus DNS soft TCP soft TLS soft something but has no Browser make a whole but this Huge damage

17

dvertised by TCP: treams”. es loses packets ets out of order. TCP connections: s the counter packet. retransmits data acknowledged. rules to decide schedule, congestion.

18

Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over TCP. Your browser

• finds address 131.155.70.11;
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc. What happens if attack forges a DNS pack pointing to fake server? Or a TCP packet with bogus data? DNS software is fo TCP software is fo TLS software sees something has gone but has no way to Browser using TLS make a whole new but this is slow and Huge damage from

17

TCP: packets

• rder.

connections: counter data wledged. decide congestion.

18

Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over TCP. Your browser

• finds address 131.155.70.11;
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc. What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged pack

18

Stream-level crypto http://www.pqcrypto.org uses HTTP over TCP. https://www.pqcrypto.org uses HTTP over TLS over TCP. Your browser

• finds address 131.155.70.11;
• makes TCP connection;
• inside the TCP connection,

builds a TLS connection by exchanging crypto keys;

• inside the TLS connection,

sends HTTP request etc.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet.

18

Stream-level crypto http://www.pqcrypto.org HTTP over TCP. https://www.pqcrypto.org HTTP over TLS over TCP. rowser address 131.155.70.11; es TCP connection; inside the TCP connection, builds a TLS connection exchanging crypto keys; inside the TLS connection, sends HTTP request etc.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet. Modern CurveCP; Google’s encrypt each Discard fo immediately: Retransmit authenticated

18

crypto http://www.pqcrypto.org TCP. https://www.pqcrypto.org TLS over TCP. 131.155.70.11; connection; connection, connection crypto keys; connection, request etc.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet. Modern trend (e.g., CurveCP; see also Google’s QUIC): Authenticate encrypt each packet Discard forged pack immediately: no damage. Retransmit packet authenticated ackno

18

http://www.pqcrypto.org https://www.pqcrypto.org TCP. 131.155.70.11; connection, eys; connection, etc.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet. Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate encrypt each packet separately Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto.

19

What happens if attacker forges a DNS packet pointing to fake server? Or a TCP packet with bogus data? DNS software is fooled. TCP software is fooled. TLS software sees that something has gone wrong, but has no way to recover. Browser using TLS can make a whole new connection, but this is slow and fragile. Huge damage from forged packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet.

19

happens if attacker a DNS packet

• inting to fake server?

TCP packet

• gus data?

software is fooled. software is fooled. software sees that something has gone wrong, has no way to recover. wser using TLS can a whole new connection, this is slow and fragile. damage from forged packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet. The KEM+AE Original Message as me mo

19

if attacker packet server? et data? fooled. fooled. sees that gone wrong, to recover. TLS can new connection, and fragile. from forged packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet. The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq.

19

wrong, recover. connection, fragile. packet.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet. The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k.

20

Modern trend (e.g., DNSCurve, CurveCP; see also MinimaLT, Google’s QUIC): Authenticate and encrypt each packet separately. Discard forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: Packet-level crypto works for more protocols than stream-level crypto. Disadvantage: Crypto must fit into packet.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. Fragile, many problems: e.g., Coppersmith attack, Bleichenbacher attack, bogus OAEP security proof.

20

dern trend (e.g., DNSCurve, CurveCP; see also MinimaLT,

• gle’s QUIC): Authenticate and

encrypt each packet separately. rd forged packet immediately: no damage. Retransmit packet if no authenticated acknowledgment. Engineering advantage: t-level crypto for more protocols stream-level crypto. Disadvantage: must fit into packet.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. Fragile, many problems: e.g., Coppersmith attack, Bleichenbacher attack, bogus OAEP security proof. Shoup’s “Key enc Choose random Encrypt Define k “Data encapsulation Encrypt m under Authenticato any modification Much easier Also generalizes P + Q: hash

20

(e.g., DNSCurve, also MinimaLT, QUIC): Authenticate and packet separately. packet damage. et if no acknowledgment. advantage: crypto rotocols stream-level crypto. into packet.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. Fragile, many problems: e.g., Coppersmith attack, Bleichenbacher attack, bogus OAEP security proof. Shoup’s “KEM+DEM” “Key encapsulation Choose random r mo Encrypt r as re mo Define k = H(r; re “Data encapsulation Encrypt and authe m under AES-GCM Authenticator catches any modification of Much easier to get Also generalizes nicely P + Q: hash concatenation.

20

DNSCurve, MinimaLT, Authenticate and rately. wledgment. et.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. Fragile, many problems: e.g., Coppersmith attack, Bleichenbacher attack, bogus OAEP security proof. Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod p Much easier to get right. Also generalizes nicely. P + Q: hash concatenation.

21

The KEM+AE philosophy Original view of RSA: Message m is encrypted as me mod pq. “Hybrid” view of RSA, including random padding: Choose random AES-GCM key k. Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. Fragile, many problems: e.g., Coppersmith attack, Bleichenbacher attack, bogus OAEP security proof.

22

Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod pq. Much easier to get right. Also generalizes nicely. P + Q: hash concatenation.

21

KEM+AE philosophy Original view of RSA: Message m is encrypted mod pq. rid” view of RSA, including random padding:

• se random AES-GCM key k.

Randomly pad k as r. Encrypt r as re mod pq. Encrypt m under k. ragile, many problems: Coppersmith attack, Bleichenbacher attack, OAEP security proof.

22

Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod pq. Much easier to get right. Also generalizes nicely. P + Q: hash concatenation. DEM sec weak single-message

• f securit

authenticated Chou: Is for multip Answer: KEM+AE (But need AES-GCM, aim for full More complicated Use KEM n-time sec

21

philosophy RSA: encrypted

• f RSA,

padding: AES-GCM key k. as r. mod pq. under k. roblems: ersmith attack, attack, security proof.

22

Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod pq. Much easier to get right. Also generalizes nicely. P + Q: hash concatenation. DEM security hypothesis: weak single-message

• f security for secret

authenticated encryption. Chou: Is it safe to for multiple messages? Answer: KEM+AE KEM+AE ⇒ KEM+“ (But need literature AES-GCM, Salsa20-P aim for full AE securit More complicated Use KEM+DEM to n-time secret key m

21

padding: key k.

• f.

22

Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod pq. Much easier to get right. Also generalizes nicely. P + Q: hash concatenation. DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt n-time secret key m; reuse m

22

Shoup’s “KEM+DEM” view: “Key encapsulation mechanism”: Choose random r mod pq. Encrypt r as re mod pq. Define k = H(r; re mod pq). “Data encapsulation mechanism”: Encrypt and authenticate m under AES-GCM key k. Authenticator catches any modification of re mod pq. Much easier to get right. Also generalizes nicely. P + Q: hash concatenation.

23

DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, etc. aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt an n-time secret key m; reuse m.

22

Shoup’s “KEM+DEM” view: encapsulation mechanism”:

• se random r mod pq.

Encrypt r as re mod pq. k = H(r; re mod pq). encapsulation mechanism”: Encrypt and authenticate under AES-GCM key k. Authenticator catches modification of re mod pq. easier to get right. generalizes nicely. : hash concatenation.

23

DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, etc. aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt an n-time secret key m; reuse m. DNSCurve: Server kno Client kno server’s public Client → packet containin where k E is authenticated q is DNS Server → packet containin where r

22

“KEM+DEM” view: psulation mechanism”: r mod pq. mod pq. re mod pq). encapsulation mechanism”: thenticate AES-GCM key k. tches

• f re mod pq.

get right. nicely. concatenation.

23

DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, etc. aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt an n-time secret key m; reuse m. DNSCurve: ECDH Server knows ECDH Client knows ECDH server’s public key Client → server: packet containing where k = H(cS); E is authenticated q is DNS query. Server → client: packet containing where r is DNS resp

22

view: mechanism”: . q). mechanism”: . d pq. concatenation.

23

DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, etc. aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt an n-time secret key m; reuse m. DNSCurve: ECDH for DNS Server knows ECDH secret k Client knows ECDH secret k server’s public key S = sG. Client → server: packet containing cG; Ek(0; where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response.

23

DEM security hypothesis: weak single-message version

• f security for secret-key

authenticated encryption. Chou: Is it safe to reuse k for multiple messages? Answer: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. (But need literature on this!) AES-GCM, Salsa20-Poly1305, etc. aim for full AE security goal. More complicated alternative: Use KEM+DEM to encrypt an n-time secret key m; reuse m.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response.

23

security hypothesis: single-message version security for secret-key authenticated encryption. Is it safe to reuse k ultiple messages? er: KEM+AE is safe; KEM+AE ⇒ KEM+“nDEM”. need literature on this!) AES-GCM, Salsa20-Poly1305, etc. r full AE security goal. complicated alternative: KEM+DEM to encrypt an secret key m; reuse m.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response. Client can across multiple but this Let’s assume

23

hypothesis: single-message version secret-key encryption. to reuse k messages? KEM+AE is safe; KEM+“nDEM”. literature on this!) Salsa20-Poly1305, etc. security goal. complicated alternative: to encrypt an ey m; reuse m.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response. Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time

23

version safe; DEM”. this!)

• ly1305, etc.

goal. alternative: encrypt an m.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response. Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”.

24

DNSCurve: ECDH for DNS Server knows ECDH secret key s. Client knows ECDH secret key c, server’s public key S = sG. Client → server: packet containing cG; Ek(0; q) where k = H(cS); E is authenticated cipher; q is DNS query. Server → client: packet containing Ek(1; r) where r is DNS response.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt.

24

DNSCurve: ECDH for DNS knows ECDH secret key s. knows ECDH secret key c, server’s public key S = sG. → server: containing cG; Ek(0; q) k = H(cS); authenticated cipher; DNS query. → client: containing Ek(1; r) r is DNS response.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt. Post-quantum “McEliece Client sends encapsulated Random random small public ke

24

ECDH for DNS ECDH secret key s. ECDH secret key c, ey S = sG. g cG; Ek(0; q) ); authenticated cipher; g Ek(1; r) response.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt. Post-quantum encrypted “McEliece KEM”: Client sends k = H encapsulated as Sc Random c ∈ F5413

2

random small e ∈ public key S ∈ F6960

2

24

DNS secret key s. key c, . (0; q)

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt. Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt.

25

Client can reuse c across multiple queries, but this leaks metadata. Let’s assume one-time c. KEM+AE view: Client is sending k = H(cS) encapsulated as cG. This is an “ECDH KEM”. Client then uses k to authenticate+encrypt. Server also uses k to authenticate+encrypt.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

.

25

can reuse c multiple queries, this leaks metadata. assume one-time c. KEM+AE view: is sending k = H(cS) encapsulated as cG. an “ECDH KEM”. then uses k authenticate+encrypt. also uses k authenticate+encrypt.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

. “NTRU

• bviously

Client sends encapsulated

25

c queries, metadata.

• ne-time c.

k = H(cS) cG. “ECDH KEM”. k authenticate+encrypt. k authenticate+encrypt.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

. “NTRU KEM”,

• bviously totally unrelated:

Client sends k = H encapsulated as Sc

25

S)

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

. “NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + encapsulated as Sc + e.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c.

26

Post-quantum encrypted DNS “McEliece KEM”: Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; random small e ∈ F6960

2

; public key S ∈ F6960×5413

2

. S has secret Goppa structure allowing server to decrypt. “Niederreiter KEM”, smaller: Client sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”.

26

• st-quantum encrypted DNS

“McEliece KEM”: sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random c ∈ F5413

2

; small e ∈ F6960

2

; key S ∈ F6960×5413

2

. secret Goppa structure wing server to decrypt. “Niederreiter KEM”, smaller: sends k = H(e; S′e) encapsulated as S′e ∈ F1547

2

.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”. Client → packet containin (Combine Server → packet containin

26

encrypted DNS KEM”: H(c; e; Sc + e) Sc + e.

5413;

∈ F6960

2

;

6960×5413 2

. Goppa structure to decrypt. M”, smaller: H(e; S′e) S′e ∈ F1547

2

.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”. Client → server: packet containing (Combine with ECDH Server → client: packet containing

26

DNS c + e) . structure decrypt. smaller: )

1547.

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”. Client → server: packet containing Sc+e; Ek (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r).

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r).

27

“NTRU KEM”,

• bviously totally unrelated:

Client sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small c; e ∈ (Z=q)[x]=(xn − 1); public key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. Server recovers 3sc + te, then te mod 3, then e, then c. Can imitate Niederreiter in the NTRU context: e.g. “Ring-LWR”.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r). r states a server address and the server’s public key. What if the key is too long to fit into a single packet? One simple answer: Client separately requests each block of public key. Can do many requests in parallel.

27

“NTRU KEM”,

• bviously totally unrelated:

sends k = H(c; e; Sc + e) encapsulated as Sc + e. Random small (Z=q)[x]=(xn − 1); key S ∈ (Z=q)[x]=(xn − 1). Secretly S = 3s=t; small s; t. recovers 3sc + te, e mod 3, then e, then c. imitate Niederreiter in the context: e.g. “Ring-LWR”.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r). r states a server address and the server’s public key. What if the key is too long to fit into a single packet? One simple answer: Client separately requests each block of public key. Can do many requests in parallel. Confidentialit Attacker can’t decrypt Integrity: Server never but Ek includes Attacker but can’t Attacker Availabilit Client disca continues eventually

27

unrelated: H(c; e; Sc + e) Sc + e. (xn − 1); Z=q)[x]=(xn − 1). =t; small s; t. 3sc + te, then e, then c. Niederreiter in the e.g. “Ring-LWR”.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r). r states a server address and the server’s public key. What if the key is too long to fit into a single packet? One simple answer: Client separately requests each block of public key. Can do many requests in parallel. Confidentiality: Attacker can’t guess can’t decrypt Ek(0 Integrity: Server never signs but Ek includes authentication. Attacker can send but can’t forge q o Attacker can repla Availability: Client discards forgery continues waiting fo eventually retransmits

27

unrelated: c + e) xn − 1). ; t. then c. the “Ring-LWR”.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r). r states a server address and the server’s public key. What if the key is too long to fit into a single packet? One simple answer: Client separately requests each block of public key. Can do many requests in parallel. Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request.

28

Client → server: packet containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) Server → client: packet containing Ek(1; r). r states a server address and the server’s public key. What if the key is too long to fit into a single packet? One simple answer: Client separately requests each block of public key. Can do many requests in parallel.

29

Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; r). Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request.

28

→ server: containing Sc+e; Ek(0; q). (Combine with ECDH KEM.) → client: containing Ek(1; r). states a server address the server’s public key. if the key is too long into a single packet? simple answer: separately requests block of public key. do many requests in parallel.

29

Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; r). Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request. Cookies What if E into same Client sends containing Server sends cookie r k) encrypted Server can Client sends Server recovers Server sends

28

g Sc+e; Ek(0; q). ECDH KEM.) g Ek(1; r). address public key. is too long single packet? er: requests public key. requests in parallel.

29

Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; r). Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request. Cookies What if Ek(0; q) do into same packet as Client sends short containing a cooki Server sends Ek(1; cookie r′: server state k) encrypted from Server can now forget Client sends packet Server recovers state, Server sends Ek(3;

28

k(0; q).

KEM.) ). . long parallel.

29

Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; r). Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request. Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to Server can now forget state. Client sends packet r′; Ek(2; Server recovers state, decrypts. Server sends Ek(3; r).

29

Confidentiality: Attacker can’t guess k, can’t decrypt Ek(0; q); Ek(1; r). Integrity: Server never signs anything, but Ek includes authentication. Attacker can send new queries but can’t forge q or r. Attacker can replay request. Availability: Client discards forgery, continues waiting for reply, eventually retransmits request.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r).

29

Confidentiality: er can’t guess k, decrypt Ek(0; q); Ek(1; r). Integrity: never signs anything, includes authentication. er can send new queries can’t forge q or r. er can replay request. Availability: discards forgery, continues waiting for reply, eventually retransmits request.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r). Client authentication Same strategy for protecting C → S, S isn’t special; many pack

29

guess k, (0; q); Ek(1; r). signs anything, authentication. send new queries

• r r.

replay request. forgery, aiting for reply, retransmits request.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r). Client authentication Same strategy works for protecting connections. C → S, S → C data isn’t special; reuse many packets each

29

(1; r). anything, authentication. queries request. , request.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r). Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

30

Cookies What if Ek(0; q) doesn’t fit into same packet as Sc + e? Client sends short Ek(0; q′) containing a cookie request q′. Server sends Ek(1; r′) containing cookie r′: server state (including k) encrypted from server to itself. Server can now forget state. Client sends packet r′; Ek(2; q). Server recovers state, decrypts. Server sends Ek(3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client.

30

• kies

if Ek(0; q) doesn’t fit same packet as Sc + e? sends short Ek(0; q′) containing a cookie request q′. sends Ek(1; r′) containing

• kie r′: server state (including

encrypted from server to itself. can now forget state. sends packet r′; Ek(2; q). recovers state, decrypts. sends Ek(3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client. Solution to avoid Imitate NFS,

30

doesn’t fit et as Sc + e? rt Ek(0; q′)

• kie request q′.

(1; r′) containing server state (including from server to itself. forget state. packet r′; Ek(2; q). state, decrypts. (3; r).

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client. Solution 2: Redo p to avoid state on server. Imitate NFS, not HTTP

30

fit e? ) request q′. containing (including to itself. state. (2; q). decrypts.

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client. Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP.

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP.

31

Client authentication Same strategy works for protecting connections. C → S, S → C data flow isn’t special; reuse k for many packets each direction. Another TCP availability problem: server allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers

• nly after client sends r′.

Solution 1: Hashcash from client.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. Server can authenticate client without signatures, same way client authenticates server:

• Send to client’s public key

encapsulation of new key k′.

• Hash k′ into shared secret.

31

authentication strategy works rotecting connections. , S → C data flow special; reuse k for packets each direction. Another TCP availability problem: allocates buffers for each connection; runs out of memory. Semi-solution: Allocate buffers after client sends r′. Solution 1: Hashcash from client.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. Server can authenticate client without signatures, same way client authenticates server:

• Send to client’s public key

encapsulation of new key k′.

• Hash k′ into shared secret.

Big keys McEliece for long-t Is this size Do we need lower-confidence such as NTRU Size of average in Alexa Web page public ke but public can be reused

31

authentication

• rks

connections. data flow reuse k for each direction. ailability problem: buffers for each

• ut of memory.

Allocate buffers sends r′. Hashcash from client.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. Server can authenticate client without signatures, same way client authenticates server:

• Send to client’s public key

encapsulation of new key k′.

• Hash k′ into shared secret.

Big keys McEliece public key for long-term confidence Is this size a problem Do we need to switch lower-confidence app such as NTRU or QC- Size of average web in Alexa Top 1000000: Web page often needs public keys for several but public key for can be reused for many

31

connections. direction. roblem: each memory. buffers client.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. Server can authenticate client without signatures, same way client authenticates server:

• Send to client’s public key

encapsulation of new key k′.

• Hash k′ into shared secret.

Big keys McEliece public key is 1MB for long-term confidence toda Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages.

32

Solution 2: Redo protocols to avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. Server can authenticate client without signatures, same way client authenticates server:

• Send to client’s public key

encapsulation of new key k′.

• Hash k′ into shared secret.

33

Big keys McEliece public key is 1MB for long-term confidence today. Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages.

32

Solution 2: Redo protocols avoid state on server. Imitate NFS, not HTTP. Solution 3 for, e.g., SSH: Authenticate client. can authenticate client without signatures, same way authenticates server: to client’s public key encapsulation of new key k′. k′ into shared secret.

33

Big keys McEliece public key is 1MB for long-term confidence today. Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages. Most imp

• n reuse

switching and prom Rationale: subsequent doesn’t allo e.g. Microsoft switches Safer: new Easier to new key

32

Redo protocols

• n server.

not HTTP. e.g., SSH: client. authenticate client signatures, same way authenticates server: client’s public key

• f new key k′.

shared secret.

33

Big keys McEliece public key is 1MB for long-term confidence today. Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages. Most important limitation

• n reuse of public

switching to new k and promptly erasing Rationale: “forward subsequent theft of doesn’t allow decryption. e.g. Microsoft SChann switches keys every Safer: new key every Easier to implement: new key every connection.

32

cols client ay server: ey ey k′. secret.

33

Big keys McEliece public key is 1MB for long-term confidence today. Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages. Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old k Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection.

33

Big keys McEliece public key is 1MB for long-term confidence today. Is this size a problem? Do we need to switch to lower-confidence approaches such as NTRU or QC-MDPC? Size of average web page in Alexa Top 1000000: 1.8MB. Web page often needs public keys for several servers, but public key for a server can be reused for many pages.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection.

33

eys McEliece public key is 1MB long-term confidence today. size a problem? need to switch to er-confidence approaches as NTRU or QC-MDPC?

• f average web page

Alexa Top 1000000: 1.8MB. age often needs keys for several servers, public key for a server reused for many pages.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection. What is a new key If server key gen, client encrypts server decrypts.

33

key is 1MB confidence today. roblem? switch to approaches r QC-MDPC? web page 1000000: 1.8MB. needs several servers, r a server r many pages.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection. What is the performance a new key every minute? If server makes new key gen, ≤1 per minute; client encrypts to new server decrypts.

33

1MB today. roaches MDPC? 1.8MB. servers, pages.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection. What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection.

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts.

34

Most important limitation

• n reuse of public keys:

switching to new keys and promptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer doesn’t allow decryption. e.g. Microsoft SChannel switches keys every two hours. Safer: new key every minute. Easier to implement: new key every connection.

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair.

34

important limitation reuse of public keys: switching to new keys romptly erasing old keys. Rationale: “forward secrecy”— subsequent theft of computer esn’t allow decryption. Microsoft SChannel switches keys every two hours. new key every minute. to implement: ey every connection.

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair. How does encrypt to without

34

limitation public keys: keys erasing old keys. ard secrecy”—

• f computer

decryption. SChannel every two hours. every minute. implement: connection.

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair. How does a stateless encrypt to a new client without storing the

34

keys. secrecy”— computer hours. minute.

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair. How does a stateless server encrypt to a new client key without storing the key?

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair.

36

How does a stateless server encrypt to a new client key without storing the key?

35

What is the performance of a new key every minute? If server makes new key: key gen, ≤1 per minute; client encrypts to new key; server decrypts. If client makes new key: client has key-gen cost; server has encryption cost; client has decryption cost. Either way:

• ne key transmission for each

active client-server pair.

36

How does a stateless server encrypt to a new client key without storing the key? Slice McEliece public key so that each slice of encryption produces separate small output. Client sends slices (in parallel), receives outputs as cookies, sends cookies (in parallel). Server combines cookies. Continue up through tree. Server generates randomness as secret function of key hash. Statelessly verifies key hash.