# Haiti: identifying a hash by its shape, from a command line or a Ruby library

> Haiti is a Ruby CLI and library that takes a hash and tells you which algorithm probably produced it, covering more than 675 hash types and including references to the hashcat and John the Ripper modes, with a gem install and a Docker image.

**noraj/haiti** — :key: Hash type identifier (CLI & lib)

- Repository: https://github.com/noraj/haiti
- Website: https://noraj.github.io/haiti/
- Stars: 1,006 · Forks: 62
- Language: Ruby
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/noraj-haiti

## What the tool is for, in one line

Haiti is a CLI tool and library to identify hash types. That is the whole job, and the name spells it out: HA, sh, I, den, T, if, I, er, which is a deliberately strained acronym of hash identifier.

The use case is the moment in a security assessment where you have a string of hex characters and no idea what produced it. A hash of unknown type is a hash you cannot attack efficiently, because every cracking approach depends on the algorithm and on whether the input was salted. Knowing that a digest is bcrypt rather than MD5 changes what you do next entirely.

The project is Ruby, published as a gem, and the tool ships in two forms. There is a command line tool, and there is a library you can call from Ruby code. The documentation site is noraj.github.io/haiti, and the project is MIT licensed.

The author is Alexandre ZANNI, who published under the handle noraj, and the project is forked from Orange-Cyberdefense/haiti. That lineage is worth noting because it explains the shape of the thing: an existing identification tool that was taken, modernised and extended, rather than something built from scratch. The current versions follow that: v4.0.0 from 2026-01-01, v3.0.0 from 2025-02-02, and v2.1.0 from 2023-11-12, the last of which carries the release note haiti goes fzfffff.

The repository is not archived and the last push was on 2026-10-15, so the work is current even though the last release was in January.

## The feature list, and what 675 types actually means

The features are listed in five lines, and each one carries weight.

675+ hash types detected. That number is the headline, and it is the thing to interrogate. Identification works from the shape of the digest: its length and character set narrow the candidates. The total number of types is a direct measure of the tool's coverage, a wide surface rather than a deep one per algorithm.

Modern algorithms supported, with SHA3, Keccak and Blake2 named as examples. This is the part that separates a current tool from one written in 2015, because SHA3 and Keccak differ only in a domain separation byte and confuse identification tools that were never taught the difference. Blake2 is a different family again.

Hashcat and John the Ripper references. This is a feature rather than an integration, and the distinction matters. Haiti does not crack hashes and it does not ship the cracking modes, it carries references, which means it can tell you that a given hash corresponds to a mode number in one of those tools, which is what you actually need to copy into a command line.

CLI tool and library. Both forms ship, and the library is the one worth understanding, because the tool is a thin wrapper over it.

And Hackable, which is listed as a feature in its own right. That word means the project intends to be extended, and it is consistent with the layout of the repository, where the hash definitions live in a data directory rather than being hard-coded in the logic.

## Installing the gem, and the other packaging routes

The install is one command:

```plaintext
$ gem install haiti-hash
```

Note the gem name, haiti-hash, which is not the same as the repository name, haiti. That is the kind of detail that wastes ten minutes if you assume they match.

The documentation has a dedicated installation page listing more methods, and the README names two of them, Docker and Debian, with openSUSE also mentioned, so the project is packaged for Linux distributions as well as for RubyGems. The packaging status badge points at repology, which tracks the distribution packages of a project, so you can see which distributions carry it and at what version before you try to install one.

The Docker route is documented in the repository itself, in a Dockerfile and a docker-compose.yml. The compose file is minimal, one service, built from the local context with a Dockerfile that takes a HAITI_VERSION build argument, and the image tag is noraj/haiti:4.0.0. The Dockerfile is based on ruby:4.0.7-alpine3.23 and is labelled as the official verified image, with the OCI metadata fields for title, description, authors, vendor, documentation, source and licence set explicitly.

The Dockerfile also shows the two things a containerised CLI should get right. It installs the gem with a pinned version and --no-document so the image does not carry the RDoc output, and it creates an unprivileged user with adduser -s /bin/true -u 1337 -D -H noraj, then switches to it with USER noraj. The shell is set to /bin/true, so the account has no interactive shell at all, and there is no home directory. The default command is the tool with -h, so running the image with no arguments prints the help.

## The repository layout, and where the hash data lives

The top level of the repository is conventional for a Ruby gem with more than one distribution channel.

There is a haiti.gemspec, a Gemfile and a Gemfile.lock, and a Rakefile for the task runner. The code is in lib, the command line entry points in bin, and the test suite in test. There is a man directory, so the tool ships a manual page, which is the Unix convention and a sign that the author expects it to be used from a shell by people who expect man pages.

The interesting directory is data. The hash type definitions are kept there rather than embedded in the code, which is what makes the tool hackable in the sense the README claims. Adding a new algorithm means adding a definition, not editing a dispatch table, and the number of supported types can grow without the logic changing. The documentation site is generated from these definitions, which is why the site can list what the tool knows.

Then there is the docs directory with the site sources, and the mkdocs setup, plus a packages directory for the distribution packaging, and docker-compose.yml for the container workflow.

The tooling is a mix of eras. There is a .rubocop.yml for the linter, a .yardopts and a .yardopts-dev for the documentation generator, a .tool-versions file for version management, and a .editorconfig for whitespace. The .tool-versions file in particular tells you the project pins its Ruby version, and the GitHub workflow badge points at a ruby.yml workflow, so the CI runs on a specific Ruby rather than a range.

## Where the value ends, and what to check first

The first limitation is the obvious one, and it is worth stating plainly: Haiti identifies, it does not crack. The Hashcat and John the Ripper support is a reference to their mode identifiers, not a cracking engine, and a project built for identification will not grow one. If what you need is to recover a password, this is the first step and then a different tool.

The second limitation is that identification is a guess. A hash type identifier works by pattern and by test vector, so a 32 character hex string can be MD5 or it can be half of a SHA-256, and a tool that reports several candidates is being honest rather than broken. The output is a shortlist, and the decisions you make with it should not assume the shortlist is complete.

The third limitation is the number 675. Coverage is wide, and wide coverage has a cost: each candidate has to be checked against the digest, so on a large set of hashes the work adds up.

The fourth is about maintenance. The project is a fork, and a fork's upstream relationship determines whether fixes flow in one direction. The recent release history, v2.1.0, v3.0.0 and v4.0.0 across three years, shows active development, and the last push on 2026-10-15 is more recent than the last release, so there is work in the tree that is not yet in a gem.

For a security tool, one more check is worth doing yourself. The project is listed in the Rawsec CyberSecurity Inventory, and the homepage and documentation site are the places to confirm what the current version knows and how the tool wants to be used, since the documentation page also holds the reasons Haiti was created and the comparison with the other tools, which is where the reasoning about scope lives.

## Conclusion

Haiti fits a security analyst or CTF player who has an unknown hash and needs to know which algorithm to attack it with, and it fits a Ruby codebase that wants the same identification logic without shelling out to a separate binary. It is a poor fit if you need to crack the hash rather than classify it, since identification is the whole job here. Before adopting, install the gem and check the documentation site, which holds the reasons the project was created and a comparison with the other tools, and note that the library is the more durable surface since the project describes itself as hackable and the CLI is a thin layer over it.

## FAQ

### What is Haiti and what does it do?

Haiti is a CLI tool and library to identify hash types. It takes a hash and reports which algorithm probably produced it, covering more than 675 hash types including modern ones such as SHA3, Keccak and Blake2, and it includes references to the Hashcat and John the Ripper modes.

### How do I install Haiti?

Run gem install haiti-hash. The documentation installation page lists other methods including Docker, Debian and openSUSE, and the repository ships a Dockerfile and a docker-compose.yml with the image tagged noraj/haiti:4.0.0.

### Does Haiti crack hashes?

No, it identifies them. The Hashcat and John the Ripper support is a reference to their mode identifiers so you know which mode to use, not a cracking engine. A hash type identifier matches the digest's format against known patterns, so the result is a shortlist of likely types rather than a certainty.

### Who maintains Haiti and where did it come from?

It is made by Alexandre ZANNI, who publishes as noraj, and it is forked from Orange-Cyberdefense/haiti. The project is MIT licensed, the homepage and documentation are at noraj.github.io/haiti, and the last push was on 2026-10-15 with the most recent release v4.0.0 from 2026-01-01.

## Sources

- [License: MIT](https://github.com/noraj/haiti/blob/master/LICENSE)
- [noraj/haiti on GitHub](https://github.com/noraj/haiti)
- [Project website](https://noraj.github.io/haiti/)
- [README](https://github.com/noraj/haiti/blob/master/README.md)
- [Releases](https://github.com/noraj/haiti/releases)

---

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