bad-hashish: a tool for recursively, remotely multi-hashing files

"recursively" meaning that files inside archives (.zip, .tar.gz) are hashed without extracting everything to disk.

"remotely" meaning that large remote (HTTP/HTTPS) files can be hashed in a streaming fashion without saving to disk.

"multi-" meaning that mulitple hash algorithms are computed in a single pass.

There are other ways to do most of these; in un-UNIX-y fashion (for now) this tool does them all together.

Planned Features

  • sha1, sha256, sha512, md5, blake2b
  • support base64, base32, hex (upper/lower), etc
  • can recurse on .tar and .zip (and more?) without hitting disk
  • can stream files via HTTP(S) without hitting disk
  • variable output (json, tsv, etc)


  • dat, ipfs, zsync index computations
  • simhash/minhash/etc, for plain text https://github.com/bartolsthoorn/simhash-rs
  • support piping out to arbitary other commands (eg, for pdf extraction simhash, image hash...) https://github.com/abonander/img_hash

Planned Libraries

rust: - zip - tar + flate2 - tree_magic - rust-crypto - crc - clap - error-chain - reqwest - log (or slog?) - rayon (for parallelization?) - something json - csv (xsv?) - data-encoding

Minimum Viable Version

Parse arguments as local files or URLs. Either way, start reading/streaming data and hand off pipe to a thing that consumes 4MB chunks at a time and hashes.

Next, add parallelization (rayon?) for hashes.

Output as space-separated (default), csv, or json, one line per file.


hashish some_file.txt

cat zip_urls.txt | parallel -j8 hashish --recurse-only {} > all_hashes.txt

Arguments: - chunk size - recurse into files or not - output format - cores to use?

Later Thoughts

Limited by {CPU, disk, network}? Where to parallelize? Data locality.