Pretzel: Email encryption and provider-supplied functions are compatible

December 13, 2016 Β· Declared Dead Β· πŸ› Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication

πŸ‘» CAUSE OF DEATH: Ghosted
No code link whatsoever

"No code URL or promise found in abstract"

Evidence collected by the PWNC Scanner

Authors Trinabh Gupta, Henrique Fingler, Lorenzo Alvisi, Michael Walfish arXiv ID 1612.04265 Category cs.CR: Cryptography & Security Citations 28 Venue Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication Last Checked 4 months ago
Abstract
Emails today are often encrypted, but only between mail servers---the vast majority of emails are exposed in plaintext to the mail servers that handle them. While better than no encryption, this arrangement leaves open the possibility of attacks, privacy violations, and other disclosures. Publicly, email providers have stated that default end-to-end encryption would conflict with essential functions (spam filtering, etc.), because the latter requires analyzing email text. The goal of this paper is to demonstrate that there is no conflict. We do so by designing, implementing, and evaluating Pretzel. Starting from a cryptographic protocol that enables two parties to jointly perform a classification task without revealing their inputs to each other, Pretzel refines and adapts this protocol to the email context. Our experimental evaluation of a prototype demonstrates that email can be encrypted end-to-end \emph{and} providers can compute over it, at tolerable cost: clients must devote some storage and processing, and provider overhead is roughly 5 times versus the status quo.
Community shame:
Not yet rated
Community Contributions

Found the code? Know the venue? Think something is wrong? Let us know!

πŸ“œ Similar Papers

In the same crypt β€” Cryptography & Security

Died the same way β€” πŸ‘» Ghosted