# XKCP: the Keccak team's reference implementations, gathered in one package

> XKCP is the repository that collects the Keccak team's free implementations of SHA-3, SHAKE, KMAC, TurboSHAKE, KangarooTwelve, Kravatte and Xoodoo, packaged as the libXKCP library with per platform builds. It suits a cryptographer or an implementer who needs the reference code, and it is not a turnkey crypto library to drop into a product.

**XKCP/XKCP** — eXtended Keccak Code Package

- Repository: https://github.com/XKCP/XKCP
- Stars: 664 · Forks: 210
- Language: C
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/xkcp-xkcp

## Every scheme the Keccak team has published, in one tree

The eXtended Keccak Code Package, also called the Xoodoo and Keccak Code Package, is a repository that gathers different free and open source implementations of the cryptographic schemes defined by the Keccak team.

The scope is the whole family, and the documentation is explicit about what is in it. The Keccak sponge function family is the core. Around it sit the SHAKE extendable output functions and the SHA-3 hash functions from FIPS 202, and the cSHAKE, KMAC, ParallelHash and TupleHash functions from NIST SP 800-185. There are the fast TurboSHAKE and KangarooTwelve extendable output functions, the Kravatte pseudo-random function and its modes, and the SHAKE- and TurboSHAKE-Wrap and -BO authenticated encryption schemes. Then the Xoodoo permutation, the Xoofff pseudo-random function and its modes, which the documentation marks as experimental, and Xoodyak, which is a submission to the NIST lightweight crypto standardisation process.

That last set of labels is a good guide to how to read the whole package. Some of what is here is a ratified standard, and some of it is a research artefact or a draft submission. The package does not separate them into different trees; the descriptions in the headers are where the distinction lives.

One decision is worth knowing about. The project decided to remove Ketje and Keyak from the XKCP, so if you are looking for those older authenticated encryption designs, they are not in the current repository.

## libXKCP is the library, and the services split into two layers

The code in the repository can be built as a library called libXKCP, and that library is organised around two kinds of service.

The low level corresponds to the Keccak-f[1600] permutation and basic state manipulation. The low level services provide an opaque representation of the state together with functions to add data into it and extract data from it, and together with the permutations themselves they implement the state and permutation interface, abbreviated SnP. The permutations implemented there are Keccak-f[1600], Keccak-p[1600, 12 rounds] and Xoodoo, and in lib/low you find implementations for different platforms, with the KeccakP-1600 directory holding the permutation used by the six approved FIPS 202 instances and the Xoodoo directory holding Xoodoo. There are also parallelised implementations using SIMD instructions, and for those the parallel state and permutation interface, PlSnP, applies.

The high level contains the constructions and the modes built on top: sponge functions, hashing, authenticated encryption. The header list is long. SimpleFIPS202 gives the six approved FIPS 202 instances through simple functions. KeccakHash gives the same instances plus any Keccak instance based on Keccak-f[1600], through a more advanced interface that proposes a message queue in the init, update, final style and supports bit-level inputs. There are SP800-185 for the cSHAKE, KMAC, ParallelHash and TupleHash functions, KeccakSponge, KeccakDuplex, KeccakOD for overwrite duplex objects, and KeccakPRG, a pseudo-random generator based on the duplex objects. TurboSHAKE and KangarooTwelve have their own headers, ShakingUpAE covers the Wrap and BO authenticated encryption schemes, Kravatte and Xoofff each ship with their modes, and Xoodyak covers hashing, encryption, MAC computation and authenticated encryption.

The selection logic is worth internalising because it recurs. In the parallel case the hierarchy first selects a permutation, or a permutation plus a degree of parallelism, and then a given implementation. So lib/low/KeccakP-1600-times4 holds four parallel instances of the permutation, and the AVX2 subdirectory of it holds a 256-bit SIMD implementation for AVX2.

## Building means one submodule step and a target specific make

Before building, the submodules have to be initialised and fetched, and the documentation names the command:

```bash
git submodule update --init
```

After that, the quick answer for building libXKCP is a single make target:

```bash
make <target>/libXKCP.so
```

The target is replaced with the actual target, with x86-64 and ARMv6M given as examples, and the .so suffix can be replaced with .a for a static library or with .dylib for a dynamic library on macOS. The full list of targets is in the section on how to build the XKCP.

If the compiler supports it, you can add EXTRA_CFLAGS="-march=native -mtune=native" at the end of the command line, so the code is further optimised for the platform on which it is compiled. That is a build time decision with a consequence worth naming: a binary built that way is tied to the machine that built it, which is fine for a benchmark and wrong for a distributed artefact.

The build system itself is small at the top. The root Makefile sets XKCBpath to support/XKCBuild and includes src/Main.makefile from there, so the real build logic lives in a support directory alongside a Makefile.build, a Makefile.ci and a CI directory. The repository also carries .travis.yml, a .gitmodules file, and a doc/ directory with the header documentation, including SnP-documentation.h and PlSnP-documentation.h for the two low level interfaces.

## Self-tests, benchmarks and a command line hasher

Alongside the library, the package ships the things you need to convince yourself the code works and to compare schemes.

The self-tests live in tests/UnitTests/main.c and are described as ensuring that the implementation is working properly. There is a benchmarking tool at tests/Benchmarks/main.c to measure the timing of the various schemes, which is the reference point for anyone comparing a SIMD implementation against a portable one, or a twelve-round TurboSHAKE against the full permutation.

There is also KeccakSum, in util/KeccakSum/KeccakSum.c, which computes a hash of a file or of multiple files. That is the piece with a life outside the library: a file hasher is something you can point at a build artefact or a release tarball, and it is the fastest way to sanity check that the library is wired up correctly on a new target.

The repository also holds a Standalone/ directory, which the documentation describes as containing some standalone implementations, separate from the libXKCP build.

One documentation artefact outside the source tree is worth mentioning, since it explains the library without being code. usage-example.md is referenced from the documentation set, and the doc/ directory carries the header level documentation for the sponge, duplex, overwrite duplex, pseudo-random generator, ShakingUpAE and Xoodyak interfaces, each in its own documentation header.

## Choosing between the interfaces is the real design decision

The high level services are not variations on the same function. They are different ways of using a sponge, and choosing between them changes both the API and the guarantees you get.

SimpleFIPS202 is the simple path: the six approved instances, SHAKE128, SHAKE256 and the SHA-3 hashes, through plain functions. KeccakHash is the same set plus any Keccak instance, but through a message queue in the init, update, final shape, with support for bit-level inputs when you need them. For a project that only needs SHA-256 style hashing with a different name, the simple interface is enough; for something that needs to absorb a stream of odd sized chunks, the queued interface is the one that does not force you to buffer.

The construction families differ in the same way. KeccakSponge covers the sponge functions with or without a message queue. KeccakDuplex covers duplex objects, and KeccakPRG is built on top of duplex objects, so a pseudo-random generator here is a duplex in a different mode. KeccakOD is the overwrite duplex, where the state is written rather than XORed, which is a different starting assumption about what you are hashing.

KangarooTwelve is a fast and parallelizable hashing mode based on TurboSHAKE and Sakura coding, which is a different structure again from the sponge, and Xoodyak is a lightweight scheme that can be used for hashing, encryption, MAC computation and authenticated encryption, aimed at constrained devices.

And then there is the mode taxonomy that runs through several of them, with SANE, SANSE, WBC and WBC-AE appearing under both Kravatte and Xoofff. Those are the mode wrappers on top of a pseudo-random function, and they are the part of the API you have to read rather than guess.

## Where XKCP is the wrong choice

Three limits are structural, and one is about the nature of the package.

The first is that this is reference material, organised for study and comparison. The interface surface is wide, the naming is dense, and you are expected to pick a target, then a permutation, then an implementation layer, then a construction, then a mode. That is the right structure for a cryptographer reading a specification and the wrong structure for a service that wants one function to hash a password.

The second is that not everything in the tree is a settled standard. Xoofff is labelled experimental, Xoodyak is a submission to the NIST lightweight crypto process, and the Wrap and BO authenticated encryption schemes are recent enough to be described by an eprint link. A package that deliberately contains drafts is a package you have to read carefully before you build on it.

The third is that the removal of Ketje and Keyak shows the contents move. The tree is not a permanent contract, and a project that tracks the Keccak team's current output will change under you.

The practical alternative for most applications is a single vetted implementation of the one scheme you need, from a library that is maintained as a product. The difference in approach is that XKCP gives you the reference code and every experimental sibling, while a product library gives you one hardened path with a stable API and somebody else's responsibility for the constant time behaviour. If your interest is in implementing or studying Keccak, XKCP is the right address. If your interest is in hashing a string, it is a lot of package for the job.

## Licence, maintenance and where the code actually lives

The licence field on the repository is recorded as a custom licence that GitHub cannot classify, and the LICENSE file at the root is the text that governs use. That is worth reading before you vendor the code, because the package is explicitly a collection of implementations contributed by the Keccak team and its collaborators, and the terms for the collection as a whole are what you are relying on.

On maintenance, the repository is not archived and the last push was on 2026-09-25, so the tree is still being worked on. There are no GitHub releases at all, which is consistent with how the project is consumed: you clone it, initialise the submodules, and build the target you need. The presence of a CI directory, a Makefile.ci and a .travis.yml shows the build matrix is exercised automatically, and the Makefile.build file alongside the root Makefile is where the target list is maintained.

The tree structure is worth knowing before you navigate it. lib/ holds the library sources, split into lib/low for the permutations and lib/high for the constructions. doc/ holds the header documentation, support/ holds the build system under XKCBuild, tests/ holds the self-tests and benchmarks, util/ holds the utilities, Standalone/ holds the standalone implementations, and CI/ holds the continuous integration configuration. The submodules matter in practice, because a checkout without them builds nothing, and the git submodule update --init step is not optional.

## Conclusion

Adopt XKCP if you are implementing a Keccak based scheme, benchmarking a variant, or want the reference code the standard was written against, and you are prepared to pick a target and an implementation layer yourself. Do not adopt it as the crypto dependency of a product, because the package is organised for study and comparison rather than for a hardened, audited API, and several of the schemes in it are experimental or submission drafts. Verify first that the scheme you need is in the current tree, since Ketje and Keyak were removed from XKCP, that the licence file covers your intended use, and that you have run the bundled self-tests for the target you built.

## FAQ

### What is the XKCP and what does it contain?

The eXtended Keccak Code Package gathers the Keccak team's free and open source implementations of their cryptographic schemes, including the Keccak sponge family, the FIPS 202 SHAKE and SHA-3 functions, the NIST SP 800-185 functions, TurboSHAKE, KangarooTwelve, Kravatte, the Xoodoo permutation, Xoofff and Xoodyak. The code can be built as the libXKCP library.

### How do I build libXKCP?

Initialise and fetch the submodules with git submodule update --init, then run make <target>/libXKCP.so, replacing the target with the real one such as x86-64 or ARMv6M. The .so suffix can be changed to .a for a static library or .dylib on macOS, and EXTRA_CFLAGS="-march=native -mtune=native" can be added for platform specific optimisation.

### What is the difference between the SnP and PlSnP interfaces?

The state and permutation interface, SnP, provides an opaque state with functions to add data into it and extract data from it, together with the Keccak-f[1600], Keccak-p[1600, 12 rounds] and Xoodoo permutations. The parallel interface, PlSnP, applies to parallelised implementations using SIMD instructions, such as the AVX2 implementation for four parallel Keccak-p[1600] instances.

### Which XKCP schemes are experimental rather than standardised?

The documentation marks Xoofff and its modes as experimental, and describes Xoodyak as a submission to the NIST lightweight crypto standardisation process. It also notes that Ketje and Keyak were removed from the XKCP.

### What utilities come with the XKCP package?

The package contains self-tests in tests/UnitTests/main.c that ensure the implementation is working, a benchmarking tool in tests/Benchmarks/main.c for timing the various schemes, and KeccakSum in util/KeccakSum/KeccakSum.c, which computes a hash of a file or of multiple files.

## Sources

- [Issues](https://github.com/XKCP/XKCP/issues)
- [README](https://github.com/XKCP/XKCP/blob/master/README.md)
- [XKCP/XKCP on GitHub](https://github.com/XKCP/XKCP)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xkcp-xkcp