How to talk to cryptographers
Not currently scheduled.
Presented by
-
Dan Shearer
https://cv.shearer.org/w/CV_List_View
Dan Shearer has been involved in Open Source since before it had the name, leading on to his interests in digital human rights. His career in open source projects started with Samba and related projects, and includes embedded, real-time, virtualisation and simulation codebases. LumoSQL is his current project, embedding a new form of data security called Lumions into the standard SQLite database used by billions of people. Lumions use Attribute-based Encryption to store permissions such as read, modify, delete etc into the data, and LumoSQL makes every row in a database into a Lumion. In addition, the team is working on a way of adding a timestamp as a reliable permission to Lumions.
Dan Shearer
https://cv.shearer.org/w/CV_List_View
Abstract
In 2019 I needed to implement encryption to solve a new class of problem. Encryption implementations often go very wrong, and this is the story so far of how I learned about design, and how to talk to cryptographers. Encryption designed for the 21st century is not common, and yet is required to implement privacy.
At linux.conf.au 2020, I presented an overview of a very young project to "implement better encryption in SQL databases". Pretty soon some open source people joined in, and we started analysing the problem. We could study a lot of open source applications that implement encryption, and many encryption libraries exist that have been exhaustively reviewed. Surely, I thought, a team of talented programmers can take good security advice and "use existing components?" But no.
And so I learned:
* The culture of software developers is to use the *least amount* of the *least advanced* encryption possible
* Encryption is almost always used for security, with privacy left to either application logic or human behaviour
* A cryptographer is a made-up animal like a platypus: part computer scientist, part mathematician, part security engineer, part academic
* A cryptography team is needed to do cryptography. Some people more mathematical, some more security, some more implementation and test, etc
* Some really capable encryption systems have been invented, peer reviewed and deployed in the 21st century. They are not widely used
* The psychology of privacy and security is not what cryptographers do. Perhaps that is why advanced systems are so rarely seen
Takeaways from this talk:
* What is missing by design: how most secure systems cannot use encryption to implement privacy because they are not designed to
* What goes wrong with culture: how expectations, perceptions, ecosystem management and economic incentives keep applications stuck in the 20th century
* Technical details of my comical early attempts to use GnuPG, OpenSSL and other pieces to create Role-based access for flat files
* How decades-old cryptographic work in zero-knowledge proofs helps in 2023
* How a Key Sharding system from 1979 might be safe in some narrow cases, and we might have one of those cases, but analysing cryptography applications is difficult
* Examples of production open source codebases implement modern cryptography for access control in 2023
* The ideas and code we have so far for enforcing privacy and secure access control within the data, callable via SQL
* How we hope to roll out solutions to very large numbers of people, since in our view most privacy violations start on the mobile
In 2019 I needed to implement encryption to solve a new class of problem. Encryption implementations often go very wrong, and this is the story so far of how I learned about design, and how to talk to cryptographers. Encryption designed for the 21st century is not common, and yet is required to implement privacy. At linux.conf.au 2020, I presented an overview of a very young project to "implement better encryption in SQL databases". Pretty soon some open source people joined in, and we started analysing the problem. We could study a lot of open source applications that implement encryption, and many encryption libraries exist that have been exhaustively reviewed. Surely, I thought, a team of talented programmers can take good security advice and "use existing components?" But no. And so I learned: * The culture of software developers is to use the *least amount* of the *least advanced* encryption possible * Encryption is almost always used for security, with privacy left to either application logic or human behaviour * A cryptographer is a made-up animal like a platypus: part computer scientist, part mathematician, part security engineer, part academic * A cryptography team is needed to do cryptography. Some people more mathematical, some more security, some more implementation and test, etc * Some really capable encryption systems have been invented, peer reviewed and deployed in the 21st century. They are not widely used * The psychology of privacy and security is not what cryptographers do. Perhaps that is why advanced systems are so rarely seen Takeaways from this talk: * What is missing by design: how most secure systems cannot use encryption to implement privacy because they are not designed to * What goes wrong with culture: how expectations, perceptions, ecosystem management and economic incentives keep applications stuck in the 20th century * Technical details of my comical early attempts to use GnuPG, OpenSSL and other pieces to create Role-based access for flat files * How decades-old cryptographic work in zero-knowledge proofs helps in 2023 * How a Key Sharding system from 1979 might be safe in some narrow cases, and we might have one of those cases, but analysing cryptography applications is difficult * Examples of production open source codebases implement modern cryptography for access control in 2023 * The ideas and code we have so far for enforcing privacy and secure access control within the data, callable via SQL * How we hope to roll out solutions to very large numbers of people, since in our view most privacy violations start on the mobile