implement symmetric encryption

[chadwhitacre]

⬑ #3994

⬑ #3976

← #4004 — #3999 →

Punchlist

• rebase on master once identity preliminaries #4004 lands
• fix typo in comment—implement symmetric encryption #3998 (comment) —done in 2a6bbd4
• audit Fernet—implement symmetric encryption #3998 (comment)
• audit cryptography—implement symmetric encryption #3998 (comment)
• sort out key policies
• comment config knob—implement symmetric encryption #3998 (comment) —done in 34ba9cd
• simplify EncryptingPacker init API—implement symmetric encryption #3998 (comment) —addressed at implement symmetric encryption #3998 (comment)
• test decryption with old key—implement symmetric encryption #3998 (comment) —done in 5ce0ff8

[rohitpaulk]

Rebased on master, previous head was @4a1097b8a007bb2e7256aa3d57a9539e182454a9

[chadwhitacre]

Alright! This one's up—and it's the big one!

@rohitpaulk @aandis et al. What do we think of our encryption procedure here?

[chadwhitacre]

cc: @gratipay/security @TheHmadQureshi

[chadwhitacre]

Rebased again (post deploy of #4004), previous head was 08b3490.

[chadwhitacre]

Frenet → Fernet

[chadwhitacre]

Do we trust Fernet? Do we trust cryptography?

[chadwhitacre]

Bottom of https://cryptography.io/en/latest/:

cryptography has not been subjected to an external audit of its code or documentation. If you’re interested in discussing an audit please get in touch.

[chadwhitacre]

Investigations

Fernet

• What's up with Fernet's versioning? Is the version unambiguous? fernet/spec#14
• Why does Fernet exist? Why Fernet? fernet/spec#15
• Read all issues and PRs on Fernet.
• Understand Fernet.

cryptography

• Skim open issues and PRs.
• Is Fernet appropriate for our use case? implement symmetric encryption #3998 (comment)
• Review cryptography's Fernet implementation:
  • What version of Fernet does cryptography implement? better specify Fernet version pyca/cryptography#2899
  • Why does cryptography use Fernet? justify Fernet pyca/cryptography#2900
  • Read all the relevant issues and PRs (initial PR: [WIP][POC] Implement Fernet pyca/cryptography#203).
  • Review code.

Etc.

• should we be using a password? implement symmetric encryption #3998 (comment)
  • no: implement symmetric encryption #3998 (comment)
• how are we going to do key rotation?
• should we have more than one key? cf. implement symmetric encryption #3998 (comment)
  • No, not now. implement symmetric encryption #3998 (comment)
• What version of OpenSSL are we going to use?implement symmetric encryption #3998 (comment)
  • Whatever Heroku gives us: implement symmetric encryption #3998 (comment).
• Are we going to audit it? implement symmetric encryption #3998 (comment)
  • No: implement symmetric encryption #3998 (comment).
• Are we going to audit cryptography's dependencies implement symmetric encryption #3998 (comment)
  • No: implement symmetric encryption #3998 (comment).
• Should we use RSA? implement symmetric encryption #3998 (comment)
  • No: implement symmetric encryption #3998 (comment)

[chadwhitacre]

I noticed a security-hardening label on cryptography with three tickets. Two are not blockers for us (one, two), and the third is also covered by a search for fernet.

[chadwhitacre]

Basically we need to decide if we're going to trust a) Fernet, and b) cryptography's implementation of Fernet.

[chadwhitacre]

cryptography has a mailing list in addition to GitHub issues. We'll need to dig there, too, probably especially for the "why" about fernet.

[chadwhitacre]

Fernet looks like a rinky-dink operation. It has 44 stars and 7 forks and approximately one contributor.

[chadwhitacre]

The author doesn't mention fernet on his blog and barely on twitter. In fact:

Then I’ll continue to think fernet is a bad format shrug

https://twitter.com/dstufft/status/437363105228939264

Hmmm ...

[chadwhitacre]

Other end of that Twitter convo suggests that Fernet comes from Heroku (where kr works):

Nice callout to Fernet by @/alex_gaynor in his #PyTN2014 keynote which was adapted from @/heroku’s Ruby Fernet

https://twitter.com/craigkerstiens/status/437352536303874048

P.S. Should I/we be @mention'ing folks here? Would that be spam or transparency?

[chadwhitacre]

I mean, PyCA advertises their interest in third-party audits.

[chadwhitacre]

Searching fernet is not so helpful ;-) , but heroku fernet turns up some hits:

• https://twitter.com/search?f=tweets&vertical=default&q=heroku%20fernet&src=typd
• https://www.google.com/search?q=heroku+fernet

[chadwhitacre]

"I don't have any issues with the code [on this PR], it seems simple enough. The only problem is this Fernet—how secure and reliable it is." —@kaguillera

[chadwhitacre]

I've started a doc on credential management: gratipay/inside.gratipay.com#606.

[chadwhitacre]

In a secure system, Alice and Mallory’s records probably wouldn’t be encrypted using the same key. [p 57]

#3998 (comment)

Transaction level key: In this practice, each transaction is encrypted with its own unique key, leading to higher level of data breach mitigation.

#3998 (comment)

I don't see how we would do this apart from a key management application such as StrongAuth or Porticor, and I think that's something to reticket and tackle further down the line.

[chadwhitacre]

https://en.wikipedia.org/wiki/Key_management

[chadwhitacre]

All tax forms are well protected because they are encrypted with RSA 2048-bit encryption.

https://www.reddit.com/r/patreon/comments/3tofi7/patreon_hacked_now_someone_is_threatening_to_leak/cx84dir

Hmmm ... I was wondering about that: should we be using asymmetric encryption? Web app encrypts, other processes decrypt?

[chadwhitacre]

I did some spelunking in the Patreon data dump. They do appear to have used RSA. While their implementation does have API for both encrypting and decrypting, I don't see that they do actually decrypt anywhere in the web application. This makes it possible for them to distribute a public key with the application, and keep the private key completely separate.

This works for their model, where all creators have a direct relationship with Patreon. On Gratipay we're facilitating a relationship between a ~user and a Team, which is an organization other than Gratipay. We need to be able to communicate full identity information from the ~user to the Team (e.g., W-9 in the U.S.), and vice versa. In order to do that, we need to be able to decrypt within the application, so even if we used asymmetric encryption, we wouldn't be able to keep the private key entirely away from the web app.

[chadwhitacre]

Okay! The investigations and punchlist items are all checked off. I'm pretty sure that means that this is ready for final review and merge. 😳

Who is going to be brave enough? @rohitpaulk? @aandis?

[chadwhitacre]

There's a bottle of fernet here at Stack, waiting to celebrate ...

[rohitpaulk]

Can't this be simplified to just take *keys?

[rohitpaulk]

Hmm, maybe this was done to emphasize the answer to https://github.com/gratipay/gratipay.com/pull/3998/files#r62548400?

[chadwhitacre]

Yeah, that's more or less what I was thinking. I wanted to differentiate between the first key, which is the one used for encryption (and decryption), and the old keys, which can only be used for decryption.

[rohitpaulk]

This looks fine to me overall - I've left a few comments regarding how multiple keys will be handled, would be great if we could have more tests for that

[chadwhitacre]

Awesome, thanks! I've updated the punchlist in the description, and will get another commit or two together here ...

[chadwhitacre]

@rohitpaulk Punchlist updated with responses, I'll let you check them off if you approve. :)

[aandis]

!m @whit537 @rohitpaulk

[chadwhitacre]

Ooooooh wow. Oh wowohwowohwow. 😳

Here we go!

!m @rohitpaulk @kaguillera @aandis *

[dannluciano]

@whit537 thanks for this nice search report about symmetric encryption.