[remark] Experimenting with multi-factor encryption

by Ciprian Dorin Craciun (https://volution.ro/ciprian) on 

Prototyping an encryption tool that allows combining multiple encryption factors, from PIN's, passwords, to X25519 pairs, and beyond.

// permanent-link // Lobsters // HackerNews // index // RSS

In the beginning of 2023 I've started extending my open-source project z-tokens, from just supporting passwords (plus other related tokens) generation and hashing (with various well-known algorithms), with support for a very "opinionated" encryption tool.

I know that "opinionated" is currently a very misused word, from "opinionated" web frameworks, to "opinionated" cryptography tools. However, in this case I think I'm not misusing it, as I'll try to describe further.

!!! WARNING !!!
I am not a cryptographer, or even a security expert!, at best I am a hobbyist applied-cryptography developer, thus take everything I say with a large grain of salt and lots of circumspection. As we all know: never implement your own cryptography! (It used to be just "[...] own crypto", but then some people wanted to rebrand ponzi-schemes into something that sounded more academic...)

Why I've set to implement another encryption tool is perhaps a story for another time. However, for the moment I would like to describe the approach I've taken.

Many tools -- by which I actually mean GnuPG and age -- support any of the following encryption mechanisms:

So, isn't that enough, one might ask? Obviously it is enough from a purely technical point-of-view, however not necessarily in terms of intended use-cases.

For example:

To answer these use-cases, here follows my "opinionated" proposal.

First of all, provide multiple mechanisms (that sometimes are technically equivalent):

Then, allow any number of these (including multiple of each kind) to be used together. For example, both one X25519 sender private key and two X25519 recipient public keys, plus also a PIN.

Additionally, also adding support for:

For the curios, the Rust implementation (still an early prototype) can be reviewed on GitHub at: z-tokens/exchange/crypto.rs.

Now one might ask, and definitively I've asked myself this, isn't this overly complicated? I can't say it isn't, however I also can't find a solution that is at the same time both flexible and not a foot-gun...

Sure, one could go the PGP route and allow the user to choose the number of password derivation iterations or even the preferred cipher suite, but that would require too much from the user.

Meanwhile, with the current proposed solution, I can easily and safely implement various scenarios that would be quite hard to achieve with the existing tools.

Just to give a few examples:

Technically, both the PIN's, secrets, and ballasts, work in the same way with the main difference being the time it takes to derive each of these into cryptographic material.

I'm curious if anyone would find such a tool useful? Or if perhaps there aren't already tools that do something similar?

Let me know via an email or comment as described in the feedback section.