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.
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.
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.
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. 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)
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. 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. 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. 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. 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
github.com/pyca/cryptography
Website
cryptography.io
Install
pip install cryptography
