5 releases

0.1.4 Feb 12, 2024
0.1.3 Feb 12, 2024
0.1.2 Feb 12, 2024
0.1.1 Nov 26, 2023
0.1.0 Nov 26, 2023

#156 in Authentication

Download history 834/week @ 2024-03-16 384/week @ 2024-03-23 133/week @ 2024-03-30 316/week @ 2024-04-06 503/week @ 2024-04-13 352/week @ 2024-04-20 193/week @ 2024-04-27 160/week @ 2024-05-04 426/week @ 2024-05-11 243/week @ 2024-05-18 384/week @ 2024-05-25 426/week @ 2024-06-01 194/week @ 2024-06-08 414/week @ 2024-06-15 185/week @ 2024-06-22 68/week @ 2024-06-29

898 downloads per month
Used in 4 crates (2 directly)

MIT license

1.5K SLoC

Futhark - A Runes Implementation in Rust

This is a rust implementation of the original runes library by Rusty Russell https://github.com/rustyrussell/runes.

What are Runes?

Runes are extendable authorization cookies, similar to Macaroons https://research.google/pubs/pub41892/ but simpler. Extendable meaning that a client that has access to a cookie issued by a server can derive a cookie with extra restrictions that can not be removed from the derived cookie. This cookie can then possibly be passed to some other party to authenticate at the server.

To find out more about the motivation of runes see the original repository.

Coverage and Features

This implementation is fully compliant with the given set of test vectors. However, a clean implementation of functional values for alternatives to check on are currently missing. These will be part of a future update.

  • Compliant with test vectors
  • Functional checks on values
  • Full crate documentation

Rune Language

(See the original repository for an in-depth explanation)

A rune is a set of restrictions that have to be passed. A restriction consists of one or more alternatives where at least one alternative has to pass.


An alternative is a string of the form (no spaces):


FIELDNAME contains only UTF-8 characters excluding punctuation characters:

! " # $ % & ' ( ) * +, - . / : ; < = > ? @ [ \ ] ^ _ \` { | } ~

Still, the punctuation characters can appear inside a VALUE but &, | and \\ must be escaped with \, as these are used to separate alternatives and restrictions.

CONDITION is one of the following values with the corresponding check

! field is missing
= exists and exactly equals
/ exists and is not exactly equal
^ exists and begins with
$ exists and ends with
~ exists and contains
< exists, is valid integer (may be signed), and numerically less than
> exists, is valid integer (may be signed), and numerically greater than
{ exists and lexicographically less than (or shorter)
} exists and lexicographically greater than (or longer)
# comment (always pass)


A restriction is a group of alternatives chained by a logically OR condition represented by |; restrictions are separated by &. Example rune:


The first restriction requires cmd to be foo or bar, the second requires that subcmd is not present, or is lexicographically less than (or shorter) get.

Rune Authorization

Every rune comes with a SHA-256 authentication code that ensures that no restriction can be striped from the rune. The basis for every authcode is a secret (less than 56 bytes), that is only known by the server that issues the rune.

From this authbase every restriction is appended to a rune with the following update to the authcode, assuming that the secret has been treated the same way:

  • Pad the restriction (the secret for the authbase) as per SHA-256 such that the result is a multiple of 64:
    • append 0x80.
    • append 0s (such that the result is a multiple of 64).
    • append the big-endian 64-bit bitcount (len) of the restriction.

This way, the authcode is always a SHA-256 digest.

A derivation is then achieved by adding a new restriction to the rune and updating the authcode.


Runes are base64 encoded (URL safe), starting with the SHA-256 authcode, followed by the restrictions (one or more) separated by &.


For more insights additional infos and examples visit the original repo https://github.com/rustyrussell/runes.


~119K SLoC