Four More Hashes, and a Verify That Asks Which One

Hashing is the quiet part of most pipelines. A file gets a fingerprint before it is stored, an integrity value is checked after a download, a record is compared to a copy somewhere else. The five algorithms we had covered most of that work, and the same three requests kept coming back anyway: a standard that asks for SHA-3, a catalog that stores Whirlpool fingerprints, and a client that wants BLAKE2 because it is fast and gives the same length as SHA-256. All three are answered now.

What was added

Four endpoints, each shaped exactly like the five before them. Send JSON with a data field, a text/plain body, or a file in a multipart field named file. The answer is one key, named after the endpoint, holding the hexadecimal digest.

curl -s -X POST https://aisenseapi.com/services/v1/sha3_256_hash \
  -H "Content-Type: application/json" \
  -d '{"data":"abc"}'

{"sha3_256_hash":"3a985da74fe225b2045c172d6bd390bd855f086e3e9d525b46bfe24511431532"}

The bytes are hashed as sent. Nothing is trimmed, and an empty input is refused with 400, the way the rest of the family refuses it. BLAKE2b-256 means BLAKE2b run with a 32 byte output, which is a different value from the first half of BLAKE2b-512; the name says which one you get. JSON bodies are accepted up to 256 KB, and a file travels as an upload. Nothing you send is stored. The request log keeps the status and how long the answer took, and no part of the input.

The length stopped being enough

hash_verify compares data against a hash and tells you whether they agree. Until today it worked out the algorithm from the hash itself: an integer meant CRC32, and a hex string was mapped by length, 8 for CRC32, 32 for MD5, 40 for SHA-1, 64 for SHA-256 and 128 for SHA-512. That trick relied on every length naming exactly one algorithm, and the four new ones break it. SHA3-256 and BLAKE2b-256 are 64 characters like SHA-256. SHA3-512 and Whirlpool are 128 like SHA-512.

So the endpoint takes an algorithm field. It is optional for the first five, where the old rule still applies, and required for the four new ones. Without it, a BLAKE2b hash is read as SHA-256, the comparison fails honestly, and the answer shows what the data hashes to under SHA-256 so the mistake is visible rather than silent.

POST /hash_verify
{"data":"abc","hash":"bddd813c634239723171ef3fee98579b94964e3bb1cb3e427262c8c068d52319","algorithm":"blake2b"}
{"match":true,"algorithm":"blake2b","computed":"bddd813c634239723171ef3fee98579b94964e3bb1cb3e427262c8c068d52319"}

The same hash with no algorithm named: the length picks SHA-256
{"data":"abc","hash":"bddd813c634239723171ef3fee98579b94964e3bb1cb3e427262c8c068d52319"}
{"match":false,"algorithm":"sha256","computed":"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad"}

A mismatch is a result, not an error, and computed is always included. An algorithm that is named but does not fit the hash is an error: a 64 character hash sent as sha3_512 gets 400 with a fix saying that SHA3-512 hashes are 128 characters. The names are md5, sha1, sha256, sha512, crc32, whirlpool, sha3_256, sha3_512 and blake2b, and the hyphenated spellings sha3-256 and sha3-512 are accepted too.

Checked before writing

We sent the string abc to each of the four endpoints from outside, on the live service, and compared the answers with the test vectors published for each algorithm: FIPS 202 for the two SHA-3 sizes, the Whirlpool reference, and the BLAKE2 reference implementation for the 32 byte output.

The same input as text/plain gave the same SHA3-256. hash_verify with blake2b named answered a match, the same hash with no name was read as SHA-256 and answered no match with the SHA-256 value shown, and a wrong length for a named algorithm was refused with 400 and a fix. Each answer came back in between 0.16 and 0.30 seconds from a laptop in Norway, over a fresh TLS connection every time, which is the connection cost rather than the hashing.

MCP, clients and pages

The hash_data tool on the free MCP server takes all nine algorithm names, and verify_hash takes the optional algorithm the same way the REST endpoint does. The server reports version 1.9.1, and the agent guide it serves as a resource is at 1.4.1 with the same wording. In the public repository, the Python and JavaScript clients and the OpenAI tool definitions carry the four new functions, and each algorithm has its own page: SHA3-256, SHA3-512, BLAKE2b and Whirlpool.