Thoughts on Rust Cryptography

4131d2f57a0db2a2b4d9a62bd389fd44?s=47 tarcieri
December 19, 2014

Thoughts on Rust Cryptography

4131d2f57a0db2a2b4d9a62bd389fd44?s=128

tarcieri

December 19, 2014
Tweet

Transcript

  1. 2.
  2. 3.
  3. 4.
  4. 5.

    This Talk • 2014: This year in cryptography • Is

    Rust a good language for crypto? • Survey of the Rust crypto landscape • A Rust common crypto library • Measuring timing variability in Rust
  5. 7.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3: “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel)
  6. 8.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) BITES AGAIN!!!
  7. 9.
  8. 10.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
  9. 11.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
  10. 13.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) SSL/TLS Design Flaws
  11. 14.

    • Java: Bleichenbacher OOB MitM (JCE) • Apple: “goto fail”

    MitM (SecureTransport) • GNUTLS: “goto cleanup” MitM • OpenSSL: “Heartbleed” Memory Exposure • TLS: Triple-Handshake MitM • NSS: “BERserk” MitM (Firefox/Chrome) • SSLv3 (and TLS): “POODLE” ciphertext recovery • Microsoft: “Winshock” RCE (SChannel) C is a crappy language
  12. 42.
  13. 43.
  14. 49.

    Things that might help • Dead code detection • Mandatory

    braces • Automatic resource management • No goto statement • true/false (and better ways of handling errors) • Memory safety
  15. 51.

    Things Rust has • Dead code detection • Mandatory braces

    • Automatic resource management • No goto statement • true/false (and better ways of handling errors) • Memory safety
  16. 58.
  17. 60.

    — Nadhem J. AlFardan and Kenneth G. Paterson "In this

    sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form. However, it is a truism that attacks only get better with time, and we cannot anticipate what improvements to our attacks, or entirely new attacks, may yet be discovered."
  18. 64.

    Cryptocoding.net Rules • Compare secret strings in constant time •

    Avoid branchings controlled by secret data • Avoid table look-ups indexed by secret data • Avoid secret-dependent loop bounds • Prevent compiler interference with security-critical operations • Prevent confusion between secure and insecure APIs • Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer • Use unsigned bytes to represent binary data • Use separate types for secret and non-secret information • Use separate types for different types of information • Clean memory of secret data • Use strong randomness
  19. 65.

    Constant Time Operation • Compare secret strings in constant time

    • Avoid branchings controlled by secret data • Avoid table look-ups indexed by secret data • Avoid secret-dependent loop bounds
  20. 67.

    Clear Abstractions • Prevent confusion between secure and insecure APIs

    • Avoid mixing security and abstraction levels of cryptographic primitives in the same API layer
  21. 68.

    Types! • Use unsigned bytes to represent binary data •

    Use separate types for secret and non-secret information • Use separate types for different types of information
  22. 73.
  23. 74.
  24. 85.
  25. 87.

    libsodium • Portable repackaging of the Networking and Cryptography Library

    (NaCl a.k.a. “salt”) • Includes Ed25519 and ChaCha20 • Includes the scrypt password hashing function • Includes the Blake2 hash function • Includes SipHash • Some optional libsodium-specific utility functions
  26. 89.
  27. 91.

    rust-crypto • Promising start! • Some good implementations • Some

    questionable implementations • Sometimes they’re the same!
  28. 96.
  29. 101.

    rust-crypto tl;dr • Good effort! • No immediate security problems

    on cursory inspection • Clear signs the code has not been well-reviewed • Needs more expert scrutiny to be trusted
  30. 103.

    Protect Keys! • mprotect! PROT_NONE guard pages • mlock! prevents

    keys from being swapped out • volatile zero on drop
  31. 105.
  32. 106.

    Warning: While this library tries to avoid branches or input-dependent

    memory operations, the code optimizer may reintroduce them and you should carefully verify the assembly in order to use this.
  33. 108.
  34. 110.
  35. 111.
  36. 115.
  37. 117.
  38. 121.
  39. 122.
  40. 125.
  41. 130.

    Rust Common Crypto • Handle zeroing buffers on drop •

    Protected buffers for keys (ala TARS) • Traits! Traits! Traits! • Constant-time primitives (ala Nadeko)
  42. 135.

    Common crypto library • Common foundation for all crypto libraries

    • Solve unsafe concerns in one place • Solve constant-time operation in one place • Promote interoperability
  43. 138.

    Modern CPU • Example clock speed: 2.5 GHz • 2,500,000,000

    CPU cycles per second • 0.4 nanoseconds per cycle • 400 picoseconds per cycle
  44. 144.

    Cyclometer • Automated testing for data-dependent timing variability in Rust

    cryptographic libraries • Use RDTSC to measure timing • Collect a large number of samples and apply statistical test (e.g. Box Test) to determine if timing variability is distinguishable
  45. 148.

    Final thoughts • Rust has immense potential for cryptography but

    we must tread carefully • Rust code without any branches isn’t necessarily constant time. Beware LLVM! • Stick with wrappers to mainstream crypto libraries until pure Rust crypto is more mature