Project Klutshnik

This page is currenlty under construction.

For more info see:

for any announcements follow @stf@mastodon.social

Klutshnik is client/server solution that brings forward-secrecy, post-compromise security and a bunch of other very nice things to data-at-rest. Also the worlds first public and free threshold OPRF and threshold OPAQUE!

WARNING: this release is a very early experimental release meant as a tech-demo, there is little hardening applied yet. In the coming months we will change this and forge it into a tool that can be widely deployed and trusted.

keeper7keys.jpg

The core-functionality is based on the full verifiable threshold UOKMS construction of the paper: "Updatable Oblivious Key Management for Storage Systems" by Stanislaw Jarecki, Hugo Krawczyk, and Jason Resch.

To quote the abstract:

[…] system, that builds on Oblivious Pseudorandom Functions (OPRF), hides keys and object identifiers from the KMS, offers unconditional security for key transport, provides key verifiability, reduces storage, and more. Further, we show how to provide all these features in a distributed threshold implementation that enhances protection against server compromise.

We extend this system with updatable encryption capability that supports key updates (known as key rotation) so that upon the periodic change of OPRF keys by the KMS server, a very efficient update procedure allows a client of the KMS service to non-interactively update all its encrypted data to be decryptable only by the new key. This enhances security with forward and post-compromise security, namely, security against future and past compromises, respectively, of the client’s OPRF keys held by the KMS. Additionally, and in contrast to traditional KMS, our solution supports public key encryption and dispenses with any interaction with the KMS for data encryption (only decryption by the client requires such communication).

There are many nice things about this construction. One of the most exciting ones is that it allows for key-rotation, which does not need to re-encrypt the files. If you don't want to read the paper, come back in a while for new blogposts giving insights to how this works.

Another notable aspect of Klutshnik is that it is an online construction, the client works together with a (number of) server(s) in order to decrypt a file protected by Klutshnik. Don't be confused, server doesn't have to mean something on the internet, it could be running on a phone, something that communicates via NFC. The point is, that the Klutshnik server acts as a separate security compartment that needs to be compromised in order to decrypt files protected by Klutshnik. This is much better than having your age or pgp keys on your hard disk next to the files they protect.

Both of these nice properties of Klutshnik come from the fact that at the very heart an OPRF is used. Which brings us to the next great announcement:

Threshold OPRF in liboprf

Yes, liboprf has support for a threshold version of the OPRF that is specified by the CFRG IRTF. And that is a first, I am not aware of any other publicly available OPRF implementation which supports a threshold setting. This tOPRF is based on TOPPSS: Cost-minimal Password-Protected Secret Sharing based on Threshold OPRF by Stanislaw Jarecki, Aggelos Kiayias, Hugo Krawczyk, and Jiayu Xu

As a nice (and necessary) side-effect liboprf also has a distributed key generation (DKG) implementation based on "Secure Distributed Key Generation for Discrete-Log Based Cryptosystems" by Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, Tal Rabin.

The use of the liboprf tOPRF enables Klutshnik to also operate in the threshold setting. But there's more!

Threshold OPAQUE without changes to libopaque or OPAQUE clients

The original OPAQUE paper mentions in passing that the OPAQUE server can do offline dictionary attacks against the users password. And that a very strong defense against this is a threshold version of OPAQUE. The CFRG/IRTF draft of the OPAQUE spec considers the threshold variant out of scope. But libopaque (and any other OPAQUE implementation using liboprf) supports this tOPAQUE through the tOPRF implemented in liboprf! Again, I know of no other public OPAQUE implementation which supports the threshold setting. We have a working version of tOPAQUE available in the opaque-store repo.

Other interesting components

All communication between the client and the servers (as currently implemented) are using the Noise XK pattern, the server uses the formally verified implementation of noise-star. The server has a file "authorizedkeys" which much like ssh, only allows connections from clients having pubkeys listed in this file.

For authorization of requests against the Klutshnik server macaroons are used. See Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud by Arnar Birgisson, Joe Gibbs Politz, Úlfar Erlingsson, Ankur Taly, Michael Vrable, Mark Lentczner.

This allows users to limit the authorization by date, by public noise-key and by keyid, which can then be passed on to 3rd parties, who will only be able to decrypt content as long as they satisfy the constraints of the macaroon. After a macaroon expires the key it enabled can be rotated, and thus decryption access will be completely revoked from the 3rd party.

The original UOKMS construction is devised for the use by cloud-providers. Klutshnik however is targeted at personal use, replacing aging (pun intended) designs like pgp. No cloud operator will want to type in passwords for decrypting files. However in the personal use use-case this can make sense (especially when combined with a strong password storage like SPHINX) and thus in the extended default setup there is automatic support for opaque-store to store noise keys and authorization tokens protected by a password. Of course if you don't want that, you can also specify your authorization token directly in the config file, and use noise keys stored on the filesystem.

The files are encrypted using the STREAM construction from Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance by Viet Tung Hoang, Reza Reyhanitabar, Phillip Rogaway, and Damian Vizár.

Future

The code needs cleanups, hardening, privilege separation, sandboxing, possibly porting to other languages, but definitely to other HW like phones, raspberry pis, ESP32, possibly the betrusted.io precursor, and other affordable dedicated compartments.

You wanna play with this?

If you wanna play with this, I am humbled! Please expect my utmost attention and readiness to help you get started! This is the minimum you need to get working:

What's with this weird name Klutshnik?

It is a homage to the all the great cryptographers having a polish/slavic background. 'kljutsh' (or variations of it) means "key" in slavic languages, and the 'nik' postfix means something like "person" just like in beatnik. Together they mean "person of keys" or "key person". Anyway I think it is a much better name than GNU Keymaster 3000 Deluxe Pro.

Thanks

I would love to express my gratitude to my love, who endures me working and rambling on this. Peter Schwabe who invited me last year to HACS workshop which was so inspiring like nothing before, which spawned all this above. Trevor Perrin explained me how to implement a tOPRF, and Hugo Krawczyk who was patient enough to answer some of my ignorant questions. And Jonathan who helped me understand some tricky part of the DKG.