DEV Community: Denys Séguret

SafeCloset, a Secret Safe - Why and how I made it in Rust

Denys Séguret — Tue, 07 Dec 2021 18:00:18 +0000

Like everybody, I have small secrets to store, like door codes, some passwords, where I buried the body, etc.

They must be kept away from other eyes but, more importantly, they must be available, even if I'm traveling far from my computers.

And they must be easily backed up without risk.

In the past, I've dealt with such secret storage with various solutions, like having files decrypted, edited with my favorite editor, then encrypted again.

They were full of weaknesses:

temporary clear files that could be inadvertently backed up, or staying here if I had to leave or in case of crash
editor weaknesses, like backup files and plugins
OS specificity making them inaccessible when far from my computers

The temporary clear files where the most dangerous problem. I've had to hunt for my clear files after a badly parameterized backup rule.
Editor plugins were a real threat too, especially as I started using an AI plugin storing whole extracts of my texts for better auto-completion.

So I had to find or build better.

The obvious requirements for my new solution were:

an encrypted storage file, with a strong algorithm
a storage format making it possible to keep the file on non secure disks
a multi-platform application, that can be easily carried too
totally open-source, so that the program can be fixed or rewritten
no clear file ever created, no data sent to external API, so the application is an editor too
pure Rust, to avoid most nasty bugs

I added a few less obvious requirements:

easy fuzzy key search
fast opening, instant closing
auto-closing (dead man switch)
focus on ergonomics, I want to feel comfortable editing in the application

And in case I inadvertently become a secret agent:

plausible deniability by putting drawers (storage units) inside other ones
non observability of deep drawers (having several versions of the file doesn't let you know whether there were changes and in which deep drawer)

Now, let's see the technical choices.

Programming language: Rust

As I said, this was obvious to me. Such program can't really be written today in another language. Rust doesn't prevent all bugs, but it makes it possible to avoid the nasty ones which stay hidden and compromise security.

Cryptographic algorithm and library : AES-GCM

I never considered rolling my own algorithm or using a lightly tested library.

I choose an AEDS crate from the RustCrypto group: AES-GCM in its SIV variant (the SIV variant isn't really needed but it doesn't cost much).

File format

The minimal unit of secret in SafeCloset is an entry, which is made of a name and a value, for example "VISA Card code" and "9875".

Entries are stored together in a drawer.

SafeCloset uses the metaphor of closets and drawers:
A SafeCloset file contains something which is called a closet.
A closet contains several drawers. Each drawer is separately encrypted, with its own passphrase (and nonce).

A drawer also contains a closet, which contains deeper drawers.

To ensure plausible deniability, drawers are automatically created, including deep ones, and nothing distinguishes drawers that you created and you can open from the ones which were automatically created and that you can't open (you could if you knew their password but they aren't displayed on creation and they only contain random bytes anyway).

Drawers are serialized using the serde crate which is kind of standard in the Rust world and is very convenient. For the encoding format, I choose MessagePack which, like JSON, allows field addition but is much more compact. Having optional fields is very important to allow evolution of the file format while ensuring old files will stay compatible with newer versions of the application.

Combining the chosen encryption scheme and the serialization encoding with the list of structures and fields, the complete file format is described in the community page to allow replacement of the application if needed.

Making an UI in the terminal

There are many low level libraries whose features go from the basic (and easy) task of coloring and styling the text you print in the terminal to handling events, terminal size, alternate screen, etc. I personally like Crossterm which is cross platform and well designed.

I combine it with Termimad, a crate I made to manage skins, generate texts without mixing the style and the content, handle text inputs, even with wide characters, and a lot of small TUI related problems.

Termimad allows fancy things like editing texts in small areas of your terminal and fading the view behind the menus or dialogs:

As the author of Termimad I feel comfortable to not recommend you use it for your own TUI. Not that it's bad, I like it, but it's a strange beast covering much more than what a library should do, and at a much lower level than your typical framework. If you're not used to low level TUI libraries and well versed in Rust, I suggest you look at other higher level TUI crates.
If you still hesitate, come to my chat and I'll tell you whether Termimad might be the right choice for your application.

Other libraries

They're very few other crates involved, way less than in common programs of the same complexity. This was a deliberate choice consistent with the global efforts of making it easier to check the source and of reducing the attack surface.

The result: SafeCloset

Here it is: https://dystroy.org/safecloset/

If I may say so, I'd say SafeCloset is convenient and pleasant to use.
It lets me find and read my secrets in a few keystrokes.
And it seems to be the most secure solution I ever used.
I designed it to be intuitive for other users too, and I hope I succeeded.

To better introduce it, I made a website explaining how it works, how to install it, how to use it: https://dystroy.org/safecloset/

The current version is a candidate for a release as 1.0, there's nothing important missing right now, but I'll let some time run to be sure.

I'd welcome your opinion!
And if you have questions, for example on technical details, please ask.

Lapin, a terminal game in Rust

Denys Séguret — Thu, 12 Mar 2020 11:07:34 +0000

My kids (4yo and 6yo) are fan of the command line since the first time I showed them sl.

One month ago, my youngest one asked for a game with a rabbit and a pink knight.

In such a case, you can either postpone indefinitely or you can rush to finish it in the evenings of a few weeks so that he's still young enough to appreciate it.

So here it is, a game with a rabbit chased by foxes, wolves, and riffle armed hunters.

A turn by turn game where invulnerable pink knights fight all your foes.

Rules so simple your kids will remember them after you've told them once.

And an editor, because the best game for a kid is to draw (more so if the inks are made of foxes and pink knights and grass and mud...).

And campaigns in which you can pack sequences of levels you or your kids made.

If you're more than 6yo, you won't be impressed by the graphics.

As a developer you might find a few interesting things in this small and hopefully clear program:

to start with, it's in Rust and I try to keep it clean. As usual in Rust, this was a delightful coding experience, almost bug-free from start to finish. An exemple of the zero cost abstractions and the sanity it brings is the use of separate types for the position on screen and the position in the game's world, I know I usually have confusion in code dealing with several reference systems in the same unit and there was none this time.
a sane and safe state+transition based application architecture
a crossterm based terminal UI with support for mouse, resize (and support for any size starting at 20*5), etc.
pathfinding (Dijkstra and A*)
hundreds of independent actors acting according to their own goals
parallel computation of actor moves using rayon
unbounded maps
sub-character move animation (try the game to understand)
undo/redo stack
serialization in user chosen format using serde
resource (default campaign) packed in the executable
no excessive optimization (I considered a bitset based map and decided it wasn't worth the pain and stuck to sane and easy to read and change data structures)

And I'd welcome any help or advice to improve the program!

(or levels for my kids)

The code is almost a kid's game too:

impl ActorKind {
    pub fn eats(self, other: Self) -> bool {
        use ActorKind::*;
        match (self, other) {
            (Fox, Lapin) => true,
            (Knight, Fox) => true,
            (Knight, Hunter) => true,
            (Knight, Wolf) => true,
            (Wolf, Hunter) => true,
            (Wolf, Sheep) => true,
            (Wolf, Lapin) => true,
            _ => false,
        }
    }
}

Here's the repository: https://github.com/Canop/lapin

I'll be happy to answer your questions about the game or the code!

An exploration of Rust/Wasm

Denys Séguret — Mon, 01 Jul 2019 08:37:42 +0000

A few days ago, I decided I needed to have an idea of what was the state and promises of Rust/Wasm development.

And in order to have a clear idea of the soundness and strength of the foundations, I didn't want to deal with the advantages and problems of the various frameworks, I wanted to look at the real deal, Rust/Wasm without superfluous frameworks and libs.

And I didn't want a mix approach with hard things done in JavaScript, I wanted to see whether you can do everything from rust and to what extent your experience is as positive as the classical Rust one.

So I decided to write the tic-tac-toe game in pure Rust/Wasm.

Before I go on with the journey, Here's the result.

Nothing fancy but it made me test what I wanted to test. It works. And if you open the network tab of your browser's developer tools, you can notice the files are rather small, and there's no polling or useless redraw.

WebAssembly is a binary instruction format that you can give any recent browser and which will be executed sandboxed with access to the browser. So building a rust+wasm application is mostly compiling your rust files into a .wasm file that you can serve to your browser in place of your usual JavaScript one. Your application will still contain a little bootstraper loading your wasm file and giving it to the browser, I hope this artefact will soon enough disappear.

The first reef waiting for the explorer is that most tutorials are full of unneeded contorsions and tools, for example using npm, webpack and a framework when what you want is just to learn Rust/Wasm. This is the equivalent of learning JavaScript by first installing Angular, jQuery and Gulp.

Here's a simple example, though: wasm-bindgen without a bundler. It's only a "Hello World" but it sets us on track.

The basis is to use the wasm-pack cargo tool to build the wasm file. You'll use only three libraries: wasm-bindgen which links the JavaScript and Wasm world, js_sys wich gives access to standard build-in objects like the JSON parser, the binary arrays or the Math function (when in wasm, you don't have access to the standard Rust libraries, even the ones which can be sandboxed, because they would have to be embedded in the wasm file), and web_sys which gives you access to the browser's world (including the DOM).

So, thanks to the example, I just wrote by hand the few files (no, you don't need a generator), that is the Cargo.toml file and src/lib.rs.

This is enough. You just have to execute

wasm-pack build --target web

and voilà, you have a pkg directory containing your wasm file and a standard JS bootstraper.

Of course, just like a JS file doesn't make an application, a Wasm one doesn't. So I added a HTML file, and a CSS one (you should have a look at the HTML file.

From there, you just have to open your file through HTTP (after having configured the server to serve .wasm files with the application/wasm mime type. There's no need to publish to the npm repository, there's no need to use another packager, you can keep those kind of tasks for when your application really needs it and you know why, with the tool chain of your choice.

At this point I had just copied the code from the example, which was adding an element with "Hello World" as inner HTML.

The next step was to add the elements of a Tic-Tac-Toe game, the matrix.
Knowing the DOM well enough I had no difficulty finding the right methods and structs in web_sys (Exhibit 1: Element.
I could directly write the elements in rust. It was clean enough but you fast notice this interface gives you a lesser type system, as some methods return you some value which may, or not, be of the desired type (for example if you create a node with document.create_element, the Node you get may be, or not, a HtmlElement depending on the tag.
This could easily be isolated in a tiny helper library, though, so this isn't a big deal.

Glancing at web_sys, you may notice the methods to add event listeners are also here.
web-sys does include a facility to make rust Closures and JavaScript closures interact. This isn't as simple as it seems.

Now it looks good, we just have to design how we will cleanly keep our application state around and have a normal event based web application continuously adding and removing elements and event listeners, deal with events, and so on.

Just the normal life of a web app, with the sanity of Rust, the perfect dream.

But it's not that simple.

You must keep a reference to your rust closure or the JavaScript event handler will fail when called (at runtime... there's no compile time check). There's also the possibility to leak them but we're looking for a viable solution for a real application, so it's absolutely out of question.
There's only one UI thread, and your event handlers are called on this thread.
A Rust application isn't supposed to have a mutable static state anyway.
You can't store your handlers behind an Arc, because the pointer to the JS isn't transferable between threads
You don't have mpsc channels (in fact you don't have much of the std utilities)

So... There's no really clean solution.

I built something which is probably safe, and quite clear, but it involves ugly calls to unsafe blocks to access the global state. I've put the active event handlers in this global state (which could be modularized).

Closure creation and boxing is ugly too (exhibit 2: BoardView).

Part of this problem could easily be isolated by a small framework, but the core isn't pretty.
And a big framework means bigger wasm files.
I hope some micro framework just for this problem will appear and be good enough without succumbing to the tentation of building a whole bag of template/binding/virtual-dom/etc fatness (some will need this one, of course, but we need a small strong core too).

From there I just had to add the necessary logic (which isn't long or complicated for such a game) and the "You win/lose" panel, then to add a "New Game" button, mostly to check I can add and remove buttons and their handlers without leaking memory.

And the game is done.

With this experience, here's how I see the use of rust+wasm compared to JavaScript:

What do we gain

We write in Rust, which has a nicer syntax. Union types, traits, patterns, sane generics, an ownership which avoids the overhead of a garbage collector (and you really don't want your wasm file to include a GC), and no null pointer
We have a little better type safety
A lot more is tested at compile time than if we were to use JS, TS or another wasm language
Rust modularisation is much cleaner than anything standard in the JS world, both at the internal application level and when it comes to use external packages

What do we not gain

Type checking isn't totally perfect, due to the interface with the browser. It's probably not much better than TypeScript at this point
There are more runtime errors that what would be expected from a rust program (because it's not a rust program, it's a browser+rust program)
There's no multithreading. Concurrency tools like the mpsc channels aren't available. Even mutexes are only partly usable. Yes I'm sure there will be tools "supporting" multithreading through webworkers but serialization-based message passing between agents is reserved to a smaller set of use cases. Rust will be the most apt to use safe multithreading when SharedArrayBuffers are back, but there's no clear direction or dates for that.

What do we not lose

There's not much from the client-side JS ecosystem which will be missed. Tools will be easily made to replace them.
building applications totally or partly based in Rust doesn't seem to me to really complexify the tool chain. And I'm not sure it's slower to compile Rust than to lint/transpile JS nowadays.
files aren't big. Rust needs no runtime, needs no gargbage collector, so there's not much to add to the wasm files.

What do we lose

Managing the state of your application and the handlers makes for ugly code.
There's less liberty in the architecture of your application.

As I love Rust I'll probably write some of my next webapp frontends in Rust/Wasm but this will need a small framework (of my own if I don't find anything good enough) and it's not something I would recommend at this point to developers with no knowledge of Rust.

As you may have noticed, I wrote this with not much experience in Wasm (which was the point). I'd be really interested by your analysis and maybe corrections.

Edit your file hierarchy with Broot 0.7

Denys Séguret — Fri, 08 Mar 2019 14:27:03 +0000

I've just released the new version of Broot.

The previous versions focused on viewing and navigating the file hierarchy but I noticed, just like a few other testers, that it could be very convenient to also edit it.

When you create, move, delete, copy your files or directories, you usually do it in the blind, meaning you do some ls (or br) before, and maybe some after.

With the new version of broot you see the file hierarchy when you type your command, and it's immediately updated. The tree view went from read-only to read-write.

Standard file commands are built in, you don't need to add them, but the verb configuration syntax allows you to define your own commands the same way and you get to preview the expanded command before it's executed.

There are already a lot of features I can build upon this, and that I plan to do, but the more testers, ideas, stories I get, the happier I'll be!

Canop / broot

A new way to see and navigate directory trees : https://dystroy.org/broot

Broot

A better way to navigate directories

Complete Documentation - Installation Instructions - Contributing or Getting Help

Get an overview of a directory, even a big one

Hit br -s

Notice the unlisted?

That's what makes it usable where the old tree command would produce pages of output.

.gitignore files are properly dealt with to put unwanted files out of your way.

As you sometimes want to see gitignored files, or hidden ones, you'll soon get used to the alti and alth shortcuts to toggle those visibilities.

(you can ignore them though, see documentation).

Find a directory then `cd` to it

type a few letters

Hit altenter and you're back to the terminal in the desired location.

This way, you can navigate to a directory with the minimum amount of keystrokes, even if you don't exactly remember where it is.

Broot is fast and doesn't…

View on GitHub

broot, a new way to browse directories

Denys Séguret — Fri, 01 Feb 2019 11:05:05 +0000

I always loved the overview you can get from a tree like view. But tree is almost never usable, because it usually generates pages (or hundreds of pages) of output.

tree is also not interactively searchable and of course doesn't act as a launcher.

tree was one of the starting point in the reflection. fzf was another one, I can't live without fuzzy search anymore.

And thus I made broot which I use all the time, which lets me go to any directory or file with a few keystrokes and faster than any other one.

It's ready for general consumption, now, but I'm still thirsty for feedback.

broot can be launched with commands, which allows for example non interactive shortcuts like this one:

If any rust expert is around, I'd love to discuss the code, especially any ideas of micro-optimizations (the development of such a program is all about speed).

Canop / broot

A new way to see and navigate directory trees : https://dystroy.org/broot

Broot

A better way to navigate directories

Complete Documentation - Installation Instructions - Contributing or Getting Help

Get an overview of a directory, even a big one

Hit br -s

Notice the unlisted?

That's what makes it usable where the old tree command would produce pages of output.

.gitignore files are properly dealt with to put unwanted files out of your way.

As you sometimes want to see gitignored files, or hidden ones, you'll soon get used to the alti and alth shortcuts to toggle those visibilities.

(you can ignore them though, see documentation).

Find a directory then `cd` to it

type a few letters

Hit altenter and you're back to the terminal in the desired location.

This way, you can navigate to a directory with the minimum amount of keystrokes, even if you don't exactly remember where it is.

Broot is fast and doesn't…

View on GitHub

DEV Community: Denys Séguret

SafeCloset, a Secret Safe - Why and how I made it in Rust

Programming language: Rust

Cryptographic algorithm and library : AES-GCM

File format

Making an UI in the terminal

Other libraries

The result: SafeCloset

Lapin, a terminal game in Rust

An exploration of Rust/Wasm

What do we gain

What do we not gain

What do we not lose

What do we lose

Edit your file hierarchy with Broot 0.7

Canop / broot

A new way to see and navigate directory trees : https://dystroy.org/broot

Broot

Get an overview of a directory, even a big one

Find a directory then cd to it

broot, a new way to browse directories

Canop / broot

A new way to see and navigate directory trees : https://dystroy.org/broot

Broot

Get an overview of a directory, even a big one

Find a directory then cd to it

Find a directory then `cd` to it

Find a directory then `cd` to it