Feature poll for the Tomb v3 roadmap

[jaromil]

TL;DR: https://github.com/dyne/tomb3

Old poll: https://doodle.com/poll/2is26dx72x2s27cn

Hi everyone, I've been planning to work on Tomb v3 for a while now.

The objectives I have, in order of importance, are:

1. portable usage on windows and mac
2. keep consistent with the user experience in v2
3. increase the security of keys
4. backward compatibility with tombs built with v2

In order to realise them I would like to have a larger reality check with you all about the features in v2 that are most precious for your workflow and that are generally most useful.

Here is a POLL for the Tomb v3 feature plan and I'll be grateful to all those who like to chip in their ideas and experience. Please excuse the ads of the site, hope you don't mind, its just a quick way to get some feedback.

At last don't you worry about this initiative because Tomb v2 is made to stay: it will keep being available here and will keep doing what it already does at its best. The development happens on a new Tomb3 repository.

ciao!

[jaromil]

Quick update on this poll, as of today we have in order of priority

1. list (11)
2. resize (10+1)
3. slam (9+2)
4. bind mount hooks (6+4)
5. bury / exhume key in jpg (6+2)
6. asymmetric crypto to multiple recipients (5+2)
7. index / search (..6)
8. cloak / uncloak key in txt (..6)
9. ps processes using (3+2)
10. exec hooks (2+3)
11. engrave key to QR code (1+2)
12. sphinx key store on remote server (1)

A new feature request is the ability to handle partition-based device encryption made with LUKS, perhaps adding a tomb key in a slot of an existing encrypted volume, see issue #422

If there is any other feature we should take into account please add your comment.

[dngray]

I would have thought mounting without sudo (#322, #197). Don't see that on the list. That and #254 would all be worthy security improvements.

[jensrischbieth]

Adding my support for portable usage on Windows and other BSD based systems like MacOS 😄 . Am wondering what the approach will be here, considering cryptsetup is not available cross-platform to the best of my knowledge?

[jaromil]

Portability status:

• Windows: since v11 the Linux subsystem supports loopback mounts and AES encryption (only, no serpent) in dm-crypt, hence Tomb works (tested!)
• OpenBSD does not support loopback mount, no solution in sight
• FreeBSD and NetBSD not investigated yet (hints?)
• AppleOSX investigated long ago, docker is insufficient, not sure if any reliable port of cryptsetup is available today
• Android needs root to operate Tomb from Termux. Vanilla devices may be able to operate userland cryptsetup through Guardian project efforts? last time I looked it wasn't ripe

[jensrischbieth]

@jaromil Your comment, for the most part, summarizes my current understanding of LUKS on platforms other than Linux: some BSDs do support LUKS, Dragonfly BSD being one that comes to mind.

I wonder whether the way forward (ie Tomb3) is to use other disk encryption specifications and/or file systems that are cross-platform.

OpenZFS comes to mind, w/ cross-platform support for all major operating systems. We also avoid having to use FUSE based solutions, and simply load the appropriate kernel module for one's OS. In doing so, we can keep Tomb as a lightweight wrapper around several commands. I recall reading the following HN article before finding Tomb: https://news.ycombinator.com/item?id=30297188

This however, would kill all possibility for backwards compatibility w/ Tomb2.

[jaromil]

@jensrischbieth Tomb 3 will break backwards compatibility with Tomb 2. I will keep maintaining both solutions.

[jensrischbieth]

@jaromil I see. Was going off of your objective list at the start of this thread.

In such a case, I see nothing preventing the adopting of another filesystem and/or disk encryption standard that works cross-platform. In the case that OpenZFS ends up being the chosen standard, creating an encrypted zpool isn't too difficult. Tomb3 could also inherit many useful ZFS options, such as compression and passphrase-only encryption, exposing these to the user.

Feel free to push back if you know of a better solution to the problem. ZFS is not without its drawbacks 😄 .

[jaromil]

@jensrischbieth thanks, I know fairly well and love ZFS, my private RAID-Z fileserver is >10yrs old and has never failed me, but I never used its encryption functionality. I'll consider it and do some tests, meanwhile I'm not really in a rush for Tomb v3

[jaromil]

Dears, I have started Tomb v3 development

It starts with an explanation of goals and features I've gathered from our interaction, the focus and list of features is not final, but won't make a lot of changes as this is something I really need myself. In particular and about OpenZFS I am testing that v3 tombs (ext4 formatted) work well on FreeBSD and can be easily stored inside ZFS volumes.

[jaromil]

I have changed my mind about how these enhancements will be introduced and the shape of the v3 roadmap.

There won't be a separate v3 repository, but two new "flavours" of tomb will be redistributed along with it:

• portable based on veracrypt and POSIX sh
• ZFS based on ZFS volume encryption

A proof of concept of portable tomb is already available in the repository and will be redistributed as a developer preview in the new upcoming 3.0 release series.