[Cryptography] Speeding up Linux disk encryption

Natanael natanael.l at gmail.com
Sun Apr 11 15:17:02 EDT 2021


Den fre 9 apr. 2021 22:43Ray Dillinger <bear at sonic.net> skrev:

> [...]
>
> Disk encryption that actually provides the protections people think disk
> encryption provides would require a whole new filesystem type, a whole
> new OS mostly organized around key management, and APIs that
> applications have to *use* (or else the application DOESN'T WORK) to
> specifically encrypt writes and decrypt reads.  'Reading' keys (half a
> symmetric pair) would be available in accounts having read permission to
> some file, and 'Writing' keys (both sides of a symmetric pair) would be
> available in accounts having write permissions to the file.  If it's an
> executable or a script, then it requires a different pair of keys;
> 'execute' permission would have half a symmetric pair and 'write
> executable' would have both halves.
>

This is how Tahoe-LAFS works, although it's not intended for use as a local
file system but rather as network based multi-server file storage. Nothing
stops you from hosting it all locally, though.

As a user who is accessing files hosted by this system you have read keys
and/or read+write keys, and the server (and hopefully also any adversaries)
has neither. Read keys are normal symmetric keys, while write keys is both
this symmetric key plus a private key for a signing keypair. When reading
files you also verify the signature.

You can use such a system to build more granular permissions, such as using
different write keys and different read keys for various files and then
controlling who has access to each key and setting metadata flags.

This may of course include using separate keys for executables, and
potentially metadata tags to tell the OS that only certain error write keys
are associated with executable permissions, controlled by a system
administrator (mimicking a capabilities model). In this case a user which
lacks write keys with executable permissions would only be able to run an
executable file which was created by some user who does have a write key
with executable permissions (such as the admin themselves).

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210411/21460a1a/attachment.htm>


More information about the cryptography mailing list