iqlusion crates is one workspace of seven Rust libraries, mostly about keys and secrets

A workspace, not a framework, and the distinction changes how you use it

The iqlusion crates repository is described as a set of Apache 2.0 licensed packages, a.k.a. crates, for the Rust programming language, contributed to the community by iqlusion. The homepage is iqlusion.io, the default branch is main, and the primary language is Rust.

The repository layout is the mechanism. The top level holds a Cargo.toml that is a workspace definition, and it lists the members explicitly.

[workspace]
resolver = "2"
members = [
    "bip32",
    "canonical-path",
    "hkd32",
    "iqhttp",
    "secrecy",
    "signatory",
    "subtle-encoding",
]

Each member is a directory with the crate's own source, its own CI workflow and its own published version, and the version badges in the README point at crates.io for each crate individually.

Each crate has its own build badge in the README, linking to a separate GitHub Actions workflow per crate. That is the tell for how this project is maintained. It is not one library with one release train, it is seven independent libraries that happen to share a repository, a licence and a maintainer. That means you take one, or two, and you do not inherit the others.

For a reader deciding whether to use anything here, that framing matters. You are not adopting a platform, you are picking a library or two from a set with a shared provenance and a shared dependency hygiene policy. The README does not give an install command, and it does not need one: the crates are published to crates.io under their own names, and the dependency status badge points at deps.rs for the current state of each dependency tree.

Three of the seven are about keys, and one of them is not

The table in the README gives each crate a one line description, and the descriptions are the fastest way to see the shape of the collection.

bip32 is hierarchical key derivation. hkd32 is HMAC-based hierarchical key derivation. signatory is a signature library with ECDSA and Ed25519. Those three are the crypto core of the set, and they are related in that they all deal with the same problem of deriving and using keys.

Then there is secrecy, described as a simple secret-keeping library, subtle-encoding, described as constant-time hex, bech32 and base64, and canonical-path, described as canonical filesystem path support.

secrecy and subtle-encoding are the two that belong together in spirit even though they are separate crates. Both exist to stop a class of mistake: a secret that gets logged, printed or compared in a way that leaks it through timing, and an encoding that is not constant time and therefore leaks through timing. A library that keeps a secret out of Debug output and a library that compares and encodes without early exits are the same concern expressed in two places.

iqhttp, an HTTP client built on hyper, is the odd one out. It is the only member of the set that has nothing to do with keys, and it is also the one that will pull the largest dependency tree into your build, since hyper is a substantial foundation rather than a small utility.

canonical-path is the other outsider, and it is the least obviously cryptographic of the group, existing because path handling on different platforms is a recurring source of bugs.

Constant-time encoding is a small crate with a large blast radius

subtle-encoding is described as constant-time hex, bech32 and base64, and the name is the explanation. A normal hex or base64 encoder is fast and branchy, and a comparison of the result with a plain equality check will return early on the first differing byte. That is a timing side channel, and for a value like a MAC or a key comparison it is a leak.

The subtle part of subtle-encoding is that it covers the whole chain. Encoding is only half of it, because the comparison that consumes the encoded value is where the timing leak happens. A crate that offers constant-time base64 but leaves you to compare the result with == has not solved the problem, and the name of the crate suggests the author was thinking about the whole path rather than the encoding step alone.

That is also why bech32 is in the list. Bech32 is the checksummed format used for human transferable identifiers, and checking that checksum naively, byte by byte with early exit, is exactly the kind of comparison the crate exists to make safe.

The practical use case for all of this is a wallet or a key custody system, which is exactly the neighbourhood the rest of the collection lives in. If your project never compares a secret against an attacker-supplied value, this crate is likely more than you need. If it does, hand rolling constant-time logic is exactly the thing not to do.

Two key derivation crates, and the difference is the hash

bip32 and hkd32 both do hierarchical key derivation, and the table tells you what distinguishes them: hkd32 is HMAC-based, bip32 is simply described as hierarchical key derivation.

BIP32 is a scheme for deriving a tree of keys from a single master seed, and it is the format behind the familiar hierarchical deterministic wallets, where a path of indices selects a child key. It is a specific, standardised algorithm with a specific structure for its chain codes, and any two implementations of it are interoperable.

HMAC-based derivation, which is what HKDF-style construction over an HMAC gives you, is a general technique. You define a derivation function over inputs and a salt, and the output is a pseudorandom key material. It is not a tree structure on its own; it is the primitive you build tree walking on top of if you want one.

So the choice is between a specified, interoperable standard and a general primitive. If you need to be compatible with something else that derives keys from a seed, BIP32 is the one with a defined format, and compatibility is the whole point of having a standard. If you are designing a key hierarchy yourself and only need the derivation step to be sound, the HMAC-based crate is smaller in its commitments.

hkd32 being in the same repository as bip32 makes sense under that reading. The author needed both, and published both.

signatory covers ECDSA and Ed25519 behind one interface

signatory is described as a signature library with ECDSA and Ed25519, and the pairing of those two algorithms is the design decision.

ECDSA is what most systems use for signatures, and it is what the NIST curves and the existing toolchain expect. Ed25519 is simpler, has no parameter selection to get wrong, and signs faster. A library that offers both behind a common abstraction means an application can choose per use case, and can move a key from one curve to another without rewriting the calling code.

The abstraction is also what makes the library usable across a portfolio. The way signing keys are identified, stored and loaded differs between schemes, and a library that normalises that saves each application from writing its own version of the same plumbing.

What the README does not tell you is which curve or format is the default, whether there is a hardware backend, or how the key material is protected once inside the library. For a crate that handles signing keys, those are the questions to ask before you adopt it, and the crate's own documentation rather than this repository is where the answers will be.

The whole set fits together as a wallet and custody toolchain: derive keys, sign with them, keep the secrets in a type that does not leak, and encode and compare in constant time.

secrecy and the cost of a type that refuses to print itself

secrecy is described as a simple secret-keeping library, and the word simple is doing deliberate work in that description.

The idea is that a secret should be a distinct type rather than a String with a comment next to it. If the secret has its own type, the compiler can help you: Debug output can be redacted, the value can be marked so it is not accidentally cloned into a log line, and a missing secret becomes a type error rather than an empty string at runtime.

The alternative, which every codebase has lived with, is a convention. You name the variable SECRET_TOKEN and you hope. A library makes the convention enforceable.

The trade is that it is a wrapper type, so you get accessor methods rather than field access, and you occasionally have to unwrap at the boundary where a value is genuinely needed. For a codebase that handles credentials in many places, that friction is worth it. For a codebase with one token, it is ceremony.

It also pairs naturally with subtle-encoding. A secret type that redacts in Debug and an encoder that does not leak through timing are two halves of the same concern about not leaking secrets, and having both in the same repository suggests they were built to be used together.

Licensing, and the detail in the badge list

Everything in the repository is Apache 2.0, with the licence text in the LICENSE file and the copyright statement reading 2018 to 2024 iqlusion. The README includes the standard Apache 2.0 grant language, with the usual disclaimer that the software is provided as is without warranty.

The contribution terms are the standard Apache 2.0 clause, that unless a contribution is explicitly stated otherwise, any contribution intentionally submitted for inclusion in the work is licensed as above without additional terms or conditions. Contributors are asked to read CONTRIBUTING.md and CODE_OF_CONDUCT.md first, and there is an AUTHORS.md file at the top level. A .typos.toml file at the root is a small sign of a project that runs automated checks on its own text.

There is a dependency status badge linking to deps.rs, which is the standard place to check how current the dependencies of a Rust project are, and the crates.io version badges are per crate.

One detail in the README is worth flagging because it shows the repository is maintained by hand rather than generated. The table of crates lists seven, and the workspace members list seven, and the build badge list at the bottom contains eight entries. The extra one is a build badge for tai64, a crate that has a CI workflow but no directory in the repository and no row in the table. So the badge section still refers to a crate that is no longer part of the set. If you are reading the README to work out what is available, trust the table and the workspace members, not the badge list.

Where this collection is the wrong answer

Two clear cases.

The first is if you want one of these capabilities from the ecosystem mainstream rather than from iqlusion. Constant-time encoding and secret-keeping types are the kind of thing the wider Rust cryptography community provides in more than one implementation, and the general advice of preferring the more widely used crate applies here. Choosing a crate from a smaller maintainer is a reasonable thing to do, but it is a decision you should be making deliberately, and this repository does not make the case for itself on adoption grounds. It says the crates are contributed to the community by iqlusion, and that is where the argument stops.

The second is the build weight. iqhttp is an HTTP client built on hyper, and hyper is a large foundation. If what you want is a small client for a simple service, pulling a full HTTP stack and its tree into a project for one call is a poor trade, and the standard client in the ecosystem may be the better choice.

There is also a structural point. Seven crates in one repository, each released independently, means seven things to track rather than one. A change in signatory does not necessarily mean a change in secrecy, and each crate has its own version, its own changelog and its own compatibility surface. The upside of the arrangement, that you take only what you need, is also its cost, that you have to track each piece separately.

The repository is not archived and the last push was on 2026-10-17, so the crates are being worked on. The README does not give a release history for the workspace as a whole, because there is not one.

Editorial conclusion

Adopt iqlusion crates if you are building Rust software that handles keys, signatures or secrets and you want small focused libraries with a consistent Apache 2.0 licence across the whole set. Do not adopt the whole workspace for one crate, since each one is published separately to crates.io and can be taken individually. Before you add one, check the per-crate build badge and the crate's documentation on crates.io, and pin the version you tested, because the crates are released independently of each other and of the repository.

Frequently asked questions

Official sources

1. iqlusioninc/crates on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README