Cryptography and Security: The Narrow Road from Theory to Practice

1. Cryptography and Security: The Narrow Road from Theory to Practice Burt Kaliski, RSA SecurityISPEC 2006, Hangzhou, ChinaApril 13, 2006

2. Introduction • Many research results in cryptography over the past 30 years • Few have made it from theory into practice • What’s worked well? • What hasn’t? • Why not, and what researchers can do about it

3. From Theory to Practice • Not every idea will make it into practice, of course • “Innovation funnel” suggests that only a few ideas survive the necessary testing • Thomas A. Edison: Genius is one per cent inspiration and ninety-nine per cent perspiration. • Goal: Increase likelihood that a good idea in cryptography will actually be applied

4. Some ObservationsExamples from “Practice & Experience” • What’s worked well and • What hasn’t • NB: “Worked well” doesn’t mean it was brought into practice perfectly, and “hasn’t” doesn’t mean it wasn’t brought into practice at all. But some good ideas have found their way into practice much more easily than others.

5. What’s Worked Well • Basic public-key cryptography • PKCS #1 v1.5 RSA • discrete log. systems (Diffie-Hellman, DSA) • elliptic curve cryptography

6. What Hasn’t • Public-key enhancements and variations • RSA-OAEP, -PSS, -KEM • Cramer-Shoup schemes • provable security in standard model, but … • various zero-knowledge versions • other public-key families, e.g., NTRU

7. What’s Worked Well • Basic digital signatures • sign + verify

8. What Hasn’t • Special digital signatures • blind, group, designated confirmer … • Direct Anonymous Attestation is a potential exception

9. What’s Worked Well • Advanced Encryption Standard and Triple-DES • culminating many years of research on DES replacements

10. What Hasn’t • Stream ciphers • other than RC4 … • Modes of operation • other than basic four (or five)

11. What’s Worked Well • HMAC message authentication • Hash (K1 || Hash (K2 || M))

12. What Hasn’t • Many other “fast” MACs • Incremental message authentication

13. What’s Worked Well • Shamir secret sharing • k of n for root keys

14. What Hasn’t • Secret sharing with other access structures • Distributed cryptography • Secure multi-party computation

15. What’s Worked Well • Password hashing • Hash (password + salt)

16. What Hasn’t • Password-authenticated key establishment • aka “zero-knowledge” password protocols

17. What’s Worked Well • SSL-protected e-commerce • server PKI • session key establishment • session encryption

18. What Hasn’t • Digital cash • Secure auctions • Electronic voting

19. What’s Worked Well • Montgomery multiplication • ARn * BRn ABRn

20. What Hasn’t • Karatsuba-Ofman multiplication • AHBH, ALBL, (AH+AL)(BH+BL), recursively

21. What’s Worked Well • Side-channel implementation countermeasures • protection for basic RSA, ECC, AES, etc.

22. What Hasn’t • Intrusion-resilient cryptography • alternatives to RSA, ECC, AES, etc. that are less vulnerable by design

23. What’s Worked Well • Software codebreaking • distributed key search and integer factorization

24. What Hasn’t • Hardware codebreaking • e.g., factoring circuits • “Deep Crack” for DES is a notable exception

25. Why Not? • “Not secure enough” • “Too many choices” • “No clear advantage” • “Too complicated” • “Not practical”

26. “Not Secure Enough” • New ideas in cryptography often need a long period of testing before others are confident to adopt them • In many cases not enough people are even looking at the idea • Expectations keep increasing based on experience with previous ideas • Example: NTRU based on a new problem, and also held to a much higher standard than, say, RSA • Tight reductions from known problems against broad adversaries gives the most confidence • But ideas based on new problems are also needed!

27. “Too Many Choices” • Research in an area can often result in a multiplicity of choices, none of which has enough support to move ahead of the rest • Results build on one another, and it may not be clear when a result is finally “stable” • Example: New modes of operation for block ciphers are numerous, though gradually being standardized • Competitions can help bring a research area to conclusion and enable a few good choices to advance

28. “No Clear Advantage” • New ideas, though good, may not be enough better than methods that are already available to justify the cost of making the change • Long-term assurances not as appreciated in the short term • Cost of introducing a new technology can be very significant, especially when it depends on industry standards • Example: RSA-PSS, -KEM provide long-term assurances, but require upgrades to existing systems • Transition planning can help phase in a new idea while still supporting available methods • New applications generally a better target than existing ones

29. “Too Complicated” • Some new ideas are just too “different” for designers to work with, especially in terms of business models and use cases • Example: distributed cryptography requires a non-hierarchical “workflow” that’s not usually found in applications • Reference implementations that enable new applications and hide the technical details can facilitate adoption • e.g., RSAREF and PGP for public-key cryptography

30. “Not Practical” • And for some ideas, the time has not yet come — other technologies may need to advance or be developed • Example: general secure multiparty computation is still computationally burdensome • Even public-key crypto was challenged in its early days! • Patience may be called for, and there’s plenty of time to improve the theory and speculate on future applications in the meantime

31. Conclusions • Researchers whose goal is to have the results of their research applied need to think about technology transfer • Results are still important even if not applied directly, since they advance the science in general • But better security depends on good research being put into practice • Hopefully these experiences will help more good ideas move through that narrow road

32. Contact Information • Burt KaliskiChief Scientist, RSA LaboratoriesVice President of Research, RSA Securitybkaliski@rsasecurity.comhttp://www.rsasecurity.com/rsalabs