Today I had the pleasure of talking on stage for ~2 minutes at the Real World Crypto 2016 conference in Stanford, CA. This is a pseudotranscript of that lightning talk.
I'm Mahmoud Hashemi and I work as a Lead Developer at PayPal. I mostly focus on Python frameworks and software infrastructure, but for the last couple years I've been working on Application Security. In fact, my first assignment, back in late 2012, was reverse engineering and reimplementing Max Levchin's Certicom elliptic curve integration, in Python.
These days I work on PayPal's comprehensive key management (and HSM integration) system. Suffice to say, we work a lot with encryption and secure sockets. Also suffice to say, we're a bit nervous about OpenSSL. With all the news lately we've started design discussions with regard to how we can hedge our OpenSSL bets.
In Python, this translates to a DBAPI 2.0-like abstraction layer to enable swapping out security implementations. Like many ORMs (e.g., SQLAlchemy), but for security. Honestly, there are usually better/more reasons to switch SSL implementations than relational databases. We want an API that allows us to leverage other great SSL implementations, including OpenSSL-derivatives like LibreSSL, as well as other implementations like WolfSSL. PayPal already has a diverse SSL ecosystem, with multiple versions of OpenSSL and tons of JVM-based implementations, making it a great testbed ecosystem.
To achieve this we're hoping to have some productive discussions with the experienced engineers and cryptographers that attend RWC. It's still very early days, and there are a lot of corner cases, so we'll need all the advice we can get. Help us invest in the algorithms, not the implementations. Design for replaceability, to avoid having 17-year-old libraries serving today's security-hungry Internet. You can contact me at github.com/mahmoud, twitter.com/mhashemi, or email@example.com.
A partially obfuscated view from the stage of RWC2016