State of Crypto in Python


Published on

Python has a complex past with cryptography. There are half a dozen major frameworks built on at least three separate C implementations, each with their own strengths and weaknesses and in various states of maintenance. In our development of an open source key management system for OpenStack (Barbican), our team has spent time investigating the major options. This presentation will review the current state of the art and discuss the future of crypto in Python including a new library being developed by a group of Python devs aimed at unifying and expanding the support for modern crypto in the Python ecosystem.

Published in: Software
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

State of Crypto in Python

  1. 1. StateofcryptoinPythonA library created by people who make poor life choices.
  2. 2. WhatDoWeWant Algorithm support Open Source MAINTAINED & Tested Python Support Trust
  3. 3. WHyc? All major cryptographic libraries are currently implemented in a low level language, mostly C or C++. Reviewed Code Several C libraries have been sponsored through the review process for professional crypto review including various compliances that some customers care about. Future possibilities There are some exciting options for future work in the crypto space with languages like Rust / Go. Unfortunately, these aren’t usable from Python right now. Timing / Memory Attacks These attacks relate to exploiting timing differentials or securely wiping memory. They are difficult or impossible to remediate without the low level control exposed by C. Existing Code Writing good crypto code is hard. Most existing libraries have a long history including significant bug-fixing / research.
  4. 4. StateofC OSS X-Platform Maintained Ubiquitous Std. Algorithms FIPS OpenSSL NSS NaCl Botan CommonCrypto MS CSP Libgcrypt
  5. 5. StateOfPython Backend Maintained Python Support Reviewed Completeness m2crypto openssl recently active pypy with patch, no py3 no openssl swig pycrypto bespoke low no pypy no no AEAD (without alpha) pyopenssl openssl* yes yes (with crypto) no Thin openssl bindings python-nss NSS low unknown no exposes most of NSS botan botan yes py3, maybe pypy no exposes most of botan Most of these libraries require / assume the user understands how to use the underlying C library correctly.
  6. 6. Do we need another Python library?
  7. 7. Why a new crypto library for Python? •  Lack of maintenance. •  Use of poor implementations of algorithms (i.e. ones with known side-channel attacks). •  Lack of high level, “Cryptography for humans”, APIs. •  Absence of algorithms such as AES-GCM and HKDF. •  Poor introspectability, and thus poor testability. •  Extremely error prone APIs, and bad defaults. •  Lack of PyPy and Python 3 support. Introducing cryptography Grandiose Vision: A cryptographic standard library for Python.
  8. 8. ourPeople Alex Gaynor (Alex_gaynor) Paul Kehrer (reaperhulk) David Reid (dreid) Alex Stapleton (alexs) Aryx, Jarret Raim (jraim), Donald Stufft (dstufft), cyli, Mohammed Attia (skeuomorf), Jean-Paul Calderone (exarkun), Hynek Schlawack (hynek), Julian Krause (juliankrause), Richard Wall (wallrj), Matt Iverson (lvoz), Chris Glass (chrisglass), Laurens Van Houtven (lvh), Konstantinos Koukopoulos (kouk), koobs, Christian Heimes (tiran), fedor-brunner, Kyle Kelley (rgbkrk), jgiannuzzi, manuels, Wouter Bolsterlee (wbolster), Arturo Filasto (hellais), Stephen Holsapple (sholsapp), Marcin Wielgoszewski (mwielgoszewshi), Jay Parlar (parlarjb)
  9. 9. TheStructure Bindings Hazmat Recipes
  10. 10. Backends OpenSSL Our primary (and only guaranteed) backend. We don’t currently package OpenSSL to allow for flexibility for package maintainers. Common Crypto Available on OS X and iOS, this is the preferred backend on OS X. Apple has decided not to ship newer version of OpenSSL, leaving developers with a old version lacking modern algorithms. Cryptography is designed around the concept of backends. Each backend implements a set of defined interfaces. This allows us to implement a backend for each C library and exchange them transparently. MULTIBACKEND This meta-backend allows composition and prioritization of multiple backends. This creates a superset of operations in Python, isolating the developer from variations in C libraries. Moar! Any C backend can be included. We have spoken with many of the C library maintainers about writing a backend for cryptography.
  11. 11. Tests per run Testify 66,144 500+ Million tests per week 77 Runs per build 5,093,088 Tests per build 15 Builds per day 45 Documentation runs per day
  12. 12. currentSupport Symmetric Currently support a variety of common ciphers such as AES, Camellia, 3DES, CAST5, etc. Most non-patent encumbered block cipher modes are also supported. HMAC HMAC using any supported hash algorithm. Supports constant time verification. Key Derivation Functions PBKDF2HMAC, HKDF One Time Password TOTP, HOTP RSA SIGNING AND VERIFICATION Supports PKCS#1 v1.5 padding and Probabilistic Signature Scheme (using MGF1 with user-definable hash) fernet A high level recipe designed to provide easy to use authenticated encryption. ??? Any C backend can be included. We have had preliminary talks with various maintainers about moving into cryptography and PyOpenSSL 0.14+ depends on our project.
  13. 13. LetsReview Algorithm support Open Source MAINTAINED & Tested Python Support Multi-Backend & Openssl Apache 2 500+ Million Tests 30+ contributors 2.6, 2.7, 3.2, 3.3, 3.4, & pypy
  14. 14. FutureWork DSA signing/verification Defaulting to deterministic k Asymmetric Key loading PKCS1, PKCS8, JWK RSA Encryption/Decryption PKCS1 v1.5, OAEP X509/TLS? Proper hostname validation, TLS 1.2, modern ciphersuites Less Common Symmetric Primitives Chacha20, Salsa20 Github Website Install pip install cryptography
  15. 15. ~ fin ~