Manpage
Table of Contents
NAME
Jacksum - a comprehensive data integrity and message digest framework
VERSION
4.0.0
SYNOPSIS
jacksum [OPTION]... [FILE]...
DESCRIPTION
Jacksum (JAva ChecKSUM) is a comprehensive data integrity and message
digest framework written entirely in Java. It is free, open source,
cross-platform, feature-rich, multi-threaded, and it supports a command
line interface that makes hash functions available to you to solve
particular tasks the smart way.
Jacksum covers many types of use cases in which hash values make sense:
- Calculating hash values/fingerprints
- of almost any input:
files, file trees, command line arguments, plain strings,
encoded strings, console, standard input, NTFS ADS, pipes,
sockets, doors, partitions, and disks
- Generating and persisting check lists resp. wanted lists
- Generating random pseudo numbers
- Generating reproducible, unique, secure passwords
- Verifying data integrity
- Finding any OK/failed/missing/new files
- Performing a strict integrity verification aka audit
- Finding objects
- Finding strings that match a hash
- Finding files by their fingerprints (positive matching)
- Finding files that do not match certain fingerprints (negative matching)
- Finding all duplicates of a file by its hash value
- Finding the algorithm(s) that generated a certain hash value
- Gathering information
- Gathering detailed hash algorithm information
- Investigating CRC polynomials
- Investigating HMAC parameters
In order to achieve the goals above, Jacksum supports four major areas
- Support for algorithms
- 586 algorithms (crypto hash functions, CRCs, and checksums)
- HMAC support for 490+ hash functions
- Customizable CRCs from 1 to 64 bit width
- Cross-platform
- 70 command line options to control Jacksum's behavior
- Cross-platform executability with identical behavior
- Multi-threading for parallel hash calculations to take advantage of
multiprocessors and multi-core processors
- Multi-threading for parallel data reads in order to take advantage of
faster data access speed of SSD storage
- Comprehensive I/O control
- Recursive traversal with depth control, policies to follow symbolic
links on files and/or folders, and file system cycle detection
- Wildcard support
- Creation of checklists with check values such as checksums,
file size, timestamp and file name
- 18 predefined standard styles for reading and writing check files
- 15 predefined standard styles for reading and writing wanted lists
- 17 different encodings for representing hash values
- 6 predefined styles for representing file timestamps
- 170+ different character sets to read and write check files and
wanted lists correctly
- Fully customizable output format on demand
- Documentation
- 10000+ lines of manpage with descriptions, examples, and compatibility
lists for all supported algorithms
May the hashes be with you, always!
OPERATING MODES OVERVIEW
Jacksum selects the appropriate operating mode dependent on the options
and parameters that you set. See the OPERATING MODES EXPLAINED section
for details.
Calculate hash values
Calculate hash values from files
jacksum [-a <algorithms>] [OPTION]... FILES
Calculate hash values from user input
jacksum [-a <algorithms>] {--quick|-q} <sequence>
[OPTION]...
Calculate hash values from strings stored in files
jacksum [-a <algorithms>] --string-list <file>
[OPTION]...
Generate large random (pseudo) numbers
jacksum -a hmac:<algo>[:<trim-to-bit-width>] -k <seed>
--string-list <feed> -F "#HASH"
[OPTION]...
Generate unique secure reproducible passwords using a master password
jacksum -a hmac:<algo>[:<trim-to-bit-width]
-k <key> -q <sequence> -E <encoding>
[OPTION]...
Generate check lists
Generate a lightweight checklist (file sizes and names only)
jacksum --style sizes-and-names
[OPTION]... [FILES]
Generate a lightweight checklist (timestamps and names only)
jacksum --style timestamps-and-names
[{--timestamp|-t} <timestamp-format>]
[OPTION]... [FILES]
Generate a lightweight checklist (file sizes, timestamps, and names only)
jacksum --style without-hashes
[OPTION]... [FILES]
Generate a lightweight checklist (file names only)
jacksum --style names-only
[OPTION]... [FILES]
Generate a hash value checklist (hash values at least)
jacksum [[--style {bsd|bsd-r|sfv|gnu-linux|fciv|openssl-dgst|
openssl-dgst-r|solaris-digest|solaris-digest-v|hdb}] |
[--filesize {on|off}]
[{--timestamp|-t} <timestamp-format>]
[{--encoding|-E} <encoding>]
]
[OPTION]... [FILES]
Generate a full blown checklist (hash values, timestamps, file sizes, names)
jacksum {--style full|
--filesize on
{--timestamp|-t} <timestamp-format>
[{--encoding|-E} <encoding>]
}
[OPTION]... [FILES]
Generate wanted lists
Generate wanted lists
jacksum [[--style {full|bsd|bsd-r|sfv|gnu-linux|fciv|openssl-dgst|
openssl-dgst-r|solaris-digest|solaris-digest-v|hdb}] |
[--filesize {on|off}]
[{--timestamp|-t} <timestamp-format>]
[{--encoding|-E} <encoding>]
]
[OPTION]... [FILES]
Verify data integrity
Verify data integrity by reading a check list
jacksum {{--check-file|-c} <file> | --check-line <line>}
[--style <style>]
[OPTION]... [FILES]
Verify data integrity by reading a check list (strict, aka audit)
jacksum {{--check-file|-c} <file> | --check-line <line>}
[--style <style>] --check-strict
[OPTION]... FILES
Verify data integrity of user input by providing a hash value
jacksum {--quick|-q} <sequence> {--expect|-e} <hash>
[OPTION]...
Find strings and files
Find strings that match a hash value
jacksum --string-list <file> {--expect|-e} <hash>
[OPTION]...
Find files by a fingerprint, given by the user
jacksum {--expect|-e} <hash>
[OPTION]... [FILES]
Find files by their fingerprints, stored in wanted list
jacksum {--wanted-list|-w} <list>
[OPTION]... [FILES]
Find hash functions by knowing both the input and the hash value
jacksum {--algorithm|-a} unknown:<bits>
{--quick|-q} <sequence> {--expect|-e} <hash>
[OPTION]...
Gather information
Gather algorithm information
jacksum {--algorithm|-a} <algorithm> {--list|-l} [{--verbose|-V} <control>] |
{--help|-h} [<language>] [<algorithm>] |
--hmacs [{--verbose|-V} <vcontrol>] |
--info [{--algorithm|-a} <algorithm> [{--list|-l}]] [{--quick|-q} <sequence>]
Gather option information
jacksum [--exact] {--help|-h} [<language>] { options | <option> }
Gather parameter information
jacksum -h parameters
Gather encoding information
jacksum {--help|-h} [<language>] -E
Gather style information
jacksum {--help|-h} [<language>] --style
jacksum {--style|-C} <style> --info
Gather program version
jacksum [ {--version|-v} [{--verbose|-V} <vcontrol>] [--info] ]
jacksum [ {--help|-h} [<language>] version ]
Gather copyright information
jacksum --copyright
jacksum {--help|-h} [<language>] copyright
Gather license information
jacksum --license
jacksum {--help|-h} [<language>] license
Notes:
- FILES means "{{--file-list|-L} <file-list> | FILE} [FILE]..."
- FILE can be a regular file, a directory, any platform-dependent file,
or the hyphen (-) which represents standard input. For more
information, see section PARAMETERS.
- OPTION can be one of the supported options for a particular mode. See
OPERATING MODES, OPTION TYPES, and OPTION SUPPORT MATRIX for details.
OPERATING MODES EXPLAINED
Jacksum selects the appropriate operating mode dependent on the options
and parameters that you set. The options mentioned below are the minimum
options that trigger a particular mode. For each mode you can set many
more options. See also the sections entitled SYNOPSIS, OPTION TYPES,
OPTION SUPPORT MATRIX, and EXAMPLES.
1. Calculating hashes
For each mode in this section, the following option types are supported
for OPTION:
- Common Options
- Security Strength Options
- Hashing Performance Options
- Output Format Options
- Output Options
1.1 Calculating hashes from files
jacksum [OPTION]... FILES
Calculating hash values is usually the first step you take to be able to
check data integrity later on.
The hash calculation mode is enabled if you specify at least one file to
hash. FILES can be provided by a list (-L) and by program parameters.
If you specify the hyphen for FILES, Jacksum reads from standard input
channel.
The major features of this mode are the selection of a vast array of
algorithms and comprehensive format options to get the output to
meet your needs.
The following option types are also supported for OPTION:
- File List Options
- Directory Traversal Options
- I/O Performance Options
- Path Format Options
Examples:
> jacksum myfile.iso
> cat myfile | jacksum -
> jacksum .
> jacksum mydir/
> jacksum --file-list myfile.list mydir/ mydir2/ myfile*
> jacksum -a md5+sha256 --style bsd .
> jacksum -a crc32c+md5+sha256 -V all -r 1 --threads-reading 4
--threads-hashing max --header -F "#HASHES #FILENAME" .
1.2 Calculating hashes from user input
jacksum {--quick|-q} <sequence>
[OPTION]...
In this mode, you can specify the input data entirely on the command
line and calculate the hash(es) of it. You can also read secret data
from the console, and hash the secret.
The mode is enabled if you specify -q (or --quick).
The following option types are also supported for OPTION:
- Quick Mode Options
- Path Format Options
Examples:
> jacksum -q txt:"Hello World"
> jacksum -q password -a sha256 -E z85
Password: facebook.com <a strong master password>
> jacksum -q password -a hmac:sha256 -k password
Key (echo off): <enter the HMAC key here>
Password: <enter the secret message here>
1.3 Calculating hashes from strings
jacksum --string-list <file>
[OPTION]...
In this mode, hash values are calculated from multiple strings.
The following option type is also supported for OPTION:
- Hash Strings Mode Options
Example:
> jacksum --string-list words.txt
1.4 Generating [many] [large] random [pseudo] numbers
jacksum -a hmac:<algo>[:<trim-to-bit-width>] -k <seed>
--string-list <file> -F "#HASH"
[OPTION]...
This method is similar to the one described in section 1.3, but it's
used to generate large random pseudo-numbers. Here is how you can do it:
1. Use a unique set of strings in <file>.
2. Apply an HMAC (Hash-based Message Authentication Code) using a
compatible hash function.
3. Trim the HMAC to fit the desired bit-width of the random numbers.
4. Set the HMAC key as a seed to ensure randomness for the entire process.
5. Treat each string in <file> as an individual seed to generate a number.
6. Format each line to show just the hash value.
7. Encode the hash value in decimal form so that the hash value appears as a number.
Examples:
> jacksum -h | sort | uniq > strings.txt
> jacksum -a hmac:sha256:64 -k txt:run42 --string-list strings.txt -F "#HASH" -E dec
1.5 Generating reproducible unique secure passwords using a master password
jacksum -a hmac:<algo>[:<trim-to-bit-width]
-k <key> -q <sequence> -E <encoding>
[OPTION]...
This method can be used to generate unique and secure passwords.
The advantage is that you only have to remember ONE secure master
password. Yet, you can still use different, strong passwords for all
your accounts.
No password manager is required, because nothing is stored on disk,
the master password will be in your brain only. Even the generated
passwords are not stored somewhere, they will be regenerated on
demand.
The complete considerations for this method are described at
https://bit.ly/secure-passwords-with-jacksum
Here is how you can do it:
1. Apply an HMAC to make precalculated rainbow tables useless for
attack purpose
2. For the HMAC select a cryptographic, non-broken hash function
that generates a long enough hash value (e.g. SHA3-512)
3. Trim the HMAC to avoid revealing the entire hash to the website
which protects the actual master password.
4. The key of the HMAC is your master password (-k)
5. The message to be hashed (-q) contains the website address
and the master password (appending it is fine)
6. Apply the base64 encoding without padding to be compliant
with most website requirements with respect to password
complexity. In order to avoid padding for the base64 encoding
and without the need to use the special base64-nopadding
encoding, the number of encoded bytes (the hash) must be a
multiple of 3.
The example below will truncate the SHA3-512 hash value after 240 bits
that results in a 40 character password with at least three different
character categories (upper- and lowercase characters, numbers, and
sometimes even a special character).
Example:
> jacksum -a hmac:sha3-512:240 -8 -k password -q password -E base64
Key (echo off): <your-master-password>
Password: <a-webpage-on-the-internet> <your-master-password>
2. Verifying data integrity
For each mode in this section, the following option types are supported
for OPTION:
- Common Options
- Security Strength Options
- Hashing Performance Options
- Output Options
2.1 Verifying file integrity
jacksum {{--check-file|-c} <file> | --check-line <line>}
[OPTION]... [FILES]
The data/file integrity verification mode is enabled if you specify
the option -c (or --check-file) or the option --check-line.
You can specify the style of the check-file by setting the option
--style. If one or more input lines are invalid, use --check-strict to
exit with a nonzero value after all warnings have been issued. Specify
the character set of the check-file using the option
--check-file-charset. To ignore particular lines from the check file,
use the option --ignore-lines-starting-with-string.
Data integrity ensures that data items have not been changed, destroyed,
or lost in an unauthorized or accidental manner since they were created,
transmitted, or stored. In other words, you can detect ok, failed and
missing files, and if you specify FILES you can detect new files as
well. For detecting missing or new files, hashing is not necessary.
You can control what you are searching for (e.g. failed and
new files only) by setting the option called "--list-filter" to an
appropriate value.
FILES can be provided by a list (-L) and by program parameters.
If you specify the hyphen for FILES, Jacksum will read from the standard
input channel.
The following option types are also supported for OPTION:
- File List Options
- Check/Integrity Verification Mode Options
- Input Format Options
- Directory Traversal Options
- I/O Performance Options
Examples:
> jacksum -c my.hashes
> jacksum -c my.hashes .
> jacksum -c my.hashes --list-filter none,missing,new .
> jacksum -a crc32c+sha256+whirlpool --style bsd -c my.hashes .
2.2 Verifying file integrity (strict)
jacksum {{--check-file|-c} <file> | --check-line <line>} --check-strict
[OPTION]... FILES
A strict check guarantees that no file has been changed,
no file has been added, and no file has been removed.
To perform a strict check, the following conditions must be met:
- FILES must not be omitted, because we want detect new files if
there are any
- FILES must be set to the same folder which was specified as
output during the creation of <file>.
- the check file <file> must not be stored in FILES, because
otherwise <file> would be detected as a new or modified file.
- the option --list-filter must be set to all (default), because
we do not want to filter anything in strict mode
- the option -V must be set to summary (default for -c)
- the option --scan-ntfs-ads should be set on Windows, because
one or more ADS could have been added which we wouldn't detect
otherwise.
- the option --scan-all-unix-file-types should be set on GNU/Linux
and Unix, because we want to detect any non-regular files that
have been added to FILES
- the option --check-strict should be set so that the exit code
reflects the actual outcome of the verification
The summary prints an additional line called "strict check". The value
for "strict check" can become PASSED or FAILED. If the value is set to
PASSED, it means that
- all files listed in <file> have been read, hashed and verified
against the current objects on the file system
- no file in <file> have been removed
- no additional files (regular or non-regular) have been added to
FILES
The following option types are also supported for OPTION:
- File List Options
- Check/Integrity Verification Mode Options
- Directory Traversal Options
- I/O Performance Options
Example:
> jacksum -a sha256 -c ../.SHA256 --check-strict --scan-ntfs-ads .
2.3 Verifying the integrity of user input
jacksum {--quick|-q} <sequence> {--expect|-e} <hash>
[OPTION]...
In this mode, you can specify the input data on the command line,
calculate the hash(es), and verify the integrity.
This mode is enabled if you specify both -q and -e.
The following option type is also supported for OPTION:
- Quick Mode Options
Examples:
> jacksum -a md5 -q txt:hello -e 5d41402abc4b2a76b9719d911017c592
> jacksum -a hmac:sha256 -q password -k password -e
60273a1e778ed009a6fb32fa11dbb16f905148fc2ec84a67f8a3b3a6cabaa9b7
3. Finding strings and files
3.1 Finding strings that match a hash
jacksum --string-list <file> {--expect|-e} <hash>
[OPTION]...
3.2 Finding files by their fingerprints
jacksum {{--wanted-list|-w} <list> | {--expect|-e} <hash>}}
[OPTION]... [FILES]
In "Wanted list" mode, you can find all files that match or do not
match a set of known hashes stored in a list file. In other words,
you can verify the integrity of a file, find files by their
fingerprints, or find all duplicates of a file.
This mode is enabled if you specify the option -w (or --wanted-list) or
-e (or --expect). The character set of <list> can be specified by
--wanted-list-charset.
To enable positive matching, set --match-filter to "positive", and
to enable negative matching, set --match-filter to "negative".
FILES can be provided by a list (-L) and by program parameters.
If you specify the hyphen for FILES, Jacksum will read from the standard
input channel.
The following option types are supported for OPTION:
- Common Options
- Security Strength Options
- File List Options
- Wanted List Mode Options
- Input Format Options
- Directory Traversal Options
- Hashing Performance Options
- I/O Performance Options
- Output Options
Examples:
> jacksum -a sha256 ./all-official-log4j-libs/ > /tmp/log4j.hashes
> jacksum -a sha256 -V nosummary -w /tmp/log4j.hashes /
MATCH /opt/serverapp/log.jar (log4j-core-2.12.0.jar)
> jacksum -w known.hashes --match-filter negative .
> jacksum -a sha256 -e b85286d9855f549ed9895763519f6a295a7698fb9c5c5345811b3eefadfb6f07
ubuntu-22.04-desktop-amd64.iso
> jacksum -a blake2b-64 -e a47fc96f87b6fb5a .
4. Finding hash functions by knowing both the input and the hash value
jacksum {--algorithm|-a} unknown:<bits>
{--quick|-q} <sequence> {--expect|-e} <hash>
[OPTION]...
In this mode, you can find the hash function that was used to produce a
hash. This mode is enabled if you specify -q, -e and -a unknown:<bits>
where <bits> specifies the width of the algorithm in question. <bits>
can be an integer from 1 to 1024.
The following option types are supported for OPTION:
- Common Options
- Security Strength Options
- Quick Mode Options
- Output Options
Example:
> jacksum -a unknown:16 -q hex:050000 -E hex -e d893
5. Gathering information
In these modes, some information is collected and the program is
terminated. See the OPTIONS section for more details on each option.
5.1 Gathering algorithm information
jacksum {--algorithm|-a} <algorithm> {--list|-l} |
{--help|-h} [<language>] [<algorithm>] |
--hmacs [-V <vcontrol>] |
--info [{--algorithm|-a} <algorithm> [{--list|-l}]] [{--quick|-q} <sequence>]
Examples:
> jacksum -a all --list --verbose summary
> jacksum -a all:256 -l
> jacksum -a all:crc -l --info
> jacksum -a all:crc -l -q "txt:the quick brown fox jumps over the lazy dog" --info
> jacksum --hmacs
> jacksum --info
5.2 Gathering option information
jacksum [--exact] {--help|-h} [<language>] { options | <option> }
Examples:
> jacksum -h -h
> jacksum -h -a
> jacksum -h options
> jacksum --exact -h -
> jacksum --exact -h --
5.3 Gathering parameter information
jacksum -h parameters
Examples:
> jacksum -h parameters
5.4 Gathering encoding information
jacksum {--help|-h} [<language>] -E
Examples:
> jacksum -h -E
5.5 Gathering style information
jacksum {--help|-h} [<language>] --style
jacksum --info [{--style|-C} <style>]
Examples:
> jacksum -h --style
> jacksum --info --style bsd
5.6 Gathering program version
jacksum [ {--version|-v} [{--verbose|-V} <vcontrol>] [--info] ]
jacksum [ {--help|-h} [<language>] version ]
Examples:
> jacksum -v
> jacksum --version
> jacksum -v --info info
> jacksum -h version
5.7 Gathering copyright information
jacksum --copyright
jacksum {--help|-h} [<language>] copyright
Examples:
> jacksum --copyright
> jacksum -h copyright
5.8 Gathering license information
jacksum --license
jacksum {--help|-h} [<language>] license
Examples:
> jacksum --license
> jacksum -h license
OPTION TYPES
Security Strength Options
This option controls the strength of the hashing procedure.
[{--algorithm|-a} <algorithm>]
[{--key|-k} <key>]
Check/Integrity Verification Mode Options
Those options control the data verification process.
See also Input Format Options.
{{--check-file|-c} <checkfile> | --check-line <line>} [
[{--charset-check-file|--check-file-charset} <charset>]
[--check-strict]
[--ignore-hashes]
[--ignore-sizes]
[--ignore-timestamps]
[--list-filter <filter>]
]
Wanted List Mode Options
Those options control the behavior of the "wanted list" mode.
See also Input Format Options.
{--wanted-list|-w} <list> [
[{--charset-wanted-list|--wanted-list-charset} <charset>]
[{--expect|-e} <hash value>]
[{--match-filter|--wanted-list-filter} <filter>]
]
Quick Mode Options
Those options control the behavior of the quick mode.
{--quick|-q} [<type>:]<sequence> [
[{--algorithm|-a} <algorithm>]
[{--expect|-e} <hash value>]
]
Hash Strings Mode Options
Those options adjust the behavior in the "hash strings"-mode.
--string-list <file> [
[{--charset-string-list|--string-list-charset} <charset>]
[{--ignore-lines-starting-with-string|-I} <string>]
[--ignore-empty-lines]
]
Information Gathering Mode Options
Those options print some specific information, and the app exits
afterwards.
[
{--algorithm|-a} <algorithm> {--list|-l} |
--copyright |
{--help|-h} [<language>] [<word>] [--exact] |
--hmacs [-V <vcontrol>] |
--info [{--algorithm|-a} <algorithm> [{--list|-l}]] |
--info [{--style|-C} <style>] |
--license |
{--version|-v} [-V <vcontrol>]
]
Common Options
Those options can be used almost by any operating mode.
[{--verbose|-V} <vcontrol>]
[{--list|-l}]
[--]
File List Options
Those options specify the way file list are to be read.
{--file-list|-L} <file-list> [
[{--charset-file-list|--file-list-charset} <charset>]
[--file-list-format <format>]
[{--ignore-lines-starting-with-string|-I} <string>]
]
Directory Traversal Options
Those options control which files are read during directory traversal.
By default, Jacksum traverses directory trees recursively. You can
control the walking depth by option -r. You can also set the
options -f and -d to disallow Jacksum from following symlinks
to files and/or directories. To scan platform dependent files,
you can use the options --scan-all-unix-file-types and --scan-ntfs-ads,
respectively.
[--recursive|-r <depth>]
[--dont-follow-symlinks-to-directories|-d]
[--dont-follow-symlinks-to-files|-f]
[--scan-all-unix-file-types]
[--scan-ntfs-ads]
Hashing Performance Options
Those options control the performance of hashing.
[{--algorithm|-a} <algorithm> [--alternative|-A]]
[--threads-hashing <threads>]
I/O Performance Options
This option controls the performance when reading files on SSDs.
[--threads-reading <threads>]
Path Format and File name Escaping Options
Those options adjust the format of path objects and control filename
escaping.
[--gnu-filename-escaping <boolean>]
[
--no-path |
[
{
--path-absolute |
--path-relative-to <path> |
{--path-relative-to-entry <number> {--file-list|-L} <list>}
}
[--path-separator|-P <char>]
]
]
Input Format Options
Those options specify the format of a check list resp. a wanted list.
[
[{--style|-C} <style>]
[
[--ignore-empty-lines]
[{--ignore-lines-starting-with-string|-I} <string>]
[{--separator|-s} <string>]
[--gnu-filename-escaping <boolean>]
[
[{--encoding|-E} <encoding>] |
[[{--hex-lowercase|-x}|{--hex-uppercase|-X}] [-g <count> [-G <char>]]]
]
[{--timestamp|-t} <format>]
[--filesize <boolean>]
[--legacy-stdin-name]
]
]
Output Format Options
Those options adjust the format of the output to meet your requirements.
[--header]
[
[{--style|-C} <style>]
[
[{--separator|-s} <string>]
[{--format|-F} <format>]
[
[{--encoding|-E} <encoding>] |
[[{--hex-lowercase|-x}|{--hex-uppercase|-X}] [-g <count> [-G <char>]]]
]
[{--timestamp|-t} <format>]
[--filesize <boolean>]
[--legacy-stdin-name]
]
]
Output Options
Those options control the output.
[--utf8|-8]
[--bom]
[
--stdout-charset <charset> |
[{--output-file|-o|-O} <file> [--output-file-charset <charset>]]
]
[
--stderr-charset <charset> |
[{--error-file|-u|-U} <file> [--error-file-charset <charset>>]]
]
OPTION SUPPORT MATRIX
The following table shows the option type in rows and the operating modes
in columns. If a cell is marked with an "x", it means that the operating
mode supports the option type.
Gather information |
Find hash functions | |
Hash strings | | |
Quick/verify one file | | | |
Quick/calculate one hash value | | | | |
Wanted list | | | | | |
Verify data/file integrity | | | | | | |
Calculate hash values and print them | | | | | | | |
| | | | | | | | |
| Option Type | | | | | | | | |
-------------------------------------|---|---|---|---|---|---|---|---|
| Common Options | x | x | x | x | x | x | x | x |
| Security Strength Options | x | x | x | x | x | x | x | x |
| File List Options | x | x | x | - | - | - | - | - |
| Wanted List Mode Options | - | - | x | - | - | - | - | - |
| Integrity Verification Mode Options| - | x | - | - | - | - | - | - |
| Quick Mode Options | - | - | - | x | x | - | x | - |
| Hash Strings Mode Options | - | - | - | - | - | x | - | - |
| Information Gathering Mode Options | - | - | - | - | - | - | - | x |
| Directory Traversal Options | x | x | x | - | - | - | - | - |
| Hashing Performance Options | x | x | x | x | x | x | - | - |
| I/O Performance Options | x | x | x | - | - | - | - | - |
| Path Format Options | x | - | - | x | - | - | - | - |
| Input Format Options | - | x | x | - | x | - | - | - |
| Output Format Options | x | - | - | x | - | x | - | - |
| Output Options | x | x | x | x | x | x | x | x |
----------------------------------------------------------------------
PARAMETERS
The following parameters are supported:
FILES on any platform:
Names of files and directories can be specified as many as desired.
Wildcards are supported, depending on the shell being used.
In hash calculation mode, if no parameters are given or if FILES is the
hyphen, Jacksum reads from the standard input channel in binary mode.
Starting with Jacksum 3.0.0, the recursive mode is enabled by default
for directories, and you can control the depth with the -r option.
FILES on Unix, and GNU/Linux:
On Unix (including macOS) and GNU/Linux, there are additional file types
available from which Jacksum can read:
- block devices (i. e. disks and partitions, e. g. /dev/sda,
/dev/sdb, /dev/sr0, etc. and /dev/sda1, /dev/sda2, etc. on
GNU/Linux; /dev/disk0, /dev/disk1, etc. and /dev/disk0s1, etc.
on macOS)
- character devices (e. g. /dev/null)
- named pipes (FIFOs)
- sockets
- doors (Solaris only)
Notes:
- Reading entire disks, partitions or special Unix file types may
require sudo or root privileges!
- Use the option --scan-all-unix-file-types to scan the Unix-
specific file types during recursively directory traversal.
- Reading copyright protected DVDs may lead to I/O errors.
- The operating system may permit or prohibit reading (and hashing) of
particular disks or partitions if they are in use (mounted).
- You should unmount block devices before reading from them, as failing
to do so may cause the device driver to flag the disk as defective,
and even a single bit difference could lead to a different hash value.
- To unmount disks use "umount" on GNU/Linux and
"diskutil umount" on macOS.
- To find disk identifiers enter "lsblk" on GNU/Linux and
"diskutil list" on macOS.
FILES on Microsoft Windows:
On Microsoft Windows, there are additional file types available from
which Jacksum can read:
- Partitions (e. g. \\.\c:)
- Hidden partitions which are not mounted by default,
such as the recovery partition or EFI partition
(e. g. \\?\Volume{4a343c6b-3576-5e5e-2072-303c6b352131}\)
- Disks, CD-ROMs, DVDs, etc. (e. g. \\.\PhysicalDrive0)
- RAM disks
- NTFS Alternate Data Streams on files
(e. g. my-file.txt:secret:$DATA)
- NTFS Alternate Data Streams on directories
(e. g., .\:secret:$DATA)
- The null-device (called "nul" on Microsoft Windows).
Notes:
- Reading data from raw disks and partitions usually require
administrator privileges!
- Use the option --scan-ntfs-ads to scan for any NTFS Alternate
Data Streams (ADS) during recursively directory traversal.
- Reading copyright protected DVDs may lead to I/O errors!
- To find PhysicalDrive IDs on Microsoft Windows, enter
the PowerShell command Get-PhysicalDisk. To find partition
drive letters and access paths, enter the PowerShell commands
Get-Volume and Get-Partition or use the "mountvol" command on
the Windows Command Prompt.
- Microsoft could change the syntax of the access paths without
any notice, or even prohibit access to particular raw disks
and/or partitions in update releases or in new versions of
Microsoft Windows.
OPTIONS
The following options are supported:
-a <algo>[+<algo>]... | all[:<length|string>] | unknown:<length>
--algorithm <algo>[+<algo>]... | all[:<length|string>] unknown:<length>
<algo>
Specifies the algorithm(s) to be used. Starting with version 3
of Jacksum, the default is sha3-256 if <algo> is omitted.
<algo> can be one of the following:
- A supported algorithm ID
- A customized CRC
- A keyed-Hash Message Authentication Code (HMAC)
A supported algorithm ID
Replace <algo> with one of the IDs that Jacksum understands.
Many algorithms support aliases to make their identification
easier to remember. To see a list of all supported algorithm
IDs, type
> jacksum -a all -l
To see a comprehensive description for each algorithm type
> jacksum -h algorithms
A customized CRC algorithm (crc:<crc>)
The pattern crc:<crc> allows you to define a customized
CRC by using a parameterized model. These customized IDs
aren't listed by `jacksum -a all -l`, but you can select and
use them. Learn more on this topic by typing
> jacksum -h crc:
A HMAC (hmac:<algo>[:<bits>])
The pattern hmac:<algo>[:<bits>] allows to calculate a HMAC,
a mechanism for message authentication using any iterated
cryptographic hash function in combination with a secret
shared key. Optionally, you can also truncate the HMAC by
specifying a value for <bits>.
Learn more on this topic by typing:
> jacksum -h hmac:
<algo>[+<algo>]...
Multiple algorithms can be selected by concatenating them with
the plus character.
Examples: "sha1+crc32", "sha512+sha3-512+blake2b-512",
"all:32+all:64", etc.
The new algorithm resulting from all concatenated algorithms
returns, by default, only one composite value consisting of all
chained hash values. This feature allows you to use any
combination of algorithms for any predefined standard style,
even if the style was designed to support only one algorithm.
Each file is read only once, even if multiple algorithms are
selected, in order to minimize I/O calls and improve
performance. Additionally, each algorithm can run in parallel if
the computer supports multi-threading.
You can control the performance behavior by setting the option
called "--threads-hashing".
If at least one "+" character is found after the option -a, the
output is normalized by a hexadecimal lowercase checksum and a
decimal file size is inserted.
Examples: "md5+", "sha256+", "sha3-256+"
You can disable adding the filesize by setting --filesize off.
You can customize the output behavior by using the options -E,
-F, -g, -G. Especially, take a look at the various tokens for
--format which allows you to highly customize the output to
meet your actual needs.
all[:<length|string>]
All or a particular group of algorithms can be filtered by a
length in bits or by a string.
All algorithms (all):
If you set <algo> to "all", all supported algorithms will
be used, meaning you can calculate hashes with hundreds
of algorithms by reading the input only once.
If "all" is used in calculation mode, the output is
normalized (if not customized) by a hexadecimal checksum and
a decimal file size.
Examples:
> jacksum -a all -l
> jacksum -a all --info
> jacksum -a all --info -l
> jacksum -a all -q txt:0123456789
> jacksum -a all -q txt:0123456789 -F "#ALGONAME{i}(#SEQUENCE) = #HASH{i}"
Several algorithms, filtered by bit length (all:<length>)
In order to use all algorithms that have a particular bit
length, you can use "all:<length>" where <length> must be a
multiple of 8.
Examples:
> jacksum -a all:224 -l
> jacksum -a all:1024 -l
> jacksum -a all:888 -l --info
> jacksum -a all:256 *.txt
> jacksum -a all:256 --style bsd *.txt
> jacksum -a all:256 -F "#ALGONAME{i}(#FILENAME) = #HASH{i}" *.txt
Several algorithms, filtered by a string (all:<string>)
In order to use all algorithms that match a particular
string, you can use "-a all:<string>" where <string> can be
any string. Both algorithm IDs and algorithm alias IDs will
be searched.
Examples:
> jacksum -a all:fnv -l
> jacksum -a all:skein -l
> jacksum -a all:sha3- -l --info
> jacksum -a all:whirlpool -F "#ALGONAME{i}(#FILENAME) = #HASH{i}" *.txt
unknown:<length>
If you only know the input and the output, and you want to know
the algorithm that has been used to produce the output,
you can set <algo> to unknown:<length>, replacing <length>
with the length of the digest in bits.
In that case, all supported algorithms will be tested to see if
there is one that can produce the expected output. Additionally,
a list of well-known CRCs will be checked, and finally, all CRC
algorithms will be tested by brute force (init and xorOut are
set to either all bits zero or all bits one while refIn and
refOut are set to either true or false for all potential
polynomials of the given length). Please be patient in case
of a brute-force session.
Both options, -q and -e, are required in this case.
See also -V, -e, -E, and -q.
Examples:
> jacksum -a unknown:16 -q hex:050000 -E hex -e d893
> jacksum -a unknown:128 -q "txt:Hello World" -X -e B10A8DB164E0754105B7A99BE72E3FE5
See also:
option -A
Available since:
The option -a is available since version 1.0.0 of Jacksum.
<algo>[+<algo>]... is supported since version 1.7.0 of Jacksum.
all:<length>, all:<string>, and unknown:<length> are supported since
version 3.0.0 of Jacksum.
-A
--alternative
By default, Jacksum uses algorithms provided by the Java API if
available, as these are optimized by your JVM vendor and usually
provide a very good performance.
If -A is set, Jacksum uses an alternative, pure Java implementation
of an algorithm, if available. Actually, Jacksum supports
alternative implementations for the following algorithms:
adler32, blake3, crc16, crc32, crc32_fddi, crc32c, fnv-0_32,
fnv-0_64, fnv-1_32, fnv-1_64, fnv-1a_32, fnv-1a_64, fugue224,
fugue256, fugue384, fugue512, md2, md5, sha-1, sha-256, sha-384,
sha-512, sha-512/224, sha-512/256, sha3-224, sha3-256, sha3-384,
sha3-512
If an algorithm has no alternative implementation, -A is ignored
for it and the standard implementation is used.
See also:
option -a
Available since:
version 1.5.0 of Jacksum.
--bom
Adds a Byte-Order Mark (BOM) to the output if either the
--charset-stdout or --charset-output-file option has been set to
one of the following charsets:
- GB18030
- UTF-8
- UTF-16BE
- UTF-16LE
- UTF-32BE
- UTF-32LE
If --bom is omitted, a BOM will not be written for the charsets
above, because a BOM is not required and is optional in those cases.
Note that if you set charsets UTF-16 or UTF-32 (no little endian LE
or big endian BE indicator), a BOM will be written in any case,
even if you don't set --bom, because it is required for those
charsets to have a BOM in the output. See also --utf8
Available since:
version 3.1.0 of Jacksum.
-c <file>
--check-file <file>
Verify files against a list of hashes, either from a former output
of Jacksum or from an output of a different hash application.
You need to set all non-default options that could generate <list>
again. The options -a, -E, -t, -d, -f, -x, -X may become
necessary; the option -F is ignored. The options -g and -G are not
supported, because grouped hash values cannot be parsed. The options
--wanted-list and -e are not supported either, because searching
files by wanted hashes is a different job than verifying files
against a list of hashes.
Hash values are compared without respecting upper and lower case,
except if an encoding with a case sensitive alphabet has been set
by -E, see also option -e.
A file size is compared in the unit that <list> stores it in. The
default format of the algorithms sum_bsd, sum_sysv, and sum_minix
stores the file size as a number of blocks, exactly as the BSD resp.
System V "sum" command does, so for those algorithms the file size
is verified block-wise. If you want it to be verified byte-wise,
create <list> with a style that stores the file size in bytes,
e.g. --style full.
If you have used option -F, or if the output of <list> is not in the
quasi-standard output format like
<encoded/formatted hash><blank>[<star>]<filename>
you can specify a parser file by using the --compat option.
The parser file must have all the necessary definitions to properly
parse <file>. For more information, see the -C resp. --style option.
Note that a second blank is not a marker, it is the first character
of the file name, because a file name is allowed to start with a
blank and a list that Jacksum has written stays verifiable that way.
A tool such as sha256sum writes such a second blank in its text mode
(and a star in its binary mode), so use --style gnu-linux to verify
a list that has been created by one of those tools.
If <file> is set to a single dash (-) Jacksum reads from stdin.
Use option --charset-check-file to specify the character set for
<file>.
You can use the option -I in order to ignore all lines that start
with a particular string in <file>.
If multiple hash values are stored in the check file for a file name
the last hash value will win that corresponds to that file name.
Entries are identified by the file they refer to, and not by the
way their path is spelled, so "a.txt" and "./a.txt" are duplicates
of each other, and such a file is read and verified exactly once.
If an entry that is replaced by a later one stores a different hash
value, file size, or timestamp, a warning is printed. The number of
duplicates is part of the summary.
To exclude files from being checked, just remove the lines from the
list. This can be done with "findstr /V" on Windows, and with
"grep -v" on both Linux and Unix. Example: check all files in
md5.check, but exclude any .iso files:
findstr /V .iso$ hashes.md5 | jacksum -E hex -a md5 -c -
For each file in <list>, Jacksum shows the status of the file's
integrity and the filename. The status can be one of the following:
OK
the file's fingerprint has no changed; the checksum that has
been calculated is still the same checksum as the one stored
in the <list>. If <list> also contains filesizes and/or
timestamps, these are being compared as well and must match
in order to return an OK.
FAILED
There is a mismatch between the calculated checksum and the
checksum in the <list>. Usually, this means that the file's
content has been changed. If <list> contains filesizes and/or
timestamps, these are compared as well.
If at least one of those does not match, FAILED is returned.
In that case, additional information is printed to
stderr. You can disable that additional information by
setting the option "--verbose noinfo"
MISSING
A file that is stored in <list> cannot be found on the file
system anymore. Usually, these files have been renamed, moved
to a different location, or even removed.
If you see only MISSING lines, it could mean that your
current working directory is different from the one that was
used when <list> was created. Make sure that your working
directory is set correctly.
ERROR
A file that is stored in <list> is there, but it could not be
verified, for example because it cannot be read, or because a
directory has been found where a file was expected. The
reason is printed to stderr, and the exit code is 4.
NEW
A new file that cannot be found in the <list>, but on the
file system, usually are those that have been created
after the <list> was created. In order to find NEW files, you
have to specify all locations that were used to generate the
<list>. This can be done by adding locations as program
arguments or with the option called "--file-list".
If you want to filter the output by one or more statuses, you can
set the option --list-filter <filter>
If you don't want the status at all in the output, you can
set the option --list and only the filenames will be printed.
After the filenames (and, by default, the status for each file) have
been printed out on separate lines, a short summary with statistics
is printed out, as usually you don't want to miss that information
during a verification check. This is because the verbose control
is set to "info,warnings,summary" if the option -c is set.
Set --verbose nosummary if you want to disable the summary.
If at least one mismatch is found during checksum verification,
the program returns an error code of 1.
If at least one error is found during the process, the program
returns an error code greater than 1.
Improperly formatted lines are ignored with regards to the exit code
unless you set --check-strict. If you set --check-strict more
conditions apply with regards to the exit code.
See also:
options -C, -I, --list-filter, and --check-strict
Available since:
version 3.0.0 of Jacksum
--check-line <string>
Take a <string> from the command line and treat it as if it were
coming from a check file.
See also:
option --style
Available since:
version 3.0.0 of Jacksum.
--check-strict
If one or more input lines are invalid, exit with a non-zero status
after all warnings have been issued when verifying integrity.
If all input lines are valid, exit with a non-zero status if ...
- one or more files failed the verification process (mismatch)
- one or more files have been added
- one or more files have been removed
The option requires --list-filter all, which is the default. Any
other filter is rejected with a parameter error, because a filter
could prevent hashing which could prevent reliable detection.
For a reliable strict check you also should ...
- set the option --scan-ntfs-ads for files stored on a NTFS
file systems to detect new alternate data streams that might
have been added
- set the option --scan-all-unix-file-types for files stored
on Unix- and GNU/Linux file systems to detect special Unix
file types that might have been added.
Available since:
version 3.0.0 of Jacksum.
-C <style>
--compat <style>
--style <style>
Specify the compatibility behavior of Jacksum for both input format
and output format. Replace <style> with one of the
predefined keywords as described below in order to get a predefined
behavior or replace it with a file that contains the properties that
are required for a compatibility file.
For a description of a compatibility/style file, see the Wiki at
https://github.com/jonelo/jacksum/wiki/File-Format-of-Styles
To get the properties of one of the predefined compatibility files,
add the option --info. For example: `jacksum --style bsd --info`
The <style> option can be used for the hashing mode, the
check mode and the info mode.
calculating hash values mode:
During normal hashing of files/messages the <style>determines
the actual output format only. The algorithm (--algorithm),
the encoding for the representation of the hash value
(--encoding), and the format (--format) are used as
defined in <style>.
If the <style> supports the user-specified algorithm, you can
set option -a to get the expected output format defined in
<style>, but with the algorithm you want. For example,
this allows you to print SHA3-256 hashes in the legacy SFV format.
If the <style> supports the GNU file name escaping
formatter to be enabled by the user, you can set option
--gnu-filename-escaping to tag all lines that contain file names
that have been escaped by that feature.
verify hash values mode:
Jacksum can not only read output that has been produced by
itself, but it is also able to read output produced by other
tools. To be compatible with both well-known and lesser-known
tools, you can specify one of the predefined build-in parsers
or define your own parser by providing a short property file.
In check mode (if option -c or --check-file has been set),
the <style> determines the parser that is used to read the
file content properly. With --style, you can check against a
list that was created by a different application, or if you
have generated a list with Jacksum and used the -F option.
To specify the character set of the input file, use the
option --charset-check-file if the input file was not saved in
the UTF-8 character set.
You can also write you own parser definition, save it to a text
file and specify the location of the file with --style.
info mode:
In info mode (if the option --info has been set), all properties
in the compatibility file are printed.
For <style>, the following predefined compatibility style files
are supported:
bsd
Aliases: bsd-tagged, linux-tagged, gnu-linux-tagged
A common lightweight plain text file format on BSD systems
and GNU/Linux. The algorithm information is stored in the
file (therefore it is called "tagged").
This compatibility file can print and parse the output
similar to that of the programs
- md5, sha1, sha224, sha256, sha384, sha512,
sha512t256, rmd16, skein256, skein512, skein1024
on BSD systems
- md5sum, sha1sum, sha224sum, sha256sum, sha384sum,
sha512sum, b2sum, etc. with the --tag
option on Unix and GNU/Linux
- cksum on GNU/Linux with GNU Core Utilities 9.0
and later
The compat file works with any algorithm supported
by Jacksum, as well as concatenated hash values.
GNU escaping can be disabled; see the option
"--gnu-filename-escaping".
If you don't specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum38 -a sha-512/224 --style bsd *.txt
SHA512t224 (gpl-3.0.txt) = 43f7ec26cfa66d9c6ff0cb2d59...
Available since version 3.0.0 of Jacksum.
bsd-r
Aliases: bsd-untagged, bsd-reversed
A common lightweight plain text file format on BSD systems
does not store the algorithm information, thus it is
referred to as "untagged". The BSD reversed mode
format is similar to the GNU untagged format, but does not
use a character to differentiate between binary and text
modes.
This compatibility file can print and parse the output
similar to that of the programs
- md5, sha1, sha224, sha256, sha384, sha512,
sha512t256, rmd16, skein256, skein512, skein1024
with the -r option on BSD systems
The compat file works with any algorithm supported
by Jacksum, and it even works with concatenated hash values.
GNU escaping can be disabled; see the option
"--gnu-filename-escaping" for more information. If you do
not specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha-512/224 --style bsd-r *.txt
...66d9c6ff0cb2d59d5c4e4ef38c94a486925bfc07df4af gpl-3.0.txt
Available since version 3.0.0 of Jacksum.
fciv
"File Checksum Integrity Verifier" was tool from Microsoft.
It supported a lightweight plain text file format.
This compatibility file can print and parse the output
similar to that of the calls "FCIV -sha1" or "FCIV -md5"
on Microsoft Windows.
The compat file works with any algorithm supported by
Jacksum; it even works with concatenated algorithms. If
you do not specify -a, the algorithm defaults to sha1,
as is the strongest algorithm that FCIV supports.
Example:
> jacksum -a sha1 --style fciv *.txt
31a3d460bb3c7d98845187c716a30db81c44b615 gpl-3.0.txt
Available since version 3.0.0 of Jacksum.
files-only
Aliases: filesonly, names-only
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather paths before they are being
hashed. You can pass those file lists through the option
--file-list to Jacksum.
Lists generated by this style will not contain
hash values, and thus cannot be used to check the
integrity of files, nor can they be used as
"wanted lists" (option -w).
However, those lists can be used to check the existence
of files (option -c) if that is the only information
you are interested in.
Note: the file name is at the beginning of the line in this
style, so a file whose name starts with the comment string
(by default "#") cannot be verified later, because its line
is treated as a comment while the list is being read back.
Jacksum warns while it writes such a line, see also the
option -I.
Example:
> jacksum --style names-only *.txt
gpl-3.0.txt
Available since version 3.0.0 of Jacksum.
full
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather all supported check values:
hash values, timestamps, file sizes, and paths.
Lists generated by this style contain hash values,
and thus can be used to check the integrity of files,
and they can be used as "wanted lists" (option -w).
You can get a similar style by specifying the options
`-a sha3-256 -x --filesize on --timestamp iso`
However, in that case the check values timestamp
and file size are swapped. The full style prints
timestamp first followed by the file size. That
makes it easier to read for humans, because both the
hash value and the timestamps have a fixed string length.
You can overwrite the defaults by setting
the options -a, and -t.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style full *.txt
...9dfb36986 2025-04-13T11:12:50.729+02:00 35149 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
without-hashes
Same style as full, but without hash values.
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather timestamps, file sizes
and paths.
Hashing does not occur and therefore it is very performant.
Lists generated by this style will not contain hash values,
and thus cannot be used to check the integrity of files,
nor can they be used as "wanted lists" (option -w).
However, those lists can be used to verify that the files
are still there and the timestamps and file sizes
have not been altered.
The default timestamp format is the one specified by
'-t iso'. However, you can overwrite the default
timestamp format with any timestamp format that is
supported by option -t.
Example:
> jacksum --style without-hashes *.txt
2025-04-13T11:12:50.729+02:00 35149 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
without-sizes
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather all supported check values,
except file sizes: hash values, timestamps, and paths.
Lists generated by this style contain hash values,
and thus can be used to check the integrity of files,
and they can be used as "wanted lists" (option -w).
You can get a similar style by specifying the options
`-a sha3-256 -x --filesize off -t iso`
You can overwrite the defaults by setting
the options -a, and -t.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style without-sizes *.txt
...9dfb36986 2025-04-13T11:12:50.729+02:00 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
without-timestamps
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather all supported check values,
except timestamps: hash values, file sizes, and paths.
Lists generated by this style contain hash values,
and thus can be used to check the integrity of files,
and they can be used as "wanted lists" (option -w).
You can get a similar style by specifying the options
`-a sha3-256 -x --filesize on`
You can overwrite the defaults by setting the option -a.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style without-timestamps *.txt
...ae7ad8af9b23dde66d6af86c9dfb36986 35149 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
gnu-linux
Aliases: linux, linux-untagged, gnu-linux-untagged
A common lightweight plain text file format on GNU/Linux
and macOS without algorithm information in the file
(untagged).
This compatibility file can print and parse the output
similar to that of the programs
- md5sum, sha1sum, sha224sum, sha256sum, sha384sum,
sha512sum, shasum, sha3sum, b2sum, etc. on Unix and
GNU/Linux
- cksum with the --untagged option set on GNU/Linux
with the GNU Core Utilities 9.0 and later
- shasum on macOS
The compat file works with any algorithm supported by
Jacksum, and it even works with concatenated algorithms.
GNU escaping can be disabled; see the option
--gnu-filename-escaping for more information.
The binary mode tag is set to '*' on Microsoft Windows,
and ' ' on non-Windows systems. If you do not specify -a,
the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style gnu-linux *.txt
...76696f2ae7ad8af9b23dde66d6af86c9dfb36986 *gpl-3.0.txt
Available since version 3.0.0 of Jacksum.
hdb
This style is used by sigtool which is a part of ClamAV.
ClamAV is an open source (GPLv2) anti-virus toolkit,
designed especially for e-mail scanning on mail gateways.
ClamAV is supported by Cisco Systems, Inc. ClamAV supports
hash-based signatures to scan and identify infected files.
sigtool can generate hdb files. hdb is an abbreviation for
"hash data base". MD5 is supported, ClamAV 0.98 has also
added support for SHA1 and SHA256 file checksums. The
format is the same as for MD5 file checksum:
HashStringInHex:FileSizeInBytes:MalwareName
The hdb compat file brought to you by Jacksum works with
any algorithm supported by Jacksum, and it even works with
concatenated algorithms.
If you don't want the path stored in the .hdb, you can set
the --no-path option.
GNU escaping is enabled by default and can be disabled;
see the option --gnu-filename-escaping for more
information.
Available since version 4.0.0 of Jacksum.
hexhashes-only
Alias: hexhashesonly
This style can only be used to read and write hash values,
without any accompanying file information. Hash values are
represented in hexadecimal. Since filenames are not part of
these files, the style can be used for "wanted lists" (by
option -w), but not for "check lists" (by option -c).
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
Example:
> jacksum -a sha1 --style hexhashes-only *.txt
31a3d460bb3c7d98845187c716a30db81c44b615
Available since version 3.0.0 of Jacksum.
openssl-dgst
Aliases: openssl, openssl-tagged
A lightweight plain text file format used by OpenSSL.
This compatibility file can print and parse the output,
like that of the openssl program with dgst parameter.
The algorithm names follow OpenSSL 3.x and later. OpenSSL 3.0
has renamed many digests, e.g. SHA256 became SHA2-256, and
BLAKE2b512 became BLAKE2B-512, while OpenSSL 4.0 kept those
names.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
GNU escaping can be disabled; see the option
--gnu-filename-escaping for more information. If you do not
specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style openssl-dgst *.txt
SHA2-256(gpl-3.0.txt)= 3972dc9744f6499f0f9b2dbf76696...
Available since version 3.0.0 of Jacksum.
openssl-dgst-r
Aliases: openssl-r, openssl-untagged
A lightweight plain text file format used by OpenSSL.
This compatibility file can print and parse the output
like that of the openssl program with program arguments
"dgst -r" which prints the digest in coreutils format.
The binary mode flag is set always to "*", even on
GNU/Linux.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
GNU escaping can be disabled; see also the option
--gnu-filename-escaping for more information. If you do not
specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style *.txt
...6696f2ae7ad8af9b23dde66d6af86c9dfb36986 *gpl-3.0.txt
Available since version 3.0.0 of Jacksum.
openssl111-dgst
Aliases: openssl111, openssl111-tagged
The same lightweight plain text file format as the style
openssl-dgst, but with the algorithm names that OpenSSL
1.1.1 and earlier print. OpenSSL 3.0 has renamed many
digests, e.g. SHA256 became SHA2-256, BLAKE2b512 became
BLAKE2B-512, and RIPEMD160 became RIPEMD-160, so use this
style if you want to produce output for an environment that
still expects the old names, and the style openssl-dgst
otherwise.
Both styles read the output of any OpenSSL version, because
the algorithm name that is stored in the file is not used to
verify the hash values. There is no separate style for the
untagged format (openssl dgst -r), because that format does
not contain an algorithm name at all.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
GNU escaping can be disabled; see the option
--gnu-filename-escaping for more information. If you do not
specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style openssl111-dgst *.txt
SHA256(gpl-3.0.txt)= 3972dc9744f6499f0f9b2dbf76696...
Available since version 4.0.0 of Jacksum.
sizes-and-names
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather both file sizes and paths.
Hashing does not occur and therefore it is very performant.
Lists generated by this style will not contain hash values,
and thus cannot be used to check the integrity of files,
nor can they be used as "wanted lists" (option -w).
However, those lists can be used to verify that the files
are still there and the file sizes have not been altered.
The default timestamp format is the one specified by
'-t default'. However, you can overwrite the default
timestamp format with any timestamp format that is
supported by option -t.
You can achieve the same default output by specifying the
options `-a none --filesize off`.
Example:
> jacksum --style sizes-and-names *.txt
35149 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
sfv
"Simple File Verification" is a legacy, lightweight plain
text file format, without algorithm information in the file.
It was initially designed for crc32 only.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms.
If you do not specify -a, the algorithm defaults to crc32,
because that is the algorithm that was used during the
original design of the SFV format.
Note: the file name is at the beginning of the line in this
style, so a file whose name starts with the comment string
(";" for this style) cannot be verified later, because its
line is treated as a comment while the list is being read
back. Jacksum warns while it writes such a line, see also
the option -I.
Example:
> jacksum --style sfv *.txt
gpl-3.0.txt 97673D00
Available since version 3.0.0 of Jacksum.
solaris-digest
Alias: solaris-untagged
A lightweight plain text file format on Solaris with
algorithm information in the file.
This compatibility file can print and parse the output like
that of the tagged call "digest -a <algo>" on Solaris.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms. If you
do not specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style solaris-digest *.txt
(gpl-3.0.txt) = 3972dc9744f6499f0f9b2dbf76696f2ae7...
Available since version 3.0.0 of Jacksum.
solaris-digest-v
Alias: solaris-tagged
A lightweight plain text file format on Solaris without
algorithm information in the file.
This compatibility file can print and parse the output like
that of the untagged call "digest -v -a <algo>" on Solaris.
The compat file works with any algorithm supported by
Jacksum, it even works with concatenated algorithms. If
you do not specify -a, the algorithm defaults to sha3-256.
Example (hash truncated to simplify the output):
> jacksum -a sha256 --style solaris-digest-v *.txt
sha256 (gpl-3.0.txt) = 3972dc9744f6499f0f9b2dbf76696...
Available since version 3.0.0 of Jacksum.
timestamps-and-names
GNU escaping is enabled by default, but it can be disabled;
see also the option --gnu-filename-escaping.
This style can be used to gather both timestamps and paths.
Hashing does not occur and therefore it is very performant.
Lists generated by this style will not contain hash values,
and thus cannot be used to check the integrity of files,
nor can they be used as "wanted lists" (option -w).
However, those lists can be used to verify that the files
are still there and the timestamps have not been altered.
You can achieve the same by specifying the options
`-a none -t iso`. You can adjust timestamp format by -t.
Example:
> jacksum --style timestamps-and-names *.txt
2025-04-13T11:12:50.729+02:00 gpl-3.0.txt
Available since version 4.0.0 of Jacksum.
A dragon's view about the features of the <style>. The first part
of the table lists well known quasi-standards, the second part of
the table lists other common use cases:
<style> |list |algo |algo |hash |file |file |file |
|type |selec|name |value|size |time |name |
|appli|table|in |encod| |stamp|escap|
|cabil| |file |ing | | |ing |
|ity | | | | | | |
____________________|_____|_____|_____|_____|_____|_____|_____|
default | cw | * | - | * | d | d | e |
bsd | cw | * | E | h | - | - | e |
bsd-r | cw | * | - | h | - | - | e |
fciv | cw | * | - | h | - | - | - |
gnu-linux | cw | * | - | h | - | - | e |
hdb | cw | * | - | h | E | - | e |
openssl-dgst | cw | * | E | h | - | - | e |
openssl-dgst-r | cw | * | - | h | - | - | e |
openssl111-dgst | cw | * | E | h | - | - | e |
sfv | cw | * | - | H | - | - | - |
solaris-digest | cw | * | - | h | - | - | d |
solaris-digest-v | cw | * | E | h | - | - | d |
--------------------+-----+-----+-----+-----+-----+-----+-----|
full | cw | * | - | h | E | E | e |
without-sizes | cw | * | - | h | - | E | e |
without-timestamps | cw | * | - | h | E | - | e |
without-hashes | c | - | - | - | E | E | e |
sizes-and-names | c | - | - | - | E | - | e |
timestamps-and-names| c | - | - | - | - | E | e |
names-only | c | - | - | - | - | - | e |
hexhashes-only | w | * | - | h | - | - | - |
--------------------+-----+-----+-----+-----+-----+-----+-----|
Legend:
* = any
- = not available
c = works with check lists (option -c)
w = works with wanted lists (option -w)
d = disabled by default, but can be enabled on demand
e = enabled by default, but can be disabled on demand
E = enabled by default and cannot be disabled
h = hex, lowercase
H = hex, uppercase
--charset-check-file <charset>
--check-file-charset <charset>
Specify the character set for the file that can be specified with
-c. If this option is not specified, UTF-8 will be used for the
check file. See also the options --check-file, --check-line, and
--compat. If you have a file that was created by a redirection on
Microsoft 10, Windows PowerShell 5.1, you should set <charset> to
UTF-16le for example. An ordinary OpenJDK 11 implementation usually
provides more than 170 different charsets. The available charsets
can be printed out by `jacksum --info`.
The Unicode aware character sets are
GB18030
is a Chinese government standard, if a Byte-Order Mark (BOM)
is found it will be ignored, as a BOM in GB18030 is not
required.
UTF-8
8-bit UCS Transformation Format, if a Byte-Order Mark (BOM)
is found it will be ignored, as a BOM in UTF-8 is
not required.
UTF-16
The 16-bit UCS Transformation Format, with an optional
byte-order mark to identify the byte order, defaults to
big-endian if there is no byte-order mark.
UTF-16BE
16-bit UCS Transformation Format, big-endian byte order.
UTF-16LE
16-bit UCS Transformation Format, little-endian byte order.
UTF-32
32-bit UCS Transformation Format, byte order identified
by an optional byte-order mark; it defaults to big-endian
if there is no byte-order mark.
UTF-32BE
32-bit UCS Transformation Format, big-endian byte order.
UTF-32LE
32-bit UCS Transformation Format, little-endian byte order.
See also:
option --info
Available since:
version 3.0.0 of Jacksum.
--charset-wanted-list <charset>
--wanted-list-charset <charset>
Specify the character set for the file using the -w option.
If this option is not specified, UTF-8 will be used. See also -w
or --wanted-list.
Available since:
version 3.4.0 of Jacksum.
--charset-file-list <charset>
--file-list-charset <charset>
Specify the character set for the file that can be specified with
-L. If this option is not specified, UTF-8 will be used for the file
list. See also --file-list or -L.
Available since:
version 3.0.0 of Jacksum.
--charset-error-file <charset>
--error-file-charset <charset>
Specify the character set for the error file. If this option is not
specified, UTF-8 will be used for the error file. See also
--error-file.
Available since:
version 3.0.0 of Jacksum.
--charset-output-file <charset>
--output-file-charset <charset>
Specify the character set for the output file. If this option is not
specified, UTF-8 will be used for the output file. See also
--output-file.
Available since:
version 3.0.0 of Jacksum.
--charset-stderr <charset>
--stderr-charset <charset>
Specify the character set set for the standard error stream
(stderr). If this option is not specified, the default charset will
be used that is dependent on your shell settings. See also --utf8.
Available since:
version 3.0.0 of Jacksum.
--charset-stdout <charset>
--stdout-charset <charset>
Specify the character set for the standard output stream (stdout).
If this option is not specified, the default charset will be used
that is dependent on your shell settings. See also --utf8.
Available since:
version 3.0.0 of Jacksum.
--charset-string-list <charset>
--string-list-charset <charset>
Specify the character set for the string list. If this option is
not specified, UTF-8 will be used for the string list file. See also
option --string-list.
Available since:
version 3.7.0 of Jacksum.
--charset-console <charset>
--console-charset <charset>
Specify the character set for the console which is used by the
options "-q readline" and "-q password".
If this option is not specified, UTF-8 will be used.
Available since:
version 3.7.0 of Jacksum.
--copyright
prints out the copyrights and license information for all portions
of the software that Jacksum licensed. See also --license.
Available since:
version 3.0.0 of Jacksum.
-d
--dont-follow-symlinks-to-directories
Do not follow symbolic links on directories; that means only regular
directories. Starting with version 3, Jacksum detects file
system cycles (a symbolic link from a sub folder to a parent folder)
and skips folders that could cause an endless loop while recursively
traversing. If you set -d, Jacksum will not follow any symbolic
links on directories.
See also:
options -r, and -f, resp. --dont-follow-symlinks-to-files
Available since:
Available since version 1.5.0 of Jacksum. File system cycle
detection has been available since version 3.0.0 of Jacksum.
-e <hash value>
--expect <hash value>
--expect-hash <hash value>
A particular hash value is expected. Works with a file,
standard input, or the option -q.
The hash value can be specified as case sensitive or case
insensitive, except if an encoding with a case sensitive alphabet
has been specified by -E, those are base64, base64-nopadding,
base64url, base64url-nopadding, and z85.
In "quick mode", it just returns MATCH (exit code 0) or NO MATCH
(exit code 1).
Examples:
> jacksum -q txt:"Hello World" -a crc32c -X
691DAA2F 11
> jacksum -q txt:"Hello World" -a crc32c -X -e 691DAA2F
[MATCH]
> jacksum -q txt:"Hello World" -a crc32c -X -e 691DAAFF
[NO MATCH]
See also:
the options -a, -q, -E, -x, and -X
Available since:
version 1.4.0 of Jacksum.
In "wanted list mode", all matches are printed out by default, so
you can find all duplicates of files that have the same hash. You
can adjust what is being printed out by the --match-filter option,
and use the --list option to just print out the paths.
If the expectation was met, that is
--match-filter option is set to match or all, and there is at least
one match OR --match-filter option is set to nomatch, and there is
at least one no match, the exit code is 0, otherwise the exit code
is > 1.
Example:
> jacksum -a sha256 -E base64
-e ihw5Abza/dwTcGJywC+/f8qfwuKa45kp9rCI5RFPcN8= -l C:\
C:\Applications\jacksum-3.4.0\jacksum-3.4.0.jar
C:\Applications\jacksum\jacksum.jar
See also:
options -a, -q, -E, -l, -x, -X, and --match-filter
Available since:
version 1.6.0 of Jacksum.
--exact
Searches the help for an exact match rather than for a prefix.
Without --exact, the option -h prints every option, every algorithm,
and every section header that starts with the word you are looking
for. With --exact, only the option, the algorithm, or the section
header that is exactly the word you are looking for is printed.
This is particularly useful for the options "-" and "--", because
without --exact almost the entire help would be printed.
The option --exact requires both the option -h and a search word.
Note that -h consumes the argument that directly follows it, so
--exact has to be set before -h, or after the search word.
If the search is unsuccessful, the exit code is 1.
Examples:
> jacksum --exact -h -
> jacksum --exact -h --
> jacksum --exact -h -a
> jacksum -h -a --exact
See also:
option -h
Available since:
version 4.0.0 of Jacksum.
-E <encoding>
--encoding <encoding>
Both the hash value and the sequence (see also the option -q) can
be encoded with the following encodings:
<encoding> description
________________________________________________________________
bin binary
dec decimal
oct octal
hex hexadecimal in lowercase chars, same as -x.
Options -g and -G are taken into account.
Each byte of the input is broken into two
4-bit values and represented by two
hexadecimal digits.
The encoding use this representation for
each 4-bit value from zero to 15:
0 - 9: 0 1 2 3 4 5 6 7 8 9
10 - 15: a b c d e f
hex-lowercase alias for hex (3.0)
hexup deprecated in 3.0, alias for hex-uppercase
hex-uppercase hexadecimal in uppercase chars, same as -X.
Options -g and -G are taken into account
(3.0). The encoding use this representation
for each 4-bit value from zero to 15:
0 - 9: 0 1 2 3 4 5 6 7 8 9
10 - 15: A B C D E F
bb alias for bubblebabble
bubblebabble "Bubble Babble" is a binary data encoding
designed by Antti Huima, Finland in April
2000.
The encoding uses alternation of
consonants and vowels (a,e,i,o,u,y) to
encode binary data to pseudowords that can
be pronounced more easily by humans than
arbitrary lists of hexadecimal digits for
example.
The encoding includes a checksumming method
that can sometimes detect invalid
encodings. The method does not increase the
length of the encoded data.
Pseudowords are grouped by five characters,
separated by a hyphen.
The encoding uses six vowels to represent
the values from zero to five, and 16
consonants to represent the values from
zero to 15:
Vowels (0 - 5): a e i o u y
Consonants (0 - 15): b c d f g h k l m n
p r s t v z
Delimiter: x
Separator: -
The delimiter x starts and ends the
encoding, and it also occurs in the last
pseudoword if the number of encoded bytes
is even.
BubbleBabble is used by OpenSSH and SSH2.
base16 Base16 (RFC 4648)
base32 Base32 (RFC 4648)
It encodes 5 bytes to 8 characters. The
digits 0, 1 and 8 are skipped due to their
similarity with the letters O, I and B.
The encoding use this representation for
each 5-bit value from zero to 31:
0 - 9: A B C D E F G H I J
10 - 19: K L M N O P Q R S T
20 - 29: U V W X Y Z 2 3 4 5
30 - 31: 6 7
Padding: =
base32-nopadding Base32, no padding (RFC 4648) (3.0)
base32hex Base32hex (RFC 4648) (3.0)
It encodes 5 bytes to 8 characters. It
extends hexadecimal in a more natural way.
The encoding use this representation for
each 5-bit value from zero to 31:
0 - 9: 0 1 2 3 4 5 6 7 8 9
10 - 19: A B C D E F G H I J
20 - 29: K L M N O P Q R S T
30 - 31: U V
Padding: =
base32hex-nopadding Base32hex, no padding (RFC 4648) (3.0)
base64 Base64 (RFC 4648)
It encodes 3 bytes to 4 characters, meaning
a space efficiency of 75 %.
The encoding use this representation for
each 6-bit value from zero to 63:
0 - 9: A B C D E F G H I J
10 - 19: K L M N O P Q R S T
20 - 29: U V W X Y Z a b c d
30 - 39: e f g h i j k l m n
40 - 49: o p q r s t u v w x
50 - 59: y z 0 1 2 3 4 5 6 7
60 - 63: 8 9 + /
Padding: =
base64-nopadding Base64, no padding (RFC 4648) (3.2)
base64url Base64 for URL (RFC 4648) (3.0)
The '+' and '/' characters of standard
Base64 are replaced by '-' and '_', so that
using URL encoders/decoders are no longer
necessary.
It encodes 3 bytes to 4 characters.
The encoding use this representation for
each 6-bit value from zero to 63:
0 - 9: A B C D E F G H I J
10 - 19: K L M N O P Q R S T
20 - 29: U V W X Y Z a b c d
30 - 39: e f g h i j k l m n
40 - 49: o p q r s t u v w x
50 - 59: y z 0 1 2 3 4 5 6 7
60 - 63: 8 9 - _
Padding: =
base64url-nopadding Base64 for URL, no padding (RFC4648) (3.2)
z85 Z85 (3.7)
Z85 was suggested by Pieter Hintjens
(1962 – 2016) for the ZeroMQ messaging lib.
See also https://rfc.zeromq.org/spec/32/
Z85 encodes 4 bytes to 5 characters,
meaning a space-efficiency of 80 %.
It is a string-safe encoding, it can be
used cleanly in source code, XML, JSON,
and so on.
The encoding use this representation for
each base-85 value from zero to 84:
0 - 9: 0 1 2 3 4 5 6 7 8 9
10 - 19: a b c d e f g h i j
20 - 29: k l m n o p q r s t
30 - 39: u v w x y z A B C D
40 - 49: E F G H I J K L M N
50 - 59: O P Q R S T U V W X
60 - 69: Y Z . - : + = ^ ! /
70 - 79: * ? & < > ( ) [ ] {
80 - 84: } @ % $ #
Note: 85^5 is bigger than 2^32, therefore a
five-byte Z85 data chunk cannot start
with '#', therefore even if the '#'
character is part of the alphabet of Z85,
it is save to use it for option
--ignore-lines-starting-with-string.
Z85 is a good binary-to-text encoding for
hash values. However according to the spec
it is up to the application to ensure that
frames and strings are padded if necessary.
The spec does not mention how to do padding.
The length constraint is not a problem for
many of the hash functions, because the
length of the hash values are usually a
multiple of 4 bytes. However, it is a
problem for a few, not so common,
algorithms like blake2s-240, or
skein-1024-1000 for example.
In order to use Z85 for all algorithms
supported by Jacksum, the following
implementation is used:
For messages that are a multiple of 4
bytes, it behaves exactly like the original
Z85 encoding, and no padding is required.
For messages that are not a multiple of 4
bytes, it behaves like Ascii85 with respect
to padding behavior. For decoding, we just
need to fill up with '#' characters instead
of 'u' before decoding, and ignore
the appropriate number of characters in the
decoded string. This is very space-
efficient, because for decoding, padding
can be calculated from the length of the
encoded string, and for encoding, only
characters that are really required need to
be stored.
z-base-32 z-base-32 (3.1)
It encodes 5 bytes to 8 characters.
The encoding use this representation for
each 5-bit value from zero to 31:
0 - 9: y b n d r f g 8 e j
10 - 19: k m c p q x o t 1 u
20 - 29: w i s z a 3 4 5 h 7
30 - 31: 6 9
Padding: none
See also:
options -F, -g, -G, -q, -x, and -X.
Available since:
version 1.6.0 of Jacksum if not stated otherwise.
-f
--dont-follow-symlinks-to-files
process regular files only. Do not follow symbolic links to
files (any OS), to block devices, character devices, named pipes,
sockets (Unix-like OS only), nor to doors (Solaris only).
See also:
option -d, resp. --dont-follow-symlinks-to-directories
Available since:
version 3.0.0 of Jacksum.
--filesize <boolean>
By default, or if this option is omitted, the file size is added to
the output when selecting an algorithm that also adds the file size
to the output in order to be more reliable for integrity checks
(usually this applies to simple checksums and CRCs). If you
select multiple algorithms, the file size will be added by default.
If you wish to control whether the file size should be added or not,
you can use this option with the following values for <boolean>:
yes|on|true|1|enabled enables the file size
no|off|false|0|disabled disables the file size
See also:
option --format, token #FILESIZE
Available since:
version 3.3.0 of Jacksum.
-F <format>
--format <format>
With this option, you can set a customizable output format if the
default output format does not meet your needs.
<format> can be any text. If the text contains particular tokens,
all tokens will be replaced with their corresponding values.
The following tokens are supported:
<token> Description
________________________________________________________________
#ALGONAME will be replaced by the name of the
selected algorithm.
#ALGONAME{<i>} If the character called + has been used
to separate multiple algorithms by
option -a, the token will be replaced
with the name of the algorithm. The
token is indexed by a number. If you
use the single character called i
rather than a number, it works like
an automatic index. (1.7)
#ALGONAME{lowercase} alias for #ALGONAME (3.0)
#ALGONAME{<i>,lowercase} alias for #ALGONAME{i} (3.0)
#ALGONAME{uppercase} like #ALGONAME, but the name of the
algorithm appears in uppercase. (3.0)
#ALGONAME{<i>,uppercase} like #ALGONAME{i}, but the name of the
algorithm appears in uppercase. (3.0)
#ALGONAMES plural. Will be replaced by the name of
the selected algorithm. If multiple
algorithms have been selected, each
algorithm name is separated by a comma.
(3.3)
#ALGONAMES{lowercase} like #ALGONAMES, but the name(s) of the
algorithm(s) appear in lowercase. (3.3)
#ALGONAMES{uppercase} like #ALGONAMES, but the name(s) of the
algorithm(s) appear in uppercase. (3.3)
#BINTAG On Microsoft Windows this token is
replaced by a '*', on all other
platforms it is replaced by a ' '.
(3.3)
#CHECKSUM alias for #HASH.
#DIGEST alias for #HASH.
#ESCAPETAG if the option called
--gnu-filename-escaping is enabled, the
<token> will be replaced by a single
backslash. If the option is disabled
(default), it will be replaced by an
empty string.
See also --gnu-filename-escaping (3.3)
#FILENAME will be replaced by the file name and
path (depends on -P)
#FILENAME{name} will be replaced by the file name (1.6)
#FILENAME{path} will be replaced by the file path (1.6)
#FILESIZE will be replaced by the file size
#FINGERPRINT alias for #HASH.
#HASH will be replaced by the hash, CRC or
checksum value (depends on the
options -a, -E, -g, -G, -x, -X) (3.3)
#HASH{<encoding>} The token will be replaced with the
encoded checksum. Replace <encoding>
with a supported encoding. For valid
encoding values see option -E. (1.7)
#HASH{<i>} If the character called + has been used
to separate multiple algorithms by
option -a, the token will be replaced
with the checksum. The token is indexed
by a number. If you use the character
called i rather than a number, it works
like an automatic index. (1.7)
#HASH{<algo>} the token will be replaced with the
hash identified by its algorithm
name. (3.0)
#HASH{<i>,<encoding>} like #HASH{<i>}, but with an explicit
encoding (3.0)
#HASH{<algo>,<encoding>} like #HASH{<algo>}, but with an
explicit encoding (3.0)
#HASHES plural. Token will be replaced by the
hash, CRC or checksum value. If
multiple algorithms have been selected,
each hash value is separated by a comma
(depends on the options -a, -E, -g, -G,
-x, and -X) (3.3)
#HASHES{<encoding>} like #HASHES, but with an explicit
encoding (3.3)
#LENGTH is an alias for #FILESIZE (3.0)
#MESSAGE is an alias for #FILENAME (3.7) for a
more convenient name for the message if
using the option --string-list
#SEPARATOR will be replaced by the separator which
you can specify with -s
#SEQUENCE will be replaced by the hexadecimal
representation of the sequence which
you can specify with -q (3.0)
#SEQUENCE{<encoding>} like #SEQUENCE, but with explicit
encoding (3.0)
#TIMESTAMP will be replaced by the time stamp
(depends on -t)
#QUOTE will be replaced by one quote char (")
See also:
options -a, -E, -g, -G, --gnu-filename-escaping, -P,
-s, -t, -x, and -X.
Available since:
version 1.5.0 of Jacksum, unless otherwise specified.
-g <count>
--group-bytes <count>
Group the hex output for the checksum in <count> bytes for
better readability, only valid if encoding is hex or hexup.
Groups are separated by a blank or by the character
specified by -G; the value for <count> must be greater than 0.
Grouped hash values cannot be parsed again, therefore this
option cannot be combined with the options -c and -w.
See also:
options -E, -G, -x, and -X
Available since:
Jacksum 1.6.0
-G <char>
--group-bytes-separator <char>
Sets the separator for byte groups, only valid if encoding is
hexadecimal and option -g has been set.
Grouped hash values cannot be parsed again, therefore this
option cannot be combined with the options -c and -w.
See also:
options -E, -g, -x, and -X
Available since:
version 1.6.0 of Jacksum.
--gnu-filename-escaping <boolean>
On GNU/Linux and Unix operating systems, file names can contain
problematic characters such as newlines and carriage returns.
The GNU Coreutils suggests escaping these problematic characters in
file names with a backslash, which ensures a single line per file on
standard output. The backslash itself also needs to be escaped.
The feature was introduced in the GNU Coreutils release 8.25 from
January 2016.
Jacksum supports file name escaping as suggested by GNU for the
default output, the custom formatter (see the --format option), and
for the style formatters (see the --style option).
By default, or if the option is omitted, the selected style
determines whether file name escaping is enabled or not.
Most styles allow toggling the feature, and you can use this option
with the following values for <boolean> to control the actual
behavior explicitly:
yes|on|true|1|enabled enables the GNU file name escaping
no|off|false|0|disabled disables the GNU file name escaping
The default style enables the feature on GNU/Linux and Unix systems
only. On Microsoft Windows, it is disabled, as it is not allowed to
use newlines or carriage returns in filenames, and thus it makes no
sense to enable it on Windows.
If file name escaping is enabled (implicitly or explicitly), and a
file contains a backslash, newline, or carriage return, the line
starts with a backslash, and the problematic characters in the file
name are escaped with a backslash.
See also:
the option -F, token #ESCAPETAG
Available since:
version 3.3.0 of Jacksum.
--header
Prints a header as a comment. The string used to mark a line as a
comment is read from the compatibility file if -C has been
specified, or if it has been specified with the -I option. If -C
and -I are omitted, the hash sign is used.
The header contains the following information:
- Jacksum version and homepage
- JMV name, vendor, and version
- OS name, architecture, and version
- ISO 8601 timestamp of invocation
see also https://www.iso.org/iso-8601-date-and-time-format.html
- Working directory of invocation
- Invocation arguments
See also:
options --no-header, --ignore-lines-starting-with-string
Available since:
version 3.3.0 of Jacksum.
-h [language] [word]
--help [language] [word]
Prints the help; valid codes for language are "en" and "de"; valid
values for word are strings such as section headers, options or
algorithms.
By default, [word] matches any option, algorithm, or section header
that starts with [word]. Set the option --exact to search for an
exact match only.
See also:
option --exact
the section "EXAMPLES" for more information, or simply type
> jacksum -h examples
Available since:
version 1.0.0 of Jacksum,
option value [word] since version 1.6.0 of Jacksum.
--hmacs
Prints all algorithms that support HMAC.
If "-V info" has been set, it also prints the following columns:
l - the bit-length of the hash output
B - the block size in bytes
L - the byte-length of the hash output which is also
the recommended minimum length in bytes of the key
T - the recommended minimum length in bytes of the HMAC output
in case of truncation
If --verbose summary has been set, it also prints the number of
supported HMACs.
See also:
the options "-a hmac:", -k
Available since:
version 3.7.0 of Jacksum.
--info
Forces the information mode, and sets the verbose control to info.
It returns information and exits the program.
If option -a has not been set, it will print out
- The program name and version
- The Primary IDs and descriptions of all supported algorithms
- The number of all supported algorithms
- The default algorithm
- The number of the supported CRC combinations
- The supported character sets
- The default character set
- Available processors
- and all Java system properties
If -a has been set it prints out additional information about the
selected algorithm(s):
- Algorithm id
- Hash length in bits and bytes
- Block size in bits and bytes (if applicable)
- Security:
"broken:" tells whether the algorithm is considered broken.
The value is one of "yes", "no", "partly" (only some of the
security properties are broken), "depends" (it depends on a
parameter of the algorithm, e.g. on the underlying hash
function of an HMAC), or "n/a" (the algorithm does not claim
cryptographic security, e.g. a CRC or a checksum).
Set --verbose details in order to also print the explanation
of that value.
- Avalanche effect:
if a sequence has been specified (using -q), the sequence
will be used to calculate the avalanche effect. If the
sequence is less than 1 byte, avalanche won't be calculated.
If a sequence has not been specified, "123456789" will be
used.
- in case of a CRC:
CRC implementation details including different
representations of the polynomial (normal, reversed,
and Koopman repr.), and the corresponding reciprocal
polynomial including different representations of the
polynomial
- in case of a PRNG: PRNG hash parameters
- Whether an alternative implementation has been requested,
whether it is available and would be used
If -a has been set to return multiple or all algorithms,
and --list has been set, it prints out:
- Details for each algorithm
Example:
> jacksum -a all:crc --info --list
If --style has been set, it prints details about the style config.
Example:
> jacksum --style hdb --info
See also:
the options -a, --style, --list
Available since:
version 3.0.0 of Jacksum.
--ignore-hashes
During a check, hash values are ignored if they are present in the
check file.
See also:
the options -c, --style
Available since:
version 4.0.0 of Jacksum
--ignore-empty-lines
While reading a string list by --string-list, lines are ignored
if they are empty. Lines are not trimmed to determine the emptiness.
By default, or if the option is omitted, empty lines are hashed,
which in fact is treated as an empty message for the algorithm.
See also:
options --string-list and --ignore-lines-starting-with-string
Available since:
version 1.7.0 of Jacksum.
-I <string>
--ignore-lines-starting-with-string <string>
While reading a list by -L or -c or --string-list, lines are ignored
if they start with the string <string>.
The value of the option also changes the comment string of the
option --header.
If <string> is not set, the string "#" is used, resp. the string
that the style has defined (e.g. ";" for the style sfv). A file
whose name starts with that string cannot be verified later, because
its line is treated as a comment while the list is being read back.
Jacksum warns while it writes such a line; set <string> to a string
that does not occur at the beginning of any of your file names to
avoid this.
See also:
options --ignore-empty-lines, and --header
Available since:
version 1.6.0 of Jacksum
--ignore-sizes
During a check, file sizes are ignored if they are present in the
check file.
See also:
the options -c, and --style
Available since:
version 4.0.0 of Jacksum
--ignore-timestamps
During a check, timestamps are ignored if they are present in the
check file.
See also:
the options -c, and --style
Available since:
version 4.0.0 of Jacksum
-k {[<type>:]<sequence>|readline|password}
--key {[<type>:]<sequence>|readline|password}
Sets a secret key for the Keyed-Hash Message Authentication Code
(HMAC). The settings supported for option -k are the same as for
option -q which is ok for testing purposes.
However, in multi user environments, only file:<file>, readline,
and password are recommended settings, because all other settings
will make the secret key appear either in process lists which could
be gathered by other users as well or in history files which are
stored on disk usually.
In order to avoid shoulder surfing attacks in non-private
environments you should prefer file:<file> or password over
readline.
Examples:
> jacksum -a hmac:sha256 -k file:key.txt message.txt
> jacksum -a hmac:sha256 -k password message.txt
Key (echo off):
See also:
the options "-a hmac:", --hmacs, --charset-console
Available since:
version 3.7.0 of Jacksum
--license
Prints out the license under which the project is offered.
See also:
option --copyright
Available since:
version 3.0.0 of Jacksum.
-l
--list
Enables the list view.
If option -a is set, it lists the IDs of the algorithms only.
Examples:
> jacksum -a all:sha -l
> jacksum -a all:32 -l
If the option -c and --list-filter is set, it will list the
filenames only without the statuses OK, FAILED, MISSING, ERROR,
or NEW. A filename that contains a backslash, a newline, or a
carriage return is escaped and its line is marked with a leading
backslash, unless GNU filename escaping has been disabled, so that
one file is always one line and the output can be read back by the
option --file-list.
If options --wanted-list and --wanted-list-filter are set, it lists
the filenames only without the statuses MATCH or NO MATCH.
Available since:
version 3.0.0 of Jacksum.
--list-filter <filter>
Filters the output produced by -c mode.
<filter> must be one or more of the following keywords,
separated by a comma:
ok show OK files
failed show FAILED files
missing show MISSING files
new show NEW files
error show ERROR files
all <filter> is set to ok,failed,missing,new,error
default <filter> is set to all
none does not print anything (useful if you are
interested in the summary only) or if you want
to define your own filter
good <filter> is set to none,ok,new
bad <filter> ist set to none,failed,missing,error
If this option is omitted, the <filter> is set to all.
Only if the filter is set to ok, failed, error, or a combination of
those, hashing occurs. For detecting missing or new files, hashing
is not required.
See also:
options -c, and --list
Available since:
version 3.0.0 of Jacksum.
-L <textfile>
--file-list <textfile>
Process <textfile> as a filelist. By default, each line in the file
will be treated as a filename or foldername to be processed.
GNU filename escaping is supported, but can be disabled on demand.
If the option --file-list-format is set to ssv, each line in the
file will be treated as multiple filenames, separated by spaces or
tabs.
If <textfile> is set to "-", standard input stream is used.
The charset UTF-8 is used to read the file unless you specify
the charset by the option --charset-file-list.
The option -L <textfile> can go in addition to file parameters.
Wildcards are not supported in the <textfile>.
See also:
options --file-list-format, --file-list-charset
Available since:
version 3.0.0 of Jacksum.
--file-list-format <format>
If this option is omitted, the format of the file list file is
set to "list". The supported formats are:
list default. Each filename is stored on a separate line.
Those lists can be generated, for example, by the "find"
command on GNU/Linux and Unix systems, the "dir /b"
command in cmd-shells on Microsoft Windows, or the
"dir -n" command in Windows PowerShells on Microsoft
Windows.
Alternatively, use Jacksum to generate those lists:
> jacksum --style filesonly
ssv space-separated values. Each filename is separated by
one or more common space characters (a space or a
horizontal tab). A file name that contains space
characters has to be enclosed in double quotes. This is
useful if Jacksum operates in Windows shells, where
Jacksum is not able to accept program arguments or
file names that contain Unicode characters.
See also:
options --file-list, --file-list-charset
Available since:
version 3.0.0 of Jacksum.
--legacy-stdin-name
Starting with Jacksum 3 the standard input stream is named
"<stdin>", as the single dash could also be the name of a file or
a directory. Since the characters < and > cannot be used for
filenames or directory names on most file systems, <stdin> is a
great choice for naming stdin. If you set the --legacy-stdin-name,
Jacksum uses the "-" again for naming the standard input stream.
Available since:
version 3.0.0 of Jacksum.
--no-header
No header is printed by default. However, the styles
with "full" in the names activates the header. If you
do not want the header to be printed, set this option.
See also:
option --header
Available since:
version 4.0.0 of Jacksum.
--no-path
Prints regular filenames without path information, which is
useful if you want to create a simple database for file
identification purposes.
This option has an effect only during hash calculation mode.
It has no effect on NTFS ADS objects, nor if a non-default output
format is already set by using the options -F or -C.
If you want to store the default output in order to perform an
integrity check later, you should not set this option, because
without path information it is impossible to find the files again.
See also:
options -P, --path-relative-to, and --path-absolute
Available since:
version 3.2.0 of Jacksum.
-o <file>
--output-file <file>
The output of the program goes to a file rather than the standard
output; the program exits with a warning if the file exists, and the
file specified by -o is excluded from the calculation process.
See also:
options -O, -u and -U
Available since:
version 1.6.0 of Jacksum.
-O <file>
--output-file-overwrite <file>
Same as -o, however an existing file will be overwritten without any
warning.
See also:
options -o, -u, and -U
Available since:
version 1.6.0 of Jacksum.
--output-file-replace-tokens
Replaces some tokens if they appear in the <file> specified by
-o or -O. The following tokens are supported:
#ALGONAME alias for #ALGONAME{lowercase}
#ALGONAME{lowercase} the name of the algorithm in lowercase
characters
#ALGONAME{uppercase} the name of the algorithm in uppercase
characters
#ALGONAME variants set the algorithm id as part of the output file
name. If the algorithm id contains a colon (e. g. "crc:", "prng:",
or "hmac:"), it will be replaced by an equal sign, because Microsoft
Windows file systems don't allow the colon to be part of a file
or path, because it is used to separate drives.
Example:
> jacksum -a sha-256 --output-file-replace-tokens
-O /myisos/.#ALGONAME{uppercase} /myisos/*.iso
creates a filename called /myisos/.SHA-256 containing the
SHA-256 hashes of all .iso files in the /myisos/ directory.
See also:
options -o, and -O
Available since:
version 3.7.0 of Jacksum.
--path-absolute
--absolute
By default, paths are printed relatively if relative paths are
passed as program arguments, and paths are printed absolutely if
absolute paths are passed as program arguments. If this option is
set, paths are printed absolutely in all cases.
See also:
options -P, --path-relative-to, and --no-path
Available since:
version 3.3.0 of Jacksum.
--path-relative-to <path>
--relative-to <path>
By default, paths are printed relatively if relative paths are
passed as program arguments, and paths are printed absolutely if
absolute paths are passed as program arguments.
If this option is set during calculation mode, the paths of the
file objects are printed relative to the <path>. If <path> points
to a file rather than to a folder, the folder name of the file is
used for <path>. If a path cannot be relativized to <path>,
(e.g., if both paths have a different root on Microsoft Windows),
the path is returned without being relativized.
If this option is set during check mode, the path for each file
object in the check file is simply prepended by <path>.
See also:
options -P, --path-absolute, and --no-path
Available since:
version 3.2.0 of Jacksum.
--path-relative-to-entry <number>
--relative-to-entry <number>
If this option is set, the option --path-relative-to <path> is
set, where <number> is the line number that is stored in the file
list, specified by --file-list. <number> starts at 1 and must be
greater than 0. This option requires the option --file-list. If
file list is empty, this option is ignored.
See also:
option --path-relative-to
Available since:
version 3.3.0 of Jacksum
-P <char>
--path-separator <char>
By default, the system-dependent default name separator character is
used. On Unix and GNU/Linux systems, the character is the slash (/),
and on Microsoft Windows systems, it is the back slash (\). You can
change the default if a special output format for file names is
required, for example to produce relative links for HTML pages on
Microsoft Windows.
See also:
options -F, --path-absolute, and --path-relative.
Available since:
version 1.5.0 of Jacksum
-q {[<type>:]<sequence>|readline|password}
--quick {[<type>:]<sequence>|readline|password}
Process a sequence quickly and quit the program. The settings
supported for option -q are the same as for option -k.
The <type> can be used to specify the type of the input:
- text or formatted text
- binary, decimal, octal, or hexadecimal sequence
- Base32, Base32hex, Base64, Base64url, z-base-32, z85, or
BubbleBabble encoded string
- one file (max. 128 MiB)
- input from the console visible or hidden
If <type> is not set, the sequence is expected to be in hex form.
The following values for <type> are supported:
bubblebabble
A BubbleBabble encoded string. For more information see also
option -E.
Example:
> jacksum -q bubblebabble:xesef-disof-gytuf-katof-movif-baxux
base32
A Base32 encoded string. The string can be encoded using
base32 or base32-nopadding. For more information see also
option -E.
Examples:
> jacksum -q base32:MFXHG53FOIQGS4ZAGQZA====
> jacksum -q base32:MFXHG53FOIQGS4ZAGQZA
base32hex
A Base32hex encoded string. The string can be encoded using
base32hex or base32hex-nopadding. For more information see
also the option -E.
Examples:
> jacksum -q base32hex:C5N76TR5E8G6ISP06GP0====
> jacksum -q base32hex:C5N76TR5E8G6ISP06GP0
base64
A Base64 encoded string. The string can be encoded using
base64 or base64-nopadding. For more information see also
the option -E.
Examples:
> jacksum -q base64:dGhlIGFuc3dlciBpcyA0Mg==
> jacksum -q base64:dGhlIGFuc3dlciBpcyA0Mg
base64url
A Base64url encoded string. The string can be encoded using
base64url or base64url-nopadding. For more information see
also the option -E.
Examples:
> jacksum -q base64url:wN7K_g==
> jacksum -q base64url:wN7K_g
bin
Binary values can be separated by commas or spaces,
but you do not have to, as long as it is clear,
where the 8 bit boundaries are. If necessary you have to
fill up with leading zeros as the last example illustrates.
Examples:
> jacksum -q bin:1100101,1100111,100000,110100,110010,1010
> jacksum -q bin:"1100101, 1100111, 100000, 110100, 110010,1010"
> jacksum -q bin:"1100101 1100111 100000 110100 110010 1010"
> jacksum -q bin:11001010110011100100000001101000011001000001010
dec
Decimal values must be separated from each other by a comma
or one or more spaces. If you use spaces, you must enclose
the string in quotation marks to indicate to the shell that
it is one string.
Examples:
> jacksum -q dec:101,103,32,52,50,10
> jacksum -q dec:"101, 103, 32, 52, 50, 10"
> jacksum -q dec:"101 103 32 52 50 10"
file
If <type> is specified as "file", all bytes from the
<file> will be read and kept in memory.
The -q option is also used to feed data to the algorithm
finder module which tries to find the algorithm to a
checksum/CRC/hash value. It does that by processing data
using a brute force algorithm, and I/O operations must be
avoided where possible in that case. Therefore the size of
<file> is limited to 128 MiB, because the entire content of
the file will be stored in memory for fast access. This
option is not intended for reading in large files. If you
want to read large files up to 8 Exbibytes
(= 8,000,000,000 Gibibytes) pass <file> as a parameter to
Jacksum.
Example:
> jacksum -q file:myfile.img
hex
Hexadecimal values can be separated by commas or spaces, but
you do not have to, as long as it is clear, where the 8 bit
boundaries are. If necessary you have to fill up with
leading zeros as the first two examples illustrates.
Examples:
> jacksum -q 65672034320A
> jacksum -q hex:65672034320A
> jacksum -q hex:65,67,20,34,32,A
> jacksum -q hex:"65, 67, 20, 34, 32, A"
> jacksum -q hex:"65 67 20 34 32 A"
oct
Octal values must be separated from each other by a comma
or one or more spaces. If you use spaces, you must enclose
the string in quotation marks to indicate to the shell that
it is one string.
Examples:
> jacksum -q oct:145,147,40,64,62,12
> jacksum -q oct:"145, 147, 40, 64, 62, 12"
> jacksum -q oct:"145 147 40 64 62 12"
password
Reads a password or passphrase from the console, not
including any line-termination characters. You can use that
mode to generate both unique and strong passwords for
websites. The returned hash values will be stronger
than anything a normal human brain could remember, and
nothing needs to be stored on disk. If the password is
compromised, the master password will still remain secret.
In other words, you can treat Jacksum as a password
generator that generates the actual password for a website
on demand.
Some notes and recommendations:
- Combine a master password with website-specific
information, such as the domain name, to get unique
passwords.
- For the master password you should use a strong password
that is at least 8 characters long; the longer, the
better, and you should be able to remember it easily.
- You should use a non-broken, strong cryptographic hash
algorithm for the task.
- Set the character set explicitly if you use multiple
different operating systems or environments that do not
use UTF-8 for the console by default, and make sure to
remember the character set as well.
- You can use all of the available characters for the
password.
- You can copy and paste the password to the prompt, but it
is better if you remember it and type it, as this trains
your brain to remember the password, and your brain will
be the only place where the master password resides.
Due to security reasons the following limits apply:
- You won't see the password that you enter; in other words,
echoing is disabled to prevent shoulder-surfing attacks.
- Only the hash is printed by default; it is not possible to
print the password in clear text, even if particular
format options such as -F or --style are set. Use
option "-q readline" if you prefer echoing.
- Operating system piping is not possible, because we want
to make sure that the password is coming from a keyboard
and not transfer passwords in clear text between processes
via piping.
- Operating system redirection is not possible, because a
console is required to enter the password. Use the
options -o/-O to save the hash to a file if you do no wish
to see the hash value in the console.
- To minimize the lifetime of sensitive data in memory, the
password is cleared from memory after processing. Java's
String interning is not used for the password.
Examples:
> jacksum -q password -a sha256 -E z85
Password: facebook.com <a strong master password>
readline
Reads one string from the console, not including any
line-termination characters. It works similar to the
"password" mode, but it shows the string that you type,
and you can print it out again by specifying format options
which is useful for investigating particular strings and
encodings.
By default UTF-8 is used for the character encoding in the
console. See also --charset-console.
Example:
> jacksum -q readline
-F "#HASH msg=#MESSAGE msglen=#LENGTH hex=#SEQUENCE{hex}"
txt
Text, unformatted. If <type> is only specified as "txt",
the default character set of the platform used to represent
the <sequence>.
For unformatted text, the \n is NOT interpreted as one
character (new line), but rather as two separate characters
(backslash and "n"). Accordingly, the sequence above
represents an input of 8 bytes and not 7 bytes.
Example:
> jacksum -q txt:"the answer is 42\n"
txtf
Text, formatted. If type is specified as "txtf", UTF-8 will
be used to interpret the <sequence> as formatted text.
The following escape sequences are interpreted accordingly:
\t Horizontal Tab (0x09)
\n New Line (0x0A)
\r Carriage Return (0x0D)
\" Double Quote (0x22)
\' Single Quote (0x27)
\\ Backslash (0x5C)
\xHH Hexadecimal Number (HH can become 00 to 7F, and
both upper and lower case can be used for HH)
Any other sequence that starts with a backslash is not
interpreted and stays in the data unchanged, this is also
true for \x80 to \xFF.
Examples:
> jacksum -q txtf:"answer is 42\n"
> jacksum -q txtf:"answer is 42\x0A"
> jacksum -q txtf:"answer is 42\x0a"
z-base-32
A z-base-32 encoded string. For more information see also
option -E.
Example:
> jacksum -q z-base-32:cfz8g75fqeog1h3ygo3y
z85
A Z85 encoded string. For more information see also
option -E.
Example:
> jacksum -q z85:vqZdgwPw]cB09p{
Available since:
version 1.3.0 of Jacksum (hex only), "type" since version
1.5.0, type "bin" and "txtf" since version 3.0.0, type
"file" since version 3.1.0 of Jacksum, console mode since
version 3.7.0 of Jacksum, types "z-base-32" and
"bubblebabble" since version 4.0.0 of Jacksum.
--scan-all-unix-file-types
This option has an effect on Unix-like operating systems only. By
default, Jacksum reads from regular files, directories, and symbolic
links during recursively directory traversal on all supported
platforms. You can change the behavior of following symbolic links
by setting the options -f and/or -d.
In Unix-like operating systems there are additional file types
available. "Everything is a file" describes one of the defining
features of Unix, and its derivatives. Since everything is a file,
if you set this option, Jacksum will also calculate message digests
from these files:
- block devices (i.e. disks, and partitions)
- character devices (e.g. /dev/null)
- named pipes (FIFOs)
- sockets
- doors (Solaris only)
If these file types are found during recursively directory
traversal, Jacksum does not read from them by default, as this could
cause the process waiting on data forever (e.g. a named pipe without
a producer), read data forever (e.g. /dev/random which generates an
infinite number of random numbers) or hash entire disks or
partitions which you did not want to hash by default. Note that
setting this option makes the output platform-dependent. Use this
option with care and wisdom.
See also:
options -d, -f, and -r
Available since:
version 3.1.0 of Jacksum.
--scan-ntfs-ads
This option has an effect on Microsoft Windows only. NTFS Alternate
Data Streams (ADS) can be attached to both files and directories. By
default, Jacksum does not look for ADS. If you set this option,
Jacksum scans for ADS and calculates hashes for those. The option
-r <depth> is respected.
Note: setting this option makes the output platform-dependent if
at least one ADS can be found.
Available since:
version 3.1.0 of Jacksum.
--string-list <list>
Activates the "string list"-mode. For each message in <list> a hash
value will be calculated. The order of the lines in the file will be
maintained.
A line is considered to be terminated by any one of a line feed
('\n'), a carriage return ('\r'), a carriage return followed
immediately by a line feed ('\r\n').
A message is a string containing the contents of the line, not
including any line-termination characters.
Empty lines are considered empty messages and are hashed. If you
do not want to hash empty messages, set the option
--ignore-empty-lines.
If <list> is set to a single dash (-) Jacksum reads from stdin.
Use option --charset-string-list to specify the character set for
<list> so that it can be read properly. If <list> is headed by an
optional Byte Order Mark (BOM), it will be removed if present before
reading.
You can use the option -I in order to ignore all lines that start
with a particular string in <list>.
You can use the option --ignore-empty-lines to ignore all lines
that are empty.
All available format options also apply to this mode. See also the
options -E, -g, -G, -F, -x, -X.
Use option --charset-output-file (if -o or -O has been set), or
option --charset-stdout to specify the character set for the output.
Use option --bom to force a Byte Order Mark (BOM).
Available since:
version 3.7.0 of Jacksum.
-r <depth>
--recursive <depth>
Process subdirectory recursively with a specific depth. The <depth>
can be "max" or a number greater than 0. If -r is not set at all,
<depth> is set to "max" implicitly. If -r is explicitly set, the
current working directory is used if no file parameter is specified.
Available since:
version 1.0.0 of Jacksum.
The <depth> is available since version 3.0.0 of Jacksum.
-s <string>
--separator <string>
A custom separator string (\t, \n, \r, \", \' and \\) will be
translated. The default value depends on the checksum algorithm;
usually, it is a single blank.
You can set <string> to any string that you like, but if you want
Jacksum to parse the output again using the -c option, you should
set the separator to a string which allows Jacksum to parse the
output properly again. Jacksum won't tell you that your choice is
suboptimal if you choose a suboptimal separator sequence.
Therefore, here are some recommendations:
You should avoid \n, and \r, as this will prevent a successful
line-by-line read. Additionally, avoid the /, and \\, as Jacksum
won't be able to detect where the path begins. Furthermore, you
should a character sequence that could be part of the encoding
character set for hashes, such as a-z, 0-9 for hex, and the
character that you specified with -G if you also set -g. The same
applies to A-Z, 0-9 for hex-uppercase, = for base64, - for bb, etc.
Additionally, you should avoid a character sequence that could be
part of the file size (0-9) or the timestamp (depends on the -t
setting) for the same reasons.
Examples that are suitable for most cases include " ", "\t", ",",
";", ":", "~", "@", "_", or any other sequence that makes the
separator unique such as " ", ", ", "; ", "\t\t", "---", "...",
etc.
If the default parser is unable to parse the output, you can still
write your own compatibility file; see also -C.
See also:
option -F
Available since:
version 1.0.0 of Jacksum.
--threads-hashing <threads>
If multiple algorithms have been selected for calculation or
verification, the value of <threads> sets the maximum number of
parallel hashing threads. Each working thread can calculate one hash
value using a particular algorithm. You can select more algorithms
for parallelism than <threads> are available.
The LPT (Longest Processing Time) algorithm is used, which means
that the slowest algorithm selected determines the minimum
computation time.
By default, if this option is omitted or if <threads> is set to
the value "max", <threads> is set to the number of available
processors. You cannot get better performance by setting <threads>
above the value of max, as you can only use the computing power that
is physically available. If the value for <threads> is set higher
than the number of threads actually needed, only the required number
of threads will be started.
See also:
option --threads-reading
Available since:
version 3.3.0 of Jacksum.
--threads-reading <threads>
Sets the number of parallel working threads for reading. That means
how many threads are allowed to read files from the file system
simultaneously.
By default, if this option is omitted, <threads> is set to 1. If
<threads> is set to 1, the output is produced in a predictable
order. If <threads> is set to a value greater than 1, the output is
produced in an unpredictable order, as the actual load on the
system can affect the speed of each thread. If <threads> is set to
the value "max", it is set to the number of available processors.
Recommendations:
- Set <threads> to a large value, or even to "max" if you want
to read/hash files from solid-state drives (SSD), as these
drives have no physical moving parts and are therefore fast,
benefiting from multiple readers. You could set <threads>
greater than "max", but usually you won't get better reading
performance in this case.
- Set <threads> to 1 if you want to read/hash files from HDDs,
CD-ROMs, DVDs, or external connected drives, as these
drives do not benefit from multiple readers. In fact, a larger
value for <threads> can significantly reduce read performance
in these cases.
Set <threads> to 1 if if you want the output in a predictable
order.
See also:
option --threads-hashing
Available since:
version 3.3.0 of Jacksum.
-t <format>
--timestamp <format>
A timestamp format. Java's formatter class
SimpleDateFormat will be used. Valid characters are
G Era designator
y Year
Y Week year
M Month in year (context sensitive)
L Month in year (standalone form)
w Week in year
W Week in month
D Day in year
d Day in month
F Day of week in month
E Day in week
u Day number of week (1 = Monday, ..., 7 = Sunday)
a Am/pm marker
H Hour in day (0-23)
k Hour in day (1-24)
K Hour in am/pm (0-11)
h Hour in am/pm (1-12)
m Minute in hour
s Second in minute
S Millisecond
z Time zone, general
Z Time zone, RFC 822
X Time zone, ISO 8601
In addition to the above, the following tokens are replaced:
#SEPARATOR will be replaced by the separator which you
can specify with option -s
#QUOTE will be replaced by one quote char (")
Predefined timestamp formats for <format>:
default
timestamps are formatted as "yyyyMMddHHmmssSSS"
expressed in the local time zone.
Available since version 1.3.0 of Jacksum, including
milliseconds since version 3.0.0 of Jacksum.
default-utc
timestamps are formatted as "yyyyMMddHHmmssSSS"
expressed in UTC.
Available since version 4.0.0 of Jacksum.
iso8601 or iso
"yyyy-MM-dd'T'HH:mm:ss.SSSXXX" is used to format timestamps
to be compatible with ISO 8601.
Available since version 3.0.0 of Jacksum, alias iso since
version 4.0.0 of Jacksum.
iso8601utc or iso-utc
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" is used to format timestamps
where the timestamp value is transformed to UTC.
Available since version 4.0.0 of Jacksum.
unixtime
timestamps are formatted by the POSIX time (the number of
seconds that have elapsed since midnight UTC on
1 January 1970).
Available since version 3.0.0 of Jacksum.
unixtime-ms
timestamps are formatted by the POSIX time (the number of
milliseconds that have elapsed since midnight UTC on
1 January 1970).
Available since version 3.0.0 of Jacksum.
A timestamp is only available if the data comes from a file. If the
data comes from standard input, from a sequence (-q), or from a
string (--string-list), no timestamp is written at all, and the token
#TIMESTAMP is replaced by an empty string.
A <format> that contains a space cannot be combined with the options
-c and -w, because a timestamp that contains a space cannot be told
apart from the fields that follow it. None of the predefined formats
above contains a space.
See also:
option -F
Available since:
version 1.6.0 of Jacksum.
-8
--utf8
Sets the UTF-8 charset for both stdout stream and stderr stream. It
is actually a shortcut for:
--charset-stdout UTF-8 --charset-stderr UTF-8
Note that you have to change the shell's default charset as well if
your shell's default charset is not UTF-8 and you want to be
compatible with this setting. On Microsoft Windows, you can change
that by changing the code page by entering: "CHCP 65001"
See also:
options --charset-stdout, and --charset-stderr
Available since:
version 3.0.0 of Jacksum.
-u <file>
--error-file <file>
"Ugly, undesirable, unforeseen, and uninvited" error messages of
the program go to a file rather than to standard error. The <file>
is excluded from the calculation process, and the program exits if
the file exists. You can set <file> to "/dev/null" (on Unix and
GNU/Linux) or to "nul" (on Microsoft Windows) in order to ignore
the output.
See also:
options -U, -o and -O
Available since:
version 1.6.0 of Jacksum.
Starting with version 3.0.0 of Jacksum, the file encoding has
been set to UTF-8.
-U <file>
--error-file-overwrite <file>
"Ugly, undesirable, unforeseen, and uninvited" error messages of
the program go to a file rather than to standard error. An existing
file will be overwritten without any warning. You can set <file> to
"/dev/null" (on Unix and GNU/Linux) or to "nul" (on Microsoft
Windows) in order to ignore the output.
See also:
options -u, -o and -O
Available since:
version 1.6.0 of Jacksum.
Starting with version 3.0.0 of Jacksum, the file encoding has been
set to UTF-8.
-v
--version
Prints the product name and version, and exits the program.
Additional information about the copyright and license will be
printed out if verbose info output has been requested:
> jacksum -v --info
See also:
> jacksum -h VERSION
Available since:
version 1.2.0 of Jacksum.
options --info with -v since version 3.7.0 of Jacksum.
-V <control set>
--verbose <control set>
The <control> must be at least one, and can be more than one, of the
following keywords separated by a comma:
info enable info
warnings enable warnings
errors enable errors
summary print summary at the end
details enable additional explanations
noinfo disable info
nowarnings disable warnings
noerrors disable errors
nosummary don't print the summary at the end
nodetails disable additional explanations
all means info,warnings,errors,summary,details
default means noinfo,warnings,errors,nosummary,
nodetails
none means noinfo,nowarnings,noerrors,nosummary,
nodetails
If you do not set --verbose, Jacksum selects a suitable
<control set> dependent on the operation it performs. By default
the <control set> is set to "default".
If you set one of the following options, <control set> is set to
"all", because usually you do not want to miss any information for
these operations:
--check-file, --check-line, or -a unknown:<length>
If you set option --version, <control set> ist set to "none".
If you set option --info, <control set> is set to "info".
The keyword "details" currently controls whether the option --info
prints the explanation of the value of "broken:" in addition to
the value itself.
Available since:
version 1.6.0 of Jacksum.
The keywords "all" and "none" are available since version 3.0.0
of Jacksum.
The keywords "details" and "nodetails" are available since
version 4.0.0 of Jacksum.
-w <hash-file>
--wanted-list <hash-file>
This option puts Jacksum in wanted-list mode. In wanted-list mode,
Jacksum only prints files that match or do not match files in the
<hash-file>, depending on --wanted-list-filter.
The format of the <hash-file> is expected to be the default output,
but it can be specified by the --style option if it is not the
default.
Hash values are compared without respecting upper and lower case,
except if an encoding with a case sensitive alphabet has been set
by -E, see also option -e. The options -g and -G are not supported,
because grouped hash values cannot be parsed.
See also:
the options --wanted-list-charset, and --style.
Available since:
version 3.4.0 of Jacksum.
--wanted-list-filter <filter>
--match-filter <filter>
Filters the output produced by options -w and -e. <filter> must be
one or more of the following keywords, separated by a comma:
match show MATCHing files (with real name in brackets)
nomatch show NOt MATCHing files (with hash in brackets)
all <filter> is set to match,nomatch
default <filter> is set to positive
none does not print anything (useful if you are
interested in the summary only) or if you want
to define your own filter
positive <filter> is set to none,match (default)
negative <filter> ist set to none,nomatch
Matching file names are being printed with the name in brackets
that is given in the wanted hash list.
Non-matching file names are being printed with the hash in brackets,
because the hash was not found in the wanted hash list.
If this option is omitted, the <filter> is set to "positive".
Hashing occurs in any case regardless of the filter set.
See also:
options -w, and --list
Available since:
version 3.4.0 of Jacksum.
-x
--hex-lowercase
Lowercase hex output for the checksum is an alias for "-E hex".
See also:
options -X, and -E
Available since:
version 1.1.0 of Jacksum.
-X
--hex-uppercase
Uppercase hex output for the checksum is an alias for "-E hexup".
See also:
options -x, and -E
Available since:
version 1.1.0 of Jacksum.
-
A single dash is used to signify that Jacksum should read from
standard input (stdin). Bytes are read from the standard input in
binary mode, and the filename is set to "<stdin>".
Example:
> jacksum - < your.iso
--
A double dash is used to signify the end of command options, after
which only positional arguments are accepted.
For example, if you want to get all checksums for files in the
folder called '-', normally '-' would be considered the option to
read from stdin, but with '--' you can calculate checksums in that
folder.
Example:
> jacksum -- -
Available since:
version 3.0.0 of Jacksum.
ALGORITHMS
The following algorithms are supported:
adler32, adler-32
algorithm name:
Adler-32
length:
32 bits
type:
checksum
published:
1995
comment:
Adler32 was invented by Mark Adler in 1995. The specification
for Adler32 may be found in RFC 1950. Adler32 is a 32-bit
extension and improvement of the Fletcher algorithm, used in the
ITU-T X.224 / ISO 8073 standard. The default encoding is
decimal. Note that the Adler algorithm has never been defined
for widths other than 32 bits, and that an Adler8, an Adler16
or an Adler64 algorithm has never been suggested by Mark Adler.
The Adler8 and Adler16 that can be found in the literature were
constructed by Maxino ("Revisiting Fletcher and Adler
Checksums", 2006) for comparison purposes only; they use the
largest prime below 2^4 resp. 2^8 as the modulus (13 and 251).
An Adler64 exists in third-party implementations only.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- Haiku: -
- HashGarten: Algorithm -> adler32
- HP-UX: -
- IBM AIX: -
- Jacksum jacksum -a adler32
- Java API: java.util.zip.Adler32
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- openSUSE: -
- OpenSSL: -
- PHP: hash("adler32", $input);
- Plan 9: -
- Python: zlib.adler32
- SCO UnixWare: -
- Solaris: -
- Tru64: -
- Windows: -
- Wolfram: Hash[expr, "Adler32", "HexString"]
since:
Jacksum 1.0.0, alias "adler-32" since 1.2.0
implementation:
java.util.zip.Adler32 as provided by the JDK.
The alternative implementation from net.jacksum.algorithms is
used if option -A has been specified.
ascon-hash
algorithm name:
Ascon-Hash (v1.2)
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://ascon.iaik.tugraz.at/
comment:
Ascon is a family of authenticated encryption and hashing
algorithms designed to be lightweight and easy to implement,
even with added countermeasures against side-channel attacks.
Ascon has been selected as new standard for lightweight
cryptography in the NIST Lightweight Cryptography competition
(2019-2023). See also
https://csrc.nist.gov/projects/lightweight-cryptography/finalists
Ascon has also been selected as the primary choice for
lightweight authenticated encryption in the final portfolio of
the CAESAR competition (2014-2019).
Ascon is designed and maintained by a team of cryptographers
working for Graz University of Technology, Infineon Technologies,
Intel Labs, Lamarr Security Research, and Radboud University:
Christoph Dobraunig, Maria Eichlseder, Florian Mendel and Martin
Schläffer.
The Ascon family includes the hash functions Ascon-Hash and
Ascon-Hasha as well as the extendable output functions
Ascon-Xof and Ascon-Xofa with sponge-based modes of operation.
Both provide 128-bit security with a hash size of at least
256 bits. The hashing modes use the same lightweight 320-bit
permutation as the authenticated encryption modes.
In August 2025 NIST published the standard SP 800-232, which
specifies Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128 and
Ascon-CXOF128. Those standardized functions differ from the
Ascon v1.2 that is implemented here (different word order and
different initial values), so their hash values do not match.
Ascon-Hasha and Ascon-XofA have not been standardized.
There is no standard-compliant parameterization according to
HMAC for sponge-based hash functions (RFC 2104 / FIPS 198-1).
broken:
no; the best published attacks reach 2 of 12 rounds
(collisions), the full Ascon-Hash is unaffected; as a sponge
construction it is also immune to length-extension attacks
see also https://eprint.iacr.org/2019/1115
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.AsconDigest
ascon-hasha
algorithm name:
Ascon-Hasha (v1.2)
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://ascon.iaik.tugraz.at/
comment:
ascon-hasha is the secondary recommendation by the Ascon team.
See also ascon-hash.
broken:
no; no attack on the full Ascon-Hasha is known that is faster
than generic attacks; note that Ascon-Hasha absorbs with 8
instead of 12 rounds and therefore has a smaller security
margin than Ascon-Hash; as a sponge construction it is immune
to length-extension attacks
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.AsconDigest
ascon-xof
algorithm name:
Ascon-Xof (v1.2)
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://ascon.iaik.tugraz.at/
comment:
See also ascon-hash.
broken:
no; the best published attacks are preimage attacks on 2 of 12
rounds, the full Ascon-Xof is unaffected; as a sponge
construction it is also immune to length-extension attacks
see also https://eprint.iacr.org/2024/371
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.AsconXof
ascon-xofa
algorithm name:
Ascon-XofA (v1.2)
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://ascon.iaik.tugraz.at/
comment:
Ascon-xofA is the secondary recommendation by the Ascon team.
See also ascon-xof.
broken:
no; no attack on the full Ascon-XofA is known that is faster
than generic attacks; note that Ascon-XofA absorbs with 8
instead of 12 rounds and therefore has a smaller security
margin than Ascon-Xof; as a sponge construction it is immune to
length-extension attacks
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.AsconXofA
aststrsum, ast, strsum
algorithm name:
The AST (AT&T Software Technology) strsum PRNG (pseudo random
number generator) hash.
length:
32 bits
type:
non-cryptographic hash function, checksum
published:
11/2010
comment:
The AST strsum is a 32-bit PRNG hash with different parameter
values than the default PRNG hash. See also prng. The algorithm
can be expressed as
prng:init=0,mpy=0x63c63cd9,add=0x9c39c33d
compatibility:
See the compatibility list of prng; the method is called "ast"
rather than "prng".
since:
Jacksum 3.6.0
implementation:
net.jacksum.algorithms.checksums.PrngHash
belt-hash, belthash, belt
algorithm name:
belt-hash (STB 34.101.31)
length:
256 bits
type:
cryptographic hash function
published:
2011
website:
https://github.com/bcrypto/belt
comment:
belt-hash is the hash function of the Belarusian national
cryptographic standard STB 34.101.31 ("belt"). It builds a
256-bit hash from the belt-compress compression function, which
in turn is based on the 128-bit belt block cipher.
The belt standard was first published in 2007; belt-hash was
added with the second edition of STB 34.101.31 in 2011. The
official test vectors for belt-hash are given in annex A.23 of
the standard.
broken:
no; no attack on belt-hash itself has been published; note
however that the public cryptanalysis of belt-hash is thin
compared with SHA-2 or SHA-3: the third-party results published
so far target the underlying Bel-T block cipher and reach at
most 6 of its 8 rounds
since:
Jacksum 4.0.0
implementation:
net.jacksum.algorithms.md.BeltHash
blake<length>, blake-<length>
algorithm name:
BLAKE-<length>
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
12/2010
website:
https://131002.net/blake/
comment:
BLAKE is one of the five hash functions that made it into the
final round of the NIST SHA-3 competition. This is the
implementation of the submission to the third and final round
of the NIST SHA-3 competition. BLAKE has not been selected as a
base for SHA-3, but since 12/2012 there exists an extended
version called BLAKE2.
broken:
no; BLAKE was one of the five SHA-3 finalists and kept one of
the largest security margins of all candidates: the best
published attacks on the hash function reach 2.5 of 14 rounds
for BLAKE-256, the full BLAKE is unaffected; its successor
BLAKE2 is not broken either
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.BLAKE<length>
blake2b, blake2b-<length>, b2sum, b2sum-<length>
algorithm name:
BLAKE2b
length:
freely selectable, as long as it is a multiple of 8 and not
greater than 512. If <length> is omitted, <length> is set to 512
type:
cryptographic hash function
published:
12/2012
website:
https://blake2.net/
comment:
BLAKE2b is the successor of BLAKE-512.
Use -C tagged or -F "BLAKE2b (#FILENAME) = #DIGEST" to get the
"cksum -a blake2b" output format from the GNU Core
Utilities 9.0.
broken:
no; the best published attacks reach a small number of the 12
rounds, the full BLAKE2b is unaffected; unlike SHA-256 and
SHA-512, BLAKE2b is not vulnerable to length-extension attacks,
and it offers a built-in keyed mode that can be used instead of
HMAC
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/b2sum [-l <length>]
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd (GNU Coreutils 8.26+ 11/2016):
/usr/bin/b2sum [-l <length>]
- GNU/Hurd (GNU Coreutils 9.0+ 09/2021):
/usr/bin/cksum -a blake2b [-l <length>]
- GNU/Linux (GNU Coreutils 8.26+ 11/2016):
/usr/bin/b2sum [-l <length>]
- GNU/Linux (GNU Coreutils 9.0+ 09/2021):
/usr/bin/cksum -a blake2b [-l <length>]
- Go API: golang.org/x/crypto/blake2b.New(<byte-length>, nil)
- HashGarten: Algorithm -> blake2b[-<length>]
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a blake2b[-<length>]
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: /usr/bin/b2sum [-l <length>]
/usr/gnu/bin/cksum -a blake2b [-l <length>]
- openSUSE: /usr/bin/b2sum [-l <length>]
- OpenSSL 1.1.0+: openssl dgst -blake2b512
- PHP: -
- Plan 9: -
- Python 3.6+: hashlib.blake2b
- Solaris: -
- Tru64: -
- Ubuntu 17.04+: /usr/bin/b2sum [-l <length>]
- Windows: -
- Wolfram: Hash[expr, "BLAKE2b-512", "HexString"]
Hash[expr, {"BLAKE2b", <length>}, "HexString"]
since:
Jacksum 3.0.0
blake2bp, blake2bp-512
algorithm name:
BLAKE2bp
length:
512 bits
type:
cryptographic hash function
published:
12/2012
website:
https://blake2.net/
comment:
BLAKE2bp is a different algorithm from BLAKE2b. Each algorithm
produces a different hash value.
BLAKE2bp is a 4-way parallel algorithm designed for increased
performance on multicore or SIMD CPUs. BLAKE2bp can produce
digests of any size between 1 and 64 bytes
(8 and 512 bits).
Jacksum implements an iterative, single-threaded 512 bit
variant only.
broken:
no, the same as BLAKE2b: blake2bp only computes several BLAKE2b
instances in parallel and combines them, which introduces no
weakness of its own
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> blake2bp
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a blake2bp
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.0+: -
- PHP: -
- Plan 9: -
- Python 3.6+: -
- Solaris: -
- Tru64: -
- Ubuntu: -
- Windows: -
- Wolfram: Hash[expr, {"BLAKE2bp", 512}, "HexString"]
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.Blake2bp
(pre-release, single-threaded with buffer fix by jonelo)
blake2s, blake2s-<length>
algorithm name:
BLAKE2s
length:
freely selectable, as long as it is a multiple of 8 and not
greater than 256. If <length> is omitted, <length> is set to 256.
type:
cryptographic hash function
published:
12/2012
website:
https://blake2.net/
comment:
BLAKE2s is the successor of BLAKE-256.
BLAKE3 is the successor of BLAKE2.
broken:
no; the best published attacks reach a small number of the 10
rounds, the full BLAKE2s is unaffected; BLAKE2s is not
vulnerable to length-extension attacks and offers a built-in
keyed mode that can be used instead of HMAC
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/blake2s.New128()
golang.org/x/crypto/blake2s.New256()
- HashGarten: Algorithm -> blake2s[-<length>]
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a blake2s[-<length>]
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.0+: openssl dgst -blake2s256
- PHP: -
- Plan 9: -
- Python 3.6+: hashlib.blake2s
- Solaris: -
- Tru64: -
- Ubuntu: -
- Windows: -
- Wolfram: Hash[expr, "BLAKE2s-512", "HexString"]
Hash[expr, {"BLAKE2s", <length>}, "HexString"]
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.Blake2s
blake2sp, blake2sp-256
algorithm name:
BLAKE2sp
length:
256 bits
type:
cryptographic hash function
published:
12/2012
website:
https://blake2.net/
comment:
BLAKE2sp is a different algorithm from BLAKE2s. Each algorithm
produces a different hash value.
BLAKE2sp is an 8-way parallel algorithm designed for increased
performance on multicore or SIMD CPUs. BLAKE2sp can produce
digests of any size between 1 and 32 bytes
(8 and 256 bits).
Jacksum implements an iterative, single-threaded 256 bit
variant only.
broken:
no, the same as BLAKE2s: blake2sp only computes several BLAKE2s
instances in parallel and combines them, which introduces no
weakness of its own
compatibility:
- 7z: 7z h -scrcblake2sp
- 7zFM: File -> CRC -> BLAKE2sp
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> blake2sp
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a blake2sp
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.0+: -
- PHP: -
- Plan 9: -
- Python 3.6+: -
- Solaris: -
- Tru64: -
- Ubuntu: -
- Windows: -
- Wolfram: Hash[expr, {"BLAKE2sp", 256}, "HexString"]
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.Blake2sp
(pre-release, single-threaded with buffer fix by jonelo)
blake3, blake3-256
algorithm name:
BLAKE3
length:
256 bits
type:
cryptographic hash function
published:
01/2020
website:
https://github.com/BLAKE3-team/BLAKE3
comment:
BLAKE3 is a single algorithm, in contrast to BLAKE and BLAKE2,
which are algorithm families with multiple variants.
broken:
no; the best published attacks reach a small number of the 7
rounds, the full BLAKE3 is unaffected; as a Merkle tree over
the BLAKE2s round function BLAKE3 is not vulnerable to
length-extension attacks and offers built-in keyed and
key-derivation modes
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> blake3
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a blake3
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.0+: -
- PHP: -
- Plan 9: -
- Python 3.6+: -
- Solaris: -
- Tru64: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
io.github.rctcwyvrn.blake3, alternative implementation provided
by org.bouncycastle.crypto.digests.Blake3Digest
bluemidnightwish<length>, bluemidnightwish-<length>
algorithm name:
Blue Midnight Wish
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
09/2009
website:
https://web.archive.org/web/20161028114810/http://www.q2s.ntnu.no/sha3_nist_competition/start
comment:
"Blue Midnight Wish" is one of 14 hash functions that had made
it into the second round of the NIST SHA-3 competition
(2007-2012). "Blue Midnight Wish" was submitted by a team at
the Norwegian University of Science and Technology.
"Blue Midnight Wish" did not pass the final (3rd) round of the
NIST SHA-3 competition, see "broken" above. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
(Blue Midnight Wish specification from Sep 10, 2009)
broken:
no, but 2010: several distinguishers and partial collisions for
the full compression function are known, the cheapest one needs
about 20 calls; the hash function itself has no collision or
preimage attack, but these results were the reason why BMW did
not advance to the final round
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 4.0.0
implementation:
fr.cryptohash.BlueMidnightWish<length>
cksum
algorithm name:
POSIX 1003.2 CRC algorithm
length:
32 bits
type:
checksum, based on CRC
comment:
The default encoding is decimal.
G(x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 +
x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x +1
The Posix CRC cannot be described completely by the
Rocksoft-Model, because the algorithm includes the length to
the CRC. Without this peculiarity, the definition would be:
crc:32,04C11DB7,00000000,false,false,FFFFFFFF
With the additional length parameter it can be expressed as
crc:32,04C11DB7,00000000,false,false,FFFFFFFF,false
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/cksum
- Angstrom: -
- BeOS: /bin/cksum
- BusyBox: /bin/cksum
- CentOS: /bin/cksum
- DragonFly BSD: /usr/bin/cksum
- eComStation: C:\ecs\KLIBC\bin\cksum
- FreeBSD: /usr/bin/cksum
- FreeDOS: -
- GNU/Hurd: /usr/bin/cksum
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a crc
- GNU/Linux: /usr/bin/cksum
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a crc
- Go API: -
- Haiku: /bin/cksum
- HashGarten: Algorithm -> cksum
- HP-UX: /usr/bin/cksum
/usr/bin/sum -p
- IBM AIX: /usr/bin/cksum
- Jacksum: jacksum -a cksum
- Java API: -
- Kali Linux: /usr/bin/cksum
- macOS: /usr/bin/cksum
- Minix 3.2.1+: /usr/bin/cksum
- MS-DOS: -
- NetBSD: /usr/bin/cksum
- NetBSD 9.2+: /usr/bin/sum -a crc
/usr/bin/cksum -a crc
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum [-a crc]
- OpenSSL: -
- PHP: -
- Plan 9: -
- Python: -
- SCO UnixWare: /bin/cksum
- Solaris: /usr/bin/cksum
- Solaris 11 Express:
/usr/bin/sum --method=cksum
- Tcl: crc::cksum
- Tru64: CMD_ENV=xpg4;export CMD_ENV; /bin/cksum
- Windows: -
- Wolfram: -
since:
Jacksum 1.0.0
implementation:
crc:32,04C11DB7,00000000,false,false,FFFFFFFF,false
cksum_minix
algorithm name:
cksum algorithm on Minix 3.2.0 and earlier
length:
32 bits
type:
checksum
comment:
This is the Minix cksum implementation until Minix 3.2.0.
It cannot be described by the Rocksoft-Model, because the
algorithm uses a modified update method. It also differs from
the common cksum algorithm, because it doesn't incorporate the
message length into the crc and it also uses a different
polynomial.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> cksum_minix
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a cksum_minix
- Java API: -
- Kali Linux: -
- macOS: -
- Minix 3.2.0: /usr/bin/cksum
- Minix 3.2.1+: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- Python: -
- Solaris: -
- Tru64: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
crc:<width>,<poly>,<init>,<refIn>,<refOut>,<xorOut>[,<includeLen>[,<xorLen>]]
algorithm name:
CRC (Cyclic Redundancy Check), generic
length:
[1..64] bits
type:
CRC
comment:
With this generic CRC you can specify all CRC-algorithms which
can be described by the famous "Rocksoft (tm) Model CRC
Algorithm". The default encoding for the output is decimal.
You can change the output encoding by specifying one of the
options called -C, -E, -F, --style, -x, or -X.
Parameters after crc: must have at least 6, and can have 7 or 8
values. All values have to be separated by a comma.
The required parameters are:
<width>,<poly>,<init>,<refIn>,<refOut>,<xorOut>
The optional parameters are:
[,<includeLen>[,<xorLen>]]
<width>
width of the crc, expressed in bits. This is one less
than the width of the poly.
<poly>
the polynomial, specify as hex. The top bit of the poly
should be omitted. For example, if the poly is 10110,
you should specify 6. An important aspect of this
parameter is that it represents the unreflected poly;
the bottom bit of this parameter is always the LSB of
the divisor during the division regardless of whether
the algorithm being modelled is reflected.
In other words, for the normal representation of the
generator polynomial the most significant bit (=x^n)
of the generator polynomial is left out in the
hexadecimal representation (as it's always 1). The
hexadecimal polynomial contains only the coefficients
x^(n-1) ... x^0.
To view the poly in a non-normal representation
(reversed and Koopman), and to view the corresponding
reciprocal poly, just add the option --info.
<init>
this parameter specifies the initial value of the
register when the algorithm starts. Specify as hex.
<refIn>
this is a boolean parameter. If it is false, input
bytes are processed with bit 7 being treated as the
most significant bit (MSB) and bit 0 being treated as
the least significant bit. If this parameter is true,
each byte is reflected before being processed.
<refOut>
this is a boolean parameter. If it is set to false, the
final value in the register is fed into the xorOut
stage directly, otherwise, if this parameter is true,
the final register value is reflected first.
<xorOut>
this value is XORed to the final register value (after
the refOut stage) before the value is returned as the
official checksum, specify as hex. Obviously a xorOut
value of 0 has no impact.
Normally here ends the parameter list for the "Rocksoft (tm)
Model CRC Algorithm" schema. However, the Jacksum project
supports two additional parameters which can be optionally
specified in order to take the fact into account that some
famous CRCs (such as POSIX cksum, the FDDI CRC resp. the Plan 9
sum) include the length of the file/data to the checksum value.
Those are the parameters which can be separated by a comma:
<includeLen>
this is a boolean parameter. It is optional. If it is
omitted, no length is included to the CRC. If it is
set, one or more octets representing the length of the
file/data as a binary value, will be used to include the
length of the file to the checksum value (before the
refOut). If it is set to true, the most significant
octet of the length will be processed first to the
update method of the CRC. If it is set to false, the
least significant octet of the length will be processed
first to the update method of the CRC.
<xorLen>
this value is XORed to the length value before it gets
included to the CRC. Specify xorLen as hex. If xorLen
is omitted, the smallest number of octets capable of
representing the length of the file are being
processed. If xorLen is set, the exact number of bytes
are being processed that are required to store the
xorLen value.
since:
Available since Jacksum 1.7.0 (range [8..64] for <width>),
<includeLen> and <xorLen> since Jacksum 3.0.0,
additional range [1..7] for <width> since Jacksum 3.6.0
crc8, crc-8
algorithm name:
CRC-8
length:
8 bits
type:
CRC
comment:
this implementation of the CRC-8 (cyclic redundancy check) is
used in the System Management Bus (SMBus) and the Free Lossless
Audio Codec (FLAC) for example.
Generator poly is x^8 + x^2 + x^1 + 1.
The default encoding is decimal.
since:
Jacksum 1.6.0
implementation:
crc:8,7,0,false,false,0
crc16, crc-16
algorithm name:
CRC-16 (ARC)
length:
16 bits
type:
CRC
comment:
this implementation of the CRC-16 (cyclic redundancy check) is
the most popular form of CRC-16 algorithms.
The generator poly is x^16 + x^15 + x^2 + 1.
It is used by LHA, and ARC for example.
The default encoding is decimal.
since:
Jacksum 1.2.0
implementation:
crc:16,8005,0000,true,true,0000
crc16_x25, crc-16_x-25, fcs16, fcs-16
algorithm name:
CRC-16 (Frame Checking Sequence)
length:
16 bits
type:
CRC
comment:
The Frame Checking Sequence as defined in RFC 1662,
appendix C.2 (originally RFC 1331).
The default encoding is decimal.
since:
Jacksum 1.5.0 (aliases _x25 and _x-25 since 1.7.0)
implementation:
crc:16,1021,FFFF,true,true,FFFF
crc16_minix, crc-16_minix
algorithm name:
Minix' crc
length:
16 bits
type:
checksum
comment:
this is the Minix' crc algorithm. It cannot be entirely
described by the Rocksoft-Model, because it uses a non-standard
update method which won't be fixed due to compatibility reasons.
See also https://jacksum.net/downloads/minix-bug-151.txt
or https://bit.ly/minix-bug-id-151
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- Go API: -
- HashGarten: Algorithm -> crc16_minix
- GNU/Hurd: -
- GNU/Linux: -
- gpg: -
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc16_minix
- Java API: -
- Kali Linux: -
- macOS: -
- Minix 1.3+: /usr/bin/crc
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Tru64: -
- Windows: -
since:
Jacksum 3.0.0
implementation:
based on crc:16,1021,0000,false,false,0000
crc24, crc-24
algorithm name:
CRC-24
length:
24 bits
type:
CRC
comment:
this implementation of the CRC-24 (cyclic redundancy check) is
used by OpenPGP for example (RFC 9580, originally RFC 2440).
The default encoding is decimal.
compatibility:
- Bouncy Castle: org.bouncycastle.bcpg.CRC24 (bcpg-jdk)
- Java API: -
since:
Jacksum 1.6.0
implementation:
crc:24,864CFB,B704CE,false,false,000000
crc32, crc-32, fcs32, fcs-32
algorithm name:
CRC-32
length:
32 bits
type:
CRC
comment:
the standard algorithm CRC-32 (cyclic redundancy check) is
specified in ISO 3309, ISO/IEC 13239:2002 and ITU-T V.42, and it
is used by PKZip, gzip, png, Ethernet and WEP. That algorithm is
also known as FCS (frame checking sequence).
The default encoding is decimal.
compatibility:
- 7z (hex only): 7z h -scrccrc32
- 7zFM: File -> CRC -> CRC-32
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: /usr/bin/cksum -o 3
- FreeBSD: /usr/bin/cksum -o 3
- FreeDOS: \FDOS\BIN\MD5SUM /M=crc32
- HashGarten: Algorithm -> crc32
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/crc32.MakeTable(crc32.IEEE))
- gpg: -
- HashGarten: Algorithm -> crc32
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc32
- Java API: java.util.zip.CRC32
- Kali Linux: -
- macOS: /usr/bin/cksum -o 3
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("crc32b", $input);
- Plan 9: -
- PowerShell: -
- Python: zlib.crc32
- Solaris: -
- Tcl: crc::crc32
- Windows: -
- Wolfram: Hash[expr, "CRC32", "HexString"]
since:
Jacksum 1.0.0, alias crc-32 since 1.2.0, aliases fcs32 and
fcs-32 since 1.5.0
implementation:
java.util.zip.CRC32 as provided by the JDK or
net.jacksum.algorithms.crcs.FCS32 (if option -A is set) which
basically is an optimized version of
crc:32,04C11DB7,FFFFFFFF,true,true,FFFFFFFF
crc32c, crc-32c
algorithm name:
CRC-32c (Castagnoli, iSCSI)
length:
32 bits
type:
CRC
comment:
known as "Castagnoli CRC-32", see RFC 7143, section 13.1
(Internet Small Computer System Interface (iSCSI) Protocol):
Guy Castagnoli, Stefan Braeuer, Martin Herrmann,
"Optimization of Cyclic Redundancy-Check Codes with 24 and 32
Parity Bits", IEEE Transact. on Communications, Vol. 41,
No. 6, June 1993.
The default encoding is decimal.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/crc32.MakeTable(crc32.Castagnoli))
- gpg: -
- HashGarten: Algorithm -> crc32c
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc32c
- Java 9+: java.util.zip.CRC32C
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 7.4.0+: hash("crc32c", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
java.util.zip.CRC32c as provided by the JDK, or if option -A
has been set, net.jacksum.algorithms.crcs.CrcGeneric with
options crc:32,1EDC6F41,FFFFFFFF,true,true,FFFFFFFF
crc32_bzip2, crc-32_bzip-2
algorithm name:
CRC-32 (bzip2)
length:
32 bits
type:
CRC
comment:
This CRC is used by bzip2. The default encoding is decimal.
since:
Jacksum 1.7.0
implementation:
crc:32,04C11DB7,FFFFFFFF,false,false,FFFFFFFF
crc32_go-koopman, crc-32_go-koopman
algorithm name:
CRC-32 (GO KOOPMAN)
length:
32 bits
type:
CRC
comment:
This CRC is used by the Go API. The default encoding is decimal.
Note that the Go API on https://pkg.go.dev/hash/crc32
uses the reversed representation of the poly for the
const.Koopman (0xeb31d82e) instead of the normal
representation (0x741b8cd7). To specify the CRC using the
Rocksoft Model we have to reverse it again.
since:
Jacksum 4.0.0
implementation:
crc:32,741B8CD7,FFFFFFFF,true,true,FFFFFFFF
crc32_mpeg2, crc-32_mpeg-2
algorithm name:
CRC-32 (MPEG-2)
length:
32 bits
type:
CRC
comment:
this algorithm implements the MPEG specification of the CRC-32
calculation. The default encoding is decimal.
since:
Jacksum 1.4.0
implementation:
crc:32,04C11DB7,FFFFFFFF,false,false,00000000
crc32_php, crc-32_php
algorithm name:
CRC-32 (PHP's crc32)
length:
32 bits
type:
CRC
comment:
PHP's crc32. This is actually the CRC-32 that is also used by
bzip2, but the 4 bytes for the output are being mirrored.
Accordingly, this CRC cannot be described by the Rocksoft Model
CRC Algorithm scheme. The default encoding is decimal.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> crc32_php
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc32_php
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("crc32", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
crc:32,04C11DB7,FFFFFFFF,false,false,FFFFFFFF
using reflected bytes for the output
crc32_ubi, crc-32_ubi, ubicrc32, crc32_jamcrc, crc-32_jamcrc
algorithm name:
CRC-32 (UBICRC32 and JAMCRC)
length:
32 bits
type:
CRC
comment:
ubicrc32 is part of the Memory Technology Device Utilities for
Linux (mtd-utils). UBI (Latin: "where?") stands for "Unsorted
Block Images". The default encoding is decimal. Specify -E hex
in order to get the hex output that the ubicrc32 tool
produces. This algorithm is also known as JAMCRC.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: /usr/bin/ubicrc32
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> crc32_ubi
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc32_ubi
- Java API: -
- Kali Linux: /usr/bin/ubicrc32
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu (+mtd-utils): /usr/sbin/ubicrc32
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
crc:32,04C11DB7,FFFFFFFF,true,true,00000000
crc64, crc-64
algorithm name:
CRC-64 (often wrongly assumed as a FCS in ISO 3309)
length:
64 bits
type:
CRC
comment:
Generator poly is x^64 + x^4 + x^3 + x + 1.
The default encoding is hexadecimal.
The CRC is used by the SWISS-PROT and TrEMBL protein sequence
data banks resp. by their successor UniProt. A better
polynomial has been proposed for this purpose (David Jones,
"An Improved 64-bit Cyclic Redundancy Check for Protein
Sequences", 2002), but it has never been adopted.
Note:
Wikipedia claims for years that the poly of this CRC-64 is
defined in the ISO 3309 standard, and many sources on the web
(e.g. golang.org) and even books (e.g. "Python Cookbook, 2nd
Edition", 2005, O'Reilly, Recipe 2.30 "Calculating CRC-64
Cyclic Redundancy Checks") seem to have copied that
information unchecked.
If you read all the original ISO papers you come to the
conclusion that a 64 bit CRC was never published in ISO 3309 or
in any of the revised versions of it (ISO 3309:1984,
ISO/IEC 3309:1991, ISO/IEC 3309:1993, ISO/IEC 13239:2002).
The current HDLC is defined in the ISO/IEC 13239 and it does
not define a CRC 64 bit polynomial, and it never defined one in
any of the papers that have been withdrawn. It does however
define 8, 16, and 32 bit frame checking sequences (FCS).
See also https://issues.omg.org/issues/DDSIRTP25-34
since:
Jacksum 1.5.0
implementation:
crc:64,1B,0,true,true,0 -E hex
crc64_ecma, crc-64_ecma
algorithm name:
CRC-64 (ECMA-182)
length:
64 bits
type:
CRC
published:
1992
standard:
ECMA-182
comment:
CRC-64 as defined by the ECMA (European Computer Manufacturers
Association) in the standard ECMA-182, Annex B, page 51.
Used in DLT-1 tape cartridges, see also
https://www.ecma-international.org/publications/
files/ECMA-ST/Ecma-182.pdf
since:
Jacksum 3.0.0
implementation:
crc:64,42f0e1eba9ea3693,0,false,false,0 -E hex
crc64_go-iso, crc-64_go-iso
algorithm name:
CRC-64 (programming language GO, const ISO)
length:
64 bits
type:
CRC
comment:
Used in the crc64 package from the programming language GO.
See also https://golang.org/pkg/hash/crc64/
According to the website above, the poly x^64+x^4+x^3+x+1 is
defined in ISO 3309 (which actually isn't true, because ISO 3309
and the successors including ISO/IEC 13239:2002 do not specify a
64 bit poly at all, but a 16 and 32 bit poly).
Anyway, for the algorithm in Go, that polynomial is used.
The crc parameters init, refin, refout, and xorOut are
non-default. Note that the Go API documentation uses the reversed
representation of the poly for the const.ISO (0xD800000000000000)
instead of the normal representation (0x1B). To specify the CRC
using the Rocksoft Model we have to reverse it again.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/crc64.MakeTable(crc64.ISO))
- gpg: -
- HashGarten: Algorithm -> crc64_go-iso
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc64_go-iso
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
crc:64,1b,ffffffffffffffff,true,true,ffffffffffffffff -E hex
crc64_nvme, crc-64_nvme
algorithm name:
CRC-64 (NVM Express 64b CRC)
length:
64 bits
type:
CRC
comment:
Used in the NVM Express® NVM Command Set Specification,
Revision 1.0d, from December 28, 2023, page 81ff, see also
https://nvmexpress.org/
Note that on page 83 in the pdf the "Check"-value
11199E50_6128D175h is printed in bit-reversed representation,
i.e. without the final reflection of the register. With the
reflection the value is AE8B1486_0A799888h. Big-endian is the
standard for all hash values calculated by Jacksum.
The algorithm is also used by AWS' Amazon S3, where it is the
default checksum algorithm. The AWS SDK automatically
calculates CRC-based checksums for uploads as data is
transmitted over the network. The return value is Base64
encoded by the AWS SDK.
See also https://bit.ly/AWSCRC64NVME
since:
Jacksum 4.0.0
implementation:
crc:64,ad93d23594c93659,ffffffffffffffff,true,true,ffffffffffffffff -E hex
crc64_xz, crc-64_xz, crc64_go-ecma, crc-64_go-ecma
algorithm name:
CRC-64 (.xz, and prog lang GO, const ECMA)
length:
64 bits
type:
CRC
comment:
Used in the .xz format. See also the xz format specification,
section 6: https://tukaani.org/xz/xz-file-format.txt
Also used in the crc64 package from the programming language GO,
const ECMA See also https://golang.org/pkg/hash/crc64/
The poly is defined in the standard ECMA-182, but for the
algorithm in Go, only the polynomial is used from ECMA. The crc
parameters init, refin, refout, and xorOut are different.
Note that the Go API documentation uses the reversed
representation of the poly for the const.ECMA
(0xC96C5795D7870F42) rather than the normal representation
(0x42f0e1eba9ea3693). To specify the CRC using the Rocksoft
Model we have to reverse it again.
compatibility:
- 7z: 7z h -scrccrc64
- 7zFM: File -> CRC -> CRC-64
- Angstrom: -
- BeOS: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/crc64.MakeTable(crc64.ECMA))
- gpg: -
- HashGarten: Algorithm -> crc64_xz
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc64_xz
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
crc:64,42f0e1eba9ea3693,ffffffffffffffff,true,true,ffffffffffffffff -E hex
crc82, crc82_darc, crc-82, crc-82_darc
algorithm name:
CRC-82 (DARC)
length:
82 bits internally,
88 bits (MSB zero padded) for representation
type:
CRC
comment:
DARC stands for "DAta Radio Channel", and it is the CRC that is
used by the European Telecommunications Standard
ETSI EN 300 751.
Note: although 84 bits would be enough to represent the 82 bit
CRC in hex for example, Jacksum produces the output with 88 bits
(zero padding to the left) to guarantee the output to be always
a multiple of 8-bit bytes. In hex that means (ceil(82/8)=11)
bytes are used to represent that CRC, and the first 6 bits (big
endian view) will always be zero. In other words for example, in
hex representation the first nibble will always be zero. Other
encodings such as base64 require a sequence of 8-bit bytes
anyway.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> crc82_darc
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc82_darc
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.6.0
implementation:
net.jacksum.algorithms.crcs.CRC82_DARC (derived from
Mark Adler's public domain C-code on stackoverflow.com)
cubehash<length>, cubehash-<length>
algorithm name:
CubeHash
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
09/2009
website:
https://cubehash.cr.yp.to/
comment:
CubeHash is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition (2007-2012). CubeHash
was created by Programmer and Professor Daniel Julius Bernstein.
CubeHash did not pass the final (3rd) round of the NIST SHA-3
competition, but it is not broken. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
(CubeHash specification from Sept. 2009)
broken:
no; all published collision and preimage attacks target
variants with reduced round or block parameters, the
recommended parameter set CubeHash16/32 is unaffected
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 4.0.0
implementation:
fr.cryptohash.CubeHash<length>
dha256, dha-256
algorithm name:
DHA-256
length:
256 bits
type:
cryptographic hash function
published:
11/2005
website:
http://www.nist.gov/hash-function (archived)
http://csrc.nist.gov/groups/ST/hash/documents/ChangD_DHA256.pdf
comment:
In response to the SHA-1 vulnerability that was announced in
Feb. 2005, NIST held a Cryptographic Hash Workshop on
Oct. 31-Nov. 1, 2005 to solicit public input on its
cryptographic hash function policy and standards. DHA-256 was
presented on Nov 1, 2005 by South Korean scientists at this
first NIST Hash Workshop. The NIST conducted also a second
workshop. However, NIST did not select an algorithm immediately,
but held a public competition from 2007 to 2012
(SHA-3 Competition) to find a successor for SHA-1 and the
SHA-2 family.
broken:
no, but boomerang attacks reach 46 of 64 steps and a
pseudo-collision for the full function is known (2^127.5); the
full DHA-256 has no collision or preimage attack, but it has
received far less public analysis than SHA-256, which it was
designed to improve upon
since:
Jacksum 3.0.0
implementation:
de.flexiprovider.core.md.DHA256
echo<length>, echo-<length>
algorithm name:
ECHO
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
2008
website:
https://crypto.orange-labs.fr/ECHO/
comment:
ECHO is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition (2007-2012).
ECHO was submitted by France Telecom (it was rebranded as Orange
S.A. in July 2013). ECHO did not pass the final (3rd) round of
the NIST SHA-3 competition, see "broken" above.
This is the latest implementation according to
the second round of the NIST SHA-3 competition.
ECHO must not be confused with ECOH, because ECOH is also a hash
function that was submitted to the SHA-3 competition, but did
not advance to round 2.
broken:
no, but 2010: distinguishers for the full 8-round permutation
are known (2^151); the best collision attack on the hash
function reaches 5 of 8 rounds (2^112), the full ECHO has no
collision or preimage attack
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.ECHO<length>
elf, elf32, elf-32
algorithm name:
ELF
length:
32 bits
type:
hash function
comment:
hash function used in the UNIX (System V Release 4) ELF
(Executable and Linkable Format) for object files.
The default encoding is decimal.
since:
Jacksum 1.5.0
implementation:
net.jacksum.algorithms.checksums
ed2k, emule, edonkey
algorithm name:
eMule/eDonkey
length:
128 bits
type:
cryptographic hash function
comment:
this algorithm is used in eDonkey resp. eMule, it is based on
MD4, but returns different fingerprints for files >= 9500 KiB
(9,728,000 bytes).
The default encoding is hexadecimal.
broken:
yes; the ed2k hash is built from MD4, and MD4 collisions can be
computed in a fraction of a second, so colliding files with the
same ed2k hash can be produced at will; ed2k is only suitable
for identifying files in P2P networks and for detecting
accidental corruption, never for security purposes
see also https://eprint.iacr.org/2004/199.pdf
since:
Jacksum 1.5.0
implementation:
net.jacksum.algorithms.md.Edonkey
edonr<length>, edonr-<length>, edon-r<length>, edon-r-<length>
algorithm name:
Edon-R
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
10/2008
website:
https://csrc.nist.gov/projects/hash-functions/sha-3-project
comment:
"Edon-R" is one of the 51 hash functions that were submitted to
the first round of the NIST SHA-3 competition (2007-2012).
It was designed by a team around Danilo Gligoroski at the
Norwegian University of Science and Technology (NTNU).
Unlike most of its competitors, Edon-R is not built on a
Merkle-Damgård compression function, but on quasigroup string
transformations ("Latin squares"), which makes it one of the
fastest hash functions of the competition.
Edon-R did not make it into the second round of the NIST SHA-3
competition, because of three cryptanalytic results that were
published in 2009: a meet-in-the-middle preimage attack by
Khovratovich, Nikolic and Weinmann that needs less effort than
the security claim allows (the designers of Edon-R dispute the
complexity of that attack, see
https://eprint.iacr.org/2009/120), a distinguisher for the
compression function of Edon-R 512 by Novotney and Ferguson
(https://eprint.iacr.org/2009/378), and a key recovery attack
by Leurent against the secret-prefix construction
H(key || message), which is practical: 32 queries and 2^30
computations are sufficient for Edon-R 256.
No collision attack against Edon-R is known, and none of the
attacks above threatens the plain hashing of files. Still, a
hash function of the SHA-2 or SHA-3 family should be preferred
whenever data has to be protected, and Edon-R should not be
used to build a message authentication code.
Note that the "edonr" checksum of the ZFS filesystem is based
on Edon-R 512, but it is salted with a pool specific key, so
its values do not match the plain Edon-R values computed here.
broken:
partly, 2009: the preimage resistance is broken in theory (the
attack is faster than the security claim, but far from
practical), and the secret-prefix MAC construction
H(key || message) is broken in practice; no collision attack
against Edon-R is known
see also https://eprint.iacr.org/2009/135
since:
Jacksum 4.0.0
implementation:
net.jacksum.algorithms.md.EdonR
esch<length>
algorithm name:
Esch
length:
256 or 384 bits
type:
cryptographic hash function
published:
05/2021 (v1.2)
website:
https://sparkle-lwc.github.io/esch
comment:
Esch is a family of hash functions. Esch256 outputs digests of
256 bits, and Esch384 of 384 bits. They rely on the sponge
construction, like the current hash standard SHA-3.
The Esch family is actually part of the Sparkle suite which is
a collection of lightweight symmetric cryptographic primitives.
The Sparkle suite was one of the 10 finalists of the NIST
Lightweight Cryptography competition (2019-2023).
6 of the 10 members of the Sparkle team are from the University
of Luxembourg, and Esch is the name of a city in Luxembourg
that is very close to the campus of the University of
Luxembourg.
broken:
no; no attack on the full Esch is known that is faster than
generic attacks; Esch was a finalist of the NIST Lightweight
Cryptography competition (2019-2023) but was not selected; as a
sponge construction it is immune to length-extension attacks
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.Sparkle
fletcher16, fletcher-16
algorithm name:
Fletcher's checksum
length:
16 bits
type:
checksum
published:
01/1982
comment:
published 1982 by John G. Fletcher (1934-2012). The binary
transmitted message is divided into sections of length K, for
Fletcher-16 is K=8, so Fletcher-16 is independent of the
endianness, i. e. independent from the byte order of the input
stream to of the executed hardware. The modulus of the
calculation is M and M is in this implementation set to
2^K-1=255 for K=8.
The original work of John G. Fletcher examines only the case
K=8 with modulus 255 and 256.
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.checksums.Fletcher16
fnv-0_<length>
algorithm name:
FNV-0
length:
32, 64, 128, 256, 512 or 1024 bits
type:
non-cryptographic hash function
published:
1991
comment:
Fowler-Noll-Vo is a non-cryptographic hash function created by
Glenn Fowler, Landon Curt Noll, and Phong Vo.
The FNV-0 is the historic FNV algorithm that is deprecated.
The FNV-0 hashes all buffers that contain only 0 octets to a
hash value of 0. The FNV-1 and FNV-1a hash do not suffer from
this minor problem.
The output <length> can vary from 32 bits to 1024 bits. By
default, the file size is printed if <length> is set to 32 bit,
otherwise it is omitted. By default, hash value encoding is
decimal if <length> is set to 32 bit, otherwise it is
hexadecimal.
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.checksums.Fnv0_32, Fnv0_64, and Fnv0_n
fnv-1_<length>
algorithm name:
FNV-1
length:
32, 64, 128, 256, 512 or 1024 bits
type:
non-cryptographic hash function
published:
1991
comment:
Fowler-Noll-Vo is a non-cryptographic hash function created by
Glenn Fowler, Landon Curt Noll, and Phong Vo.
The output <length> can vary from 32 bits to 1024 bits. By
default, the file size is printed if <length> is set to 32 bit,
otherwise it is omitted. By default, hash value encoding is
decimal if <length> is set to 32 bit, otherwise it is
hexadecimal.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/fnv.New32()
hash/fnv.New64()
hash/fnv.New128()
- gpg: -
- HashGarten: Algorithm -> fnv-1_<length>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a fnv-1_<length>
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.4.0+: hash("fnv132", $input);
hash("fnv164", $input);
- Plan 9: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.checksums.Fnv1_32, Fnv1_64, and Fnv1_n
fnv-1a_<length>
algorithm name:
FNV-1a
length:
32, 64, 128, 256, 512 or 1024 bits
type:
non-cryptographic hash function
published:
1991
comment:
Fowler-Noll-Vo is a non-cryptographic hash function
created by Glenn Fowler, Landon Curt Noll, and Phong Vo.
The only difference between the FNV-1a hash and the FNV-1 hash
is the order of the xor and multiply in the update method.
The output <length> can vary from 32 bits to 1024 bits. By
default, the file size is printed if <length> is set to 32 bit,
otherwise it is omitted. By default, hash value encoding is
decimal if <length> is set to 32 bit, otherwise it is
hexadecimal.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- eComStation: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: hash/fnv.New32a()
hash/fnv.New64a()
hash/fnv.New128a()
- gpg: -
- HashGarten: Algorithm -> fnv-1a_<length>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a fnv-1a_<length>
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("fnv1a32", $input);
hash("fnv1a64", $input);
- Plan 9: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.checksums.Fnv1a_32, Fnv1a_64, and Fnv1a_n
fork256, fork-256
algorithm name:
FORK-256
length:
256 bits
type:
cryptographic hash function
published:
11/2005
website:
http://www.nist.gov/hash-function (archived)
http://www.csrc.nist.gov/pki/HashWorkshop/2005/Nov1_Presentations/Sung_FORK-256.pdf
http://dx.doi.org/10.1007/11799313_13
comment:
In response to the SHA-1 vulnerability that was announced in
Feb. 2005, NIST held a Cryptographic Hash Workshop on
Oct. 31-Nov. 1, 2005 to solicit public input on its cryptographic
hash function policy and standards. FORK-256 was presented on
Nov 1, 2005 at this first NIST Hash Workshop. The NIST conducted
also a second workshop. However, NIST did not select an algorithm
immediately, but held a public competition from 2007 to 2012
(SHA-3 Competition) to find a successor for SHA-1 and the SHA-2
family. Between 2006 and 2007 attacks on FORK-256 have been
published and in response the authors improved FORK-256 under the
name "New FORK-256". But also this one was discovered to be broken
in 2007.
broken:
yes, 2007: the collision resistance of the full FORK-256 is
broken in theory (at most 2^126.6 instead of 2^128), and
near-collisions for the full function can be computed in
practice for any given IV; FORK-256 must not be used for
security purposes
see also https://eprint.iacr.org/2007/185.pdf
since:
Jacksum 3.0.0
implementation:
de.flexiprovider.core.md.FORK256
fugue<length>, fugue-<length>
algorithm name:
Fugue
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
2008
website:
https://researcher.watson.ibm.com/researcher/view_group.php?id=3253
comment:
Fugue is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition (2007-2012). Fugue
was submitted by IBM.
Fugue did not pass the final (3rd) round of the NIST SHA-3
competition, but it is not broken. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
IBM improved the algorithm further and it is called Fugue 2.0,
see fugue2-<length>.
broken:
no; the best published results are distinguishers for the
output transformation and semi-free-start collisions for
reduced variants, the full Fugue has no collision or preimage
attack
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.Fugue<length>
fugue2-<length>
algorithm name:
Fugue 2.0
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
04/2012
website:
https://researcher.watson.ibm.com/researcher/view_group.php?id=3253
comment:
Fugue 2.0 is the tweak of Fugue that its designers Shai Halevi,
William E. Hall and Charanjit S. Jutla (IBM) published in April
2012, after the NIST SHA-3 competition had ended. It needs only
half to three quarters as many applications of the SMIX round
function per input word as Fugue does and is therefore faster;
it compensates for this with more final rounds.
Both families are instances of one parameterized design and
differ only in their initial vectors, in their TIX step and in
their parameters. See fugue<length> for the original Fugue.
Section 5.2 of the Fugue 2.0 specification defines all four
output lengths, but only the 256 bit variant was ever
implemented by its designers.
broken:
no; Fugue 2.0 is the 2012 tweak of Fugue and is at least as
strong as Fugue, for which no collision or preimage attack on
the full function is known either; note that Fugue 2.0 itself
has hardly been analysed by third parties, since it was
published after the SHA-3 competition had ended
since:
Jacksum 4.0.0
implementation:
net.jacksum.algorithms.md.Fugue2_<length>
gost, gost:<init>
algorithm name:
GOST R 34.11-94
length:
256 bits
type:
cryptographic hash function
published:
1994
standard:
GOST R 34.11-94
comment:
"GOsudarstvennyi STandard", Russian for "Government Standard".
Published in 1994 as the Russian standard GOST R 34.11-94
(adopted on May 23, 1994, in force since January 1, 1995).
The default encoding is hexadecimal.
The hash function is based on the GOST block cipher
GOST 28147-89. If you omit <init> or if you set <init> to
"default" it will initialize the underlying cipher with the
default S-boxes as also described in RFC 5831 (March 2010).
If you set <init> to "crypto-pro" it will initialize the cipher
with the S-Boxes as suggested by the Crypto-Pro company in
January 2006 as described in RFC 4357.
For the GOST-Standard from 2012 see streebog.
broken:
yes, 2008: both the collision resistance and the preimage
resistance of the full function are broken in theory
(collisions in 2^105 instead of 2^128, preimages in 2^192
instead of 2^256), but the attacks are far from practical; use
its successor streebog512 instead
see also https://www.iacr.org/archive/crypto2008/51570163/51570163.pdf
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- eComStation: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> gost
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a gost
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -md_gost94
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("gost", $input);
- PHP 5.6.0+: hash("gost-crypto", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0, init available since Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.GOST3411Digest
groestl<length>, groestl-<length>
algorithm name:
Grøstl
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
01/2011
website:
http://www.groestl.info/
comment:
Grøstl is one of the five hash functions that had made it into
the final round of the NIST SHA-3 competition (2007-2012). This
is the implementation according to the third and final round of
the NIST SHA-3 Competition.
broken:
no; Grøstl was the most deeply analysed of the five SHA-3
finalists: the best collision attacks on the hash function
reach 3 of 10 rounds and the best distinguisher covers 9 of 10
rounds of the permutation (2^368, 2012), the full Grøstl is
unaffected
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.Groestl<length>
hamsi<length>, hamsi-<length>
algorithm name:
Hamsi
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
09/2009
website:
https://www.esat.kuleuven.be/cosic/publications/article-1203.pdf
https://web.archive.org/web/20090209043001/http://homes.esat.kuleuven.be/~okucuk/hamsi/
comment:
Hamsi is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition
(2007-2012). Hamsi was submitted by Özgül Küçük, Belgium.
Hamsi did not pass the final (3rd) round of the
NIST SHA-3 competition, see "broken" above. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
(Hamsi specification from Sep 14, 2009)
broken:
partly, 2010: the second-preimage resistance of the full
Hamsi-256 is broken in theory (2^247 instead of 2^256, far from
practical); no collision attack against Hamsi is known, and
none of the attacks threatens the plain hashing of files
since:
Jacksum 4.0.0
implementation:
fr.cryptohash.Hamsi<length>
has160, has-160
algorithm name:
HAS-160
length:
160 bits
type:
cryptographic hash function
published:
1998
comment:
HAS-160 is both a cryptographic hash function and a Korean
TTA standard (Telecommunications Technology Association).
The default encoding is hexadecimal.
broken:
no, but the best collision attacks reach 53 of 80 steps (2^55)
and a semi-free-start collision reaches 65 of 80 steps; the
full HAS-160 is unaffected, but its 160-bit output limits the
collision resistance to 2^80, which is not sufficient anymore;
prefer at least 256 bits
since:
Jacksum 1.7.0
implementation:
gnu.crypto.hash.Has160 (by jonelo)
haval, haval_<length>_<rounds>
algorithm name:
HAVAL
length:
128, 160, 192, 224 or 256 bits
type:
cryptographic hash function
published:
1992
comment:
Haval was invented by Yuliang Zheng, Josef Pieprzyk, and
Jennifer Seberry in 1992. The Haval message-digest algorithm has
a variable output length, with variable number of rounds. The
output <length> can vary from 128 to 256 bits in increments of
32 bits. The number of <rounds> can vary from 3 to 5. The
default values (just "haval") are 128 and 3. The default
encoding is hexadecimal.
broken:
yes; collisions for the full HAVAL are known for every
supported number of passes: for 3 passes since 2004 (Wang et
al., practical) and for 4 and 5 passes since 2006 (Yu et al.);
the preimage resistance of 3-pass HAVAL is broken as well
(2008); HAVAL must not be used for security purposes
see also https://eprint.iacr.org/2004/199.pdf
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> haval_<length>_<rounds>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a haval_<length>_<rounds>
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- PHP: hash("haval<length>,<rounds>", $input);
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.4.0
implementation:
gnu.crypto.hash.Haval
hmac:<algo>[:<bits>]
algorithm name:
HMAC, the keyed-hash message authentication code.
length:
same length as the underlying hash function.
type:
keyed-hash message authentication code.
published:
02/1997
comment:
HMAC is a mechanism for message authentication using any
iterated cryptographic hash function in combination with a
secret shared key. See also RFC 2104.
The prefix "hmac:" or "hmac-" can be used to specify a HMAC.
Compatible algorithms:
The cryptographic strength of HMAC depends on the
properties of the underlying hash function.
To see a list of suitable hash functions enter
> jacksum --hmacs
The Key:
The HMAC requires a key which can be set by option -k.
The key can be of any length (keys longer than B bytes
are first hashed using H). However, less than L bytes
is strongly discouraged as it would decrease the
security strength of the function. Keys longer than L
bytes are acceptable but the extra length would not
significantly increase the function strength. The
recommended key length, whether a key follows the RFC
recommendation, and whether the key will be hashed, can be
seen for a HMAC by specifying the option --info.
Example:
> jacksum -a hmac:sha3-256 -k txt:test --info
...
key length should have min. bytes: 32
key length follows above recom.: false
key will be hashed: false
...
Truncated output:
A well-known practice with message authentication codes
is to truncate the output of the MAC and output only part of
the bits. This can be achieved by setting a value for
<bits>. <bits> must be a positive integer that describes the
new output size of the algorithm in bits. The <bits>
leftmost bits of the HMAC computation will be used for the
output.
If <bits> is not a multiple of 8, the output will be rounded
to the next multiple of 8, and the remaining bits will be
padded to zero.
If <bits> is zero or greater than the output of the
underlying algorithm, <bits> is set to the width of the hash
function.
It is possible to see whether a truncation specified by the
user follows the recommendation from RFC 2104 by specifying
the option --info.
Example:
> jacksum -a hmac:sha3-256:160 -k txt:test --info
...
truncate to bits: 160
truncate to bytes: 20
trunc. length should have min. bits: 128
trunc. length follows above recom.: true
...
RFC 2104 from February 1997 proposes denoting a realization
of HMAC that uses a hash function H with t bits of output as
HMAC-H-t. However, since there are algorithms that mark a
truncated version of a hash function already with a hyphen,
it would be not clear whether the hyphen truncates the hash
function or the HMAC. Therefore Jacksum requires the colon
to mark a truncated HMAC.
broken:
depends on the underlying hash function; note that a broken
hash function does not necessarily yield a broken HMAC:
HMAC-MD5 has no practical attack although MD5 itself is broken,
because the HMAC construction does not rely on collision
resistance; nevertheless HMAC should be instantiated with a
hash function that is not broken
compatibility:
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: -
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a hmac:<algo>[:<bits>] -k <key>
- Java API: Mac mac = Mac.getInstance("Hmac"+<algo>); mac.init(<key>); mac.doFinal(<message>);
- Kali Linux: -
- macOS: -
- Minix: -
- PHP: hash_hmac('<algo>', '<message>', '<key>');
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -<algo> -mac hmac -macopt hexkey:<key> <message>
- Plan 9: -
- PowerShell: -
- Python: hmac.new(<key>, <message>, hashlib.<algo>).hexdigest()
- Solaris: -
- Windows: -
- Wolfram: ResourceFunction["HMAC"][<message>, <key>, "<algo>"]
since:
Jacksum 3.7.0
implementation:
net.jacksum.algorithms.HMAC
jh<length>, jh-<length>
algorithm name:
JH
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
01/2011
website:
https://www3.ntu.edu.sg/home/wuhj/research/jh/
comment:
JH is one of the five hash functions that had made it into the
final round of the NIST SHA-3 competition (2007-2012). This is
the implementation according to the third and final round of the
NIST SHA-3 Competition. Author of JH is Hongjun Wu from
Singapore.
broken:
no, but 2011: a distinguisher for the full 42-round internal
permutation is known (2^304); the best semi-free-start
collisions for the compression function reach 37 of 42 rounds,
the full JH has no collision or preimage attack
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.JH<length>
joaat, joaat32, joaat-32
algorithm name:
Bob Jenkins' One-at-a-Time Hash (joaat)
length:
32 bits
type:
non-cryptographic hash function
published:
1997
website:
http://www.burtleburtle.net/bob/hash/doobs.html
comment:
Developed by Robert John Jenkins Junior (Bob Jenkins).
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> joaat
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a joaat
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- PHP 5.4.0+: hash("joaat", $input);
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.checksums.Joaat32
k12, kangaroo12, kangarootwelve
algorithm name:
KangarooTwelve
length:
256 bits
type:
XOF as a cryptographic hash function with a fixed length
published:
2016
website:
https://keccak.team/kangarootwelve.html
comment:
KangarooTwelve is an extendable-output function (XOF) which
supports arbitrary output lengths. It is derived from the Keccak
algorithm and it has a 128-bit security strength like SHAKE128.
An XOF can be specialized to a hash function by selecting a
fixed output length.
"To achieve 128-bit security strength, the output n must be
chosen long enough so that there are no generic attacks that
violate 128-bit security. So for 128-bit (second) preimage
security the output should be at least 128 bits, and for
128-bit collision security the output should be at least 256
bits." See also https://keccak.team/files/KangarooTwelve.pdf
Jacksum restricts the set of the supported values for the output
length to 256 bits in order to define a reasonable hash
function.
broken:
no; KangarooTwelve uses 12 rounds of the same Keccak-p
permutation for which the best published attacks reach 6 of the
24 rounds used by SHA-3, so the security margin is smaller than
that of SHA-3 but still substantial; as a sponge construction
it is immune to length-extension attacks
see also https://keccak.team/third_party.html
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> kangarootwelve
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a k12
- Java 9+: -
- Kali Linux: -
- KeccakSum: KeccakSum --k12 --hex --outputbits 256
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: -
- PHP 7.1+: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.Kangaroo
m14, marsupilami14, marsupilamifourteen
algorithm name:
MarsupilamiFourteen
length:
512 bits
type:
XOF as a cryptographic hash function with a fixed length
published:
2016
website:
https://keccak.team/kangarootwelve.html
comment:
MarsupilamiFourteen is an extendable-output function (XOF) which
supports arbitrary output lengths. It is derived from the Keccak
algorithm and it has a 256-bit security strength like SHAKE256.
An XOF can be specialized to a hash function by selecting a
fixed output length.
Jacksum restricts the set of the supported values for the output
length to 512 bits in order to define a reasonable hash
function.
broken:
no; MarsupilamiFourteen is KangarooTwelve with 14 instead of 12
rounds of the Keccak-p permutation and therefore has an even
larger security margin; the best published attacks on Keccak-p
reach 6 of the 24 rounds used by SHA-3; as a sponge
construction it is immune to length-extension attacks
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> marsupilamifourteen
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a m14
- Java 9+: -
- Kali Linux: -
- KeccakSum: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: -
- PHP 7.1+: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.Kangaroo
keccak<length>, keccak-<length>
algorithm name:
Keccak
length:
224, 256, 288, 384, or 512 bits
type:
cryptographic hash function
published:
01/2011
website:
https://keccak.team/
comment:
Keccak (pronounced like "ketchak") was designed by Guido
Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche.
Keccak is based on earlier hash function designs PANAMA and
RadioGatún.
On October 2, 2012, Keccak was selected as the winner of the
NIST hash function competition.
broken:
no; the best published collision attacks reach 6 of 24 rounds
and the best preimage attacks 4 of 24 rounds, the full Keccak
is unaffected; as a sponge construction it is also immune to
length-extension attacks
see also https://keccak.team/third_party.html
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.NewLegacyKeccak256()
golang.org/x/crypto/sha3.NewLegacyKeccak512()
- gpg: -
- HashGarten: Algorithm -> keccak<length>
- Homebrew: keccak-<length>sum
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a keccak<length>
- Java 9+: -
- Kali Linux: -
- KeccakSum: KeccakSum --sha3-<length> --no-suffix --outputbits <length> --hex
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: -
- PHP 7.1+: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: Hash[expr, "Keccak<length>", "HexString"]
Hash[expr, {"Keccak", <length>}, "HexString"]
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.Keccak<length>
kupyna-<length>
algorithm name:
Kupyna
length:
256, 384, or 512 bits
type:
cryptographic hash function
published:
2015
standard:
DSTU 7564:2014
comment:
The Kupyna hash function was approved as the new Ukrainian
standard DSTU 7564:2014 in 2015.
broken:
no; the best published attacks are rebound attacks that reach 5
of 10 rounds for the hash function (2^120) and 7 of 10 rounds
for the compression function, the full Kupyna is unaffected
see also https://eprint.iacr.org/2015/959.pdf
since:
Jacksum 3.0.0
lsh-<wordlength>-<length>
algorithm name:
LSH (Lightweight Secure Hash)
length:
the actual output <length> is dependent on the <wordlength>
value. <wordlength> can become 256 or 512 bits.
If <wordlength> is 256, <length> can become 224 or 256.
If <wordlength> is 512, <length> can become 224, 256, 384, or
512.
type:
cryptographic hash
published:
2014
website:
https://seed.kisa.or.kr/kisa/Board/22/detailView.do
standard:
KS X 3262
comment:
LSH is a national standard of South Korea (KS X 3262).
broken:
no, but the wide-pipe design makes free-start collisions and
pseudo-preimages easy to construct, and boomerang attacks reach
14 rounds (2^242 for LSH-256, 2^308 for LSH-512); the full LSH
has no collision or preimage attack
since:
Jacksum 3.0.0
implementation:
kr.re.nsr.crypto
luffa<length>, luffa-<length>
algorithm name:
Luffa v2.0.1
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
10/2009
website:
https://www.hitachi.com/rd/yrl/crypto/luffa/
comment:
Luffa is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition (2007-2012). Luffa
was submitted by Hitachi (and others).
Luffa did not pass the final (3rd) round of the NIST SHA-3
competition, see "broken" above.
This is the latest implementation according to the second round
of the NIST SHA-3 competition.
(Luffa specification ver. 2.0.1 from Oct 2, 2009)
broken:
no, but 2010: distinguishers for the full permutation are
known, and semi-free-start collisions reach 7 of 8 rounds
(2^104); the full Luffa has no collision or preimage attack
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.Luffa<length>
md2, md2sum
algorithm name:
MD2
length:
128 bits
type:
cryptographic hash function
published:
1989
comment:
the MD2 message digest algorithm as defined in RFC 1319.
RSA Laboratories, in their Bulletin #4, dated November 12, 1996,
recommends to update applications away from MD2 whenever it is
practical. Jacksum supports MD2 for compatibility and edu
purposes. The default encoding is hexadecimal.
Use option "--compat openssl" to get the openssl output format.
broken:
partly, 2005: the preimage resistance of the full MD2 is broken
in theory (2^97 instead of 2^128, far from practical), and
collisions are known for the compression function and for MD2
without its checksum; no collision attack against the full MD2
is known, but with 128 bits the generic collision bound is only
2^64; MD2 is obsolete, do not use it
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> md2
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a md2
- Java 5+: java.security.MessageDigest.
MessageDigest.getInstance("MD2");
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix 3.2.1+: /usr/bin/md2
/usr/bin/sum -a md2
/usr/bin/cksum -a md2
- NetBSD: /usr/bin/md2
- NetBSD 9.2+: /usr/bin/md2
/usr/bin/sum -a md2
/usr/bin/cksum -a md2
- PHP 5.3.0+: hash("md2", $input);
- MS-DOS: -
- NetBSD: /usr/bin/md2
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -md2
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows 7+: certutil -hashfile <file> MD2
- Wolfram: Hash[expr, "MD2", "HexString"]
since:
Jacksum 1.2.0
implementation:
gnu.crypto.hash.MD2
md4, md4sum
algorithm name:
MD4
length:
128 bits
type:
cryptographic hash function
published:
1990
comment:
the MD4 message digest algorithm as defined in RFC 1320.
RSA Laboratories, in their Bulletin #4, dated November 12, 1996,
recommends that MD4 should not be used. Jacksum supports MD4 for
compatibility and edu purposes.
The default encoding is hexadecimal.
Use option "--compat openssl" to get the openssl output format.
broken:
yes, 2004: collisions can be computed in a fraction of a second
on a standard PC (Wang et al.), and even the preimage
resistance of the full MD4 is broken (2^102, 2008); MD4 must
not be used for any security purpose, only for compatibility
with legacy formats
see also https://eprint.iacr.org/2004/199.pdf
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/md4.New()
- gpg: -
- HashGarten: Algorithm -> md4
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a md4
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -md4
- macOS: -
- Minix 3.2.1+: /usr/bin/md4
/usr/bin/sum -a md4
/usr/bin/cksum -a md4
- MS-DOS: -
- NetBSD: /usr/bin/md4
- NetBSD 9.2+: /usr/bin/md4
/usr/bin/sum -a md4
/usr/bin/cksum -a md4
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -md4
- PHP: hash("md4", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris 11 Express:
/usr/bin/sum --method=md4
- Windows 7+: certutil -hashfile <file> MD4
- Wolfram: Hash[expr, "MD4", "HexString"]
since:
Jacksum 1.2.0
implementation:
gnu.crypto.hash.MD4
md5, md5sum
algorithm name:
MD5
length:
128 bits
type:
cryptographic hash function
published:
1991
comment:
The MD5 message digest algorithm was designed by Ronald Rivest
in 1991, and it is defined in RFC 1321.
The default encoding is hexadecimal.
Use -C solaris-untagged or -C solaris-tagged to print the
Solaris digest style variants.
Use -C openssl to print the openssl style.
Use -C tagged to print the "cksum -a md5" style from
the GNU Core Utilities 9.0.
broken:
yes, 2004: identical-prefix collisions can be computed in
seconds and chosen-prefix collisions in hours on a standard PC;
the attack has been demonstrated against real X.509
certificates (2008) and was abused by the Flame malware (2012);
the preimage resistance is not broken (best attack 2^123.4),
but MD5 must not be used for signatures
see also https://eprint.iacr.org/2004/199.pdf
compatibility:
- 7z: -
- 7zFM 24.09+: File -> CRC -> MD5
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/md5sum
- Angstrom: /usr/bin/md5sum
- BeOS: /bin/md5sum
- BusyBox: /bin/md5sum
- CentOS: /bin/md5sum
- ClamAV: sigtool --md5
- DragonFly BSD: /sbin/md5
- eComStation: C:\ecs\KLIBC\bin\md5sum
- FreeBSD: /sbin/md5
- FreeDOS: \FDOS\BIN\MD5SUM [/M=md5]
- GNU/Hurd: /usr/bin/md5sum
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a md5
- GNU/Linux: /usr/bin/md5sum
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a md5
- Go API: -
- gpg: -
- Haiku: /bin/md5sum
- HashGarten: Algorithm -> md5
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a md5
- Java API: java.security.MessageDigest.
MessageDigest.getInstance("MD5");
- Kali Linux: /usr/bin/md5sum
- LibreSSL: openssl dgst -md5
- macOS: /usr/bin/md5
- Minix 3.2.1+: /usr/bin/md5
/usr/bin/sum -a md5
/usr/bin/cksum -a md5
- MS-DOS: -
- NetBSD: /usr/bin/md5
- NetBSD 9.2+: /usr/bin/md5
/usr/bin/sum -a md5
/usr/bin/cksum -a md5
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a md5
/usr/bin/md5sum
/usr/bin/digest -a md5
- OpenSSL: openssl dgst -md5
- PHP: hash("md5", $input);
- Plan 9: /bin/md5sum
- PowerShell: -
- Python 2.5+: hashlib.md5()
- PowerShell: Get-FileHash -Algorithm MD5
- Solaris 9: /usr/sbin/md5 (package SUNWkeymg)
- Solaris 10+: /usr/bin/digest -a md5
- Solaris 11 Express:
/usr/bin/sum --method=md5
/usr/bin/md5sum
- Windows 7+: certutil -hashfile <file> MD5
- Wolfram: Hash[expr, "MD5", "HexString"]
- Visopsys: /programs/md5
since:
Jacksum 1.0.0
implementation:
java.security.MessageDigest. gnu.crypto.hash.MD5 is the
alternative implementation and it will be used if you have set the
option -A.
md6, md6-<length>
algorithm name:
MD6
length:
freely selectable, as long as it is a multiple of 8 and not
greater than 512. If <length> is omitted, <length> is set to 256
type:
cryptographic hash function
published:
10/2008 (revised 01/2009)
website:
https://groups.csail.mit.edu/cis/md6/ (archived)
comment:
MD6 was designed by a team led by Ronald L. Rivest at MIT and
submitted to the first round of the NIST SHA-3 competition
(2007-2012). Unlike its predecessors MD4 and MD5 it is not a
Merkle-Damgård construction, but a hash tree: the message is
processed in blocks of 512 bytes which form the leaves of a
4-ary tree, so the computation can be parallelized.
MD6 did not advance to the second round of the competition.
The submitters withdrew it, because they could not prove in
the time the competition allowed that a version with few
enough rounds to be competitively fast resists differential
attacks. MD6 itself is not broken.
Jacksum uses the standard parameters of MD6: no key, mode
parameter L = 64 (fully hierarchical), and 40 + <length> / 4
rounds. That is what the md6sum tool of the submission
package uses by default.
The hash value is the last <length> bits of the 1024 bit
final chaining value, again as printed by md6sum. Note that
the *KAT_*.txt files of the submission package list the
leading bits of the untrimmed chaining value instead, so
they do not contain MD6 hash values.
broken:
no; the best published attacks reach 16 of the at least 80
rounds (collisions for the compression function, 2^30), the
full MD6 is unaffected; MD6 was withdrawn from the second round
of the SHA-3 competition by its designers because they could
not prove resistance against differential attacks for a round
number fast enough to be competitive, not because of an attack
since:
Jacksum 4.0.0
implementation:
net.jacksum.algorithms.md.MD6
mdc2, mdc-2
algorithm name:
MDC-2
length:
128 bits
type:
cryptographic hash function
published:
1988
comment:
The MDC2 (Modification Detection Code 2) algorithm is specified
in the ANSI X9.31 and ISO/IEC 10118-2 standards. It works in
conjunction with a block cipher (DES). OpenSSL can be
configured to support MDC2. MDC2 is also used by the HBCI
(Home Banking Computer Interface). The U.S. Patent 4,908,861
submitted by IBM, expired on August 28, 2007. The default
encoding is hexadecimal.
Use option "--compat openssl" to get the openssl output format.
broken:
yes; the variant implemented here is built on the block cipher
DES and produces only 128 bits, so collisions can be found
generically in about 2^64 operations, which is within reach
today; in addition Knudsen et al. showed in 2009 that MDC-2
does not even reach its ideal security level; MDC-2 is
obsolete, do not use it for security purposes
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> mdc2
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a mdc2
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -mdc2
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.kapott.hbci.security.MDC2
none
algorithm name:
none
length:
0 bits
type:
n/a
comment:
Calculates no checksum, it does not read the content of files,
it just determines the file size and time stamp if required.
since:
Jacksum 1.6.0
implementation:
net.jacksum.algorithms.primitive.None
panama
algorithm name:
PANAMA
length:
256 bits
type:
cryptographic hash function
published:
03/1998
comment:
PANAMA was designed by Joan Daemen (Belgium) and Craig Clapp
(USA) and presented in the paper "Fast Hashing and Stream
Encryption with PANAMA" on the 5th Fast Software Encryption
(FSE) workshop at Paris, France in March 1998.
RadioGatún is the successor of PANAMA.
broken:
yes, 2007: the hashing mode of Panama is broken in practice,
collisions need only about 2^6 evaluations of the state
updating function (Daemen and Van Assche), building on the 2^82
attack by Rijmen et al. from 2001; the Panama stream cipher is
not affected by this
see also http://radiogatun.noekeon.org/panama/
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.PANAMA
photon-beetle
algorithm name:
PHOTON-Beetle Hash
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://www.isical.ac.in/~lightweight/beetle/
comment:
PHOTON-Beetle was one of the ten finalists at the NIST
Lightweight Cryptography competition (2019-2023). See also
https://csrc.nist.gov/projects/lightweight-cryptography/finalists
PHOTON-Beetle was invented by Zhenzhen Bao, Avik Chakraborti,
Nilanjan Datta, Jian Guo, Mridul Nandi, Thomas Peyrin, and
Kan Yasuda.
broken:
no; no attack on the full PHOTON-Beetle Hash is known that is
faster than generic attacks; it was a finalist of the NIST
Lightweight Cryptography competition (2019-2023) but was not
selected; as a sponge construction it is immune to
length-extension attacks
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.PhotonBeetleDigest
prng, prng:[init=<init>][<separator>][mpy=<multiplier>][<separator>][add=<addend>]
algorithm name:
PRNG (pseudo random number generator) hash
length:
32 bits
type:
non-cryptographic hash function, checksum
published:
11/2010
comment:
The 32-bit PRNG hash can be found in Solaris 11 Express 2010.11
(but not in later releases) as well as in operating systems
derived from OpenSolaris resp. illumos such as SmartOS, OmniOS,
and Tribblix. The algorithm is simple and obvious, and default
values are known from the manpages. The encoding of the hash
value is decimal.
The PRNG hash calculates the hash using the formula:
hash := <init>
for each byte in the message to be hashed do
hash := hash * <multiplier> + <addend> + byte
return hash
The PRNG hash supports properties that control the algorithm.
These properties are optional key-value pairs, and the following
properties are supported:
init=<init> A 32 bit initial value.
The default value is 0x811c9dc5.
mpy=<multiplier> A 32 bit multiplier.
The default value is 0x01000193.
add=<addend> A 32 bit addend.
The default value is 0.
If at least one property is given, prng must be appended by a
colon. If a property is not given, it becomes the default value
as described above. The values can be specified decimal or
hexadecimal by prepending with the marker "0x". If one of the
values exceeds 0xFFFFFFFF, the algorithm will be rejected from
being created. Negative values are not supported, and will be
ignored. Properties can be separated by any character as long as
it is clear where the next property begins; the <separator> must
not be one of the characters in [0-9a-fA-F] if the preceding
value is in hexadecimal representation, and the <separator>
must not be one of the characters in [0-9] if the preceding
value is in decimal representation; it is recommended to use a
comma for the <separator>. Properties can be given in any order.
The default PRNG Hash can be expressed as
prng:init=0x811c9dc5,mpy=0x01000193,add=0
or just "prng".
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> prng
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a prng
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OmniOS: /usr/bin/sum -x prng
/usr/bin/cksum -x prng
- OpenIndiana: -
- OpenSSL: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- SmartOS: /usr/bin/sum -x prng
/usr/bin/cksum -x prng
- Solaris 11 Express:
/usr/bin/sum -x prng
/usr/bin/cksum -x prng
- Tribblix: /usr/bin/sum -x prng
/usr/bin/cksum -x prng
- Windows: -
- Wolfram: -
since:
Jacksum 3.6.0
implementation:
net.jacksum.algorithms.checksums.PrngHash
radiogatun, radiogatun:<wordlen>, rg<wordlen>, rg-<wordlen>
algorithm name:
RadioGatun[32] and RadioGatun[64]
length:
256 bits
type:
cryptographic hash function
published:
2006
website:
http://radiogatun.noekeon.org/
comment:
RadioGatun was designed by Guido Bertoni, Joan Daemen,
Michaël Peeters and Gilles Van Assche and presented at the
Second Cryptographic Hash Workshop, Santa Barbara, CA, USA in
August 2006.
In theory <wordlen> can become 1 to 64. However only 32 and 64
bits are implemented actually.
The <wordlen> is optional, so radiogatun or radiogatun:64
selects the RadioGatun[64] algorithm with 64-bit words.
rg32 and rg-32 are aliases for radiogatun:32, and
rg64 and rg-64 are aliases for radiogatun:64
Keccak is the successor of RadioGatún.
broken:
no; the best published analysis needs about 2^(11w) operations
for a word length of w bits and therefore does not beat the
security claim for the implemented word lengths 32 and 64;
actual collisions have only been demonstrated for toy word
lengths such as w = 2
see also https://www.iacr.org/archive/fse2009/56650128/56650128.pdf
since:
Jacksum 3.0.0
implementation:
fr.cryptohash.RadioGatun32 and fr.cryptohash.RadioGatun64
read
algorithm name:
read
length:
0 bits
type:
n/a
comment:
Calculates no checksum, but it does read the content of files,
it also determines the file size and time stamp if required.
since:
Jacksum 1.6.0
implementation:
net.jacksum.algorithms.primitive.Read
rmd128, rmd-128, ripemd128, ripemd-128, ripe-md128
algorithm name:
RIPEMD-128
length:
128 bits
type:
cryptographic hash function
published:
1996
comment:
a message digest, see also RIPEMD-160.
The default encoding is hexadecimal.
broken:
no, but 2013: a collision attack on the full compression
function and a distinguisher for the full hash function are
known (Landelle and Peyrin), the best collision attack on the
hash function itself reaches 40 of 64 steps; in addition the
128-bit output limits the collision resistance to 2^64; do not
confuse RIPEMD-128 with the original RIPEMD from 1990, for
which practical collisions have been known since 2004
see also https://eprint.iacr.org/2013/607
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> ripemd128
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a ripemd128
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("ripemd128", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.2.0, alias rmd128 and rmd-128 since 1.4.0
implementation:
gnu.crypto.hash.RipeMD128
rmd160, rmd-160, ripemd160, ripemd-160, ripe-md160
algorithm name:
RIPEMD-160
length:
160 bits
type:
cryptographic hash function
published:
1996
comment:
RIPEMD was developed in the framework of the EU project RIPE
(RACE Integrity Primitives Evaluation), used by GnuPG.
The default encoding is hexadecimal.
Use option "--style openssl" to get the openssl output format.
format.
broken:
no, but the best collision attacks reach 40 of 80 steps and are
practical at that step count (2024); the full RIPEMD-160 is
unaffected, but its 160-bit output limits the collision
resistance to 2^80, which is not sufficient anymore; prefer at
least 256 bits
see also https://eprint.iacr.org/2024/350
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: /sbin/rmd160
- FreeBSD 5.3+: /sbin/rmd160
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/ripemd160.New()
- gpg: gpg --print-md ripemd160
- HashGarten: Algorithm -> ripemd160
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a ripemd160
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -ripemd160
- macOS: -
- Minix 3.2.1+: /usr/bin/rmd160
/usr/bin/sum -a rmd160
/usr/bin/cksum -a rmd160
- MS-DOS: -
- NetBSD: /usr/bin/rmd160
- NetBSD 9.2+: /usr/bin/rmd160
/usr/bin/sum -a rmd160
/usr/bin/cksum -a rmd160
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -rmd160
openssl dgst -ripemd
openssl dgst -ripemd160
- PHP: hash("ripemd160", $input);
- Plan 9: -
- PowerShell: Get-FileHash -Algorithm RIPEMD160
- Python: -
- Solaris: -
- Windows: -
- Wolfram: Hash[expr, "RIPEMD160", "HexString"]
since:
Jacksum 1.2.0, alias rmd160 and rmd-160 since 1.4.0
implementation:
gnu.crypto.hash.RipeMD160
rmd256, rmd-256, ripemd256, ripemd-256, ripe-md256
algorithm name:
RIPEMD-256
length:
256 bits
type:
cryptographic hash function
published:
1996
comment:
a message digest, see also RIPEMD-160. RIPEMD-256 is as secure
as RIPEMD-128. The default encoding is hexadecimal.
broken:
no, but RIPEMD-256 is derived from RIPEMD-128 and, by its
designers' own statement, provides no higher security level
than RIPEMD-128: the longer output only reduces the risk of
accidental collisions, the collision resistance remains that of
a 128-bit hash function; see rmd128
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> ripemd256
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a ripemd256
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.3.0+: hash("ripemd256", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
org.bouncycastle.crypto.digests
rmd320, rmd-320, ripemd320, ripemd-320, ripe-md320
algorithm name:
RIPEMD-320
length:
320 bits
type:
hash
published:
1996
comment:
a message digest, see also RIPEMD-160. RIPEMD-320 is as secure
as RIPEMD-160. The default encoding is hexadecimal.
broken:
no, but RIPEMD-320 is derived from RIPEMD-160 and, by its
designers' own statement, provides no higher security level
than RIPEMD-160: the longer output only reduces the risk of
accidental collisions, the collision resistance remains that of
a 160-bit hash function; see rmd160
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> ripemd320
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a ripemd320
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.3.0+: hash("ripemd320", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
org.bouncycastle.crypto.digests
romulush, romulus-h
algorithm name:
Romulus-H
length:
256 bits
type:
cryptographic hash function
published:
05/2021 (v1.3)
website:
https://romulusae.github.io/romulus/
comment:
Romulus-H is a cryptographic hash function using the tweakable
block cipher Skinny-128-384+ internally.
Romulus (Romulus-H is one part of the Romulus submission) was
one of the 10 finalists of the NIST Lightweight Cryptography
competition (2019-2023).
Romulus was created by Tetsu Iwata, Mustafa Khairallah,
Kazuhiko Minematsu, Thomas Peyrin, and Chun Guo.
broken:
no; no attack on the full Romulus-H is known that is faster
than generic attacks; Romulus-H builds a 256-bit hash from the
tweakable block cipher SKINNY in Hirose's double-block-length
mode and was a finalist of the NIST Lightweight Cryptography
competition (2019-2023) but was not selected
since:
Jacksum 4.0.0
implementation:
net.jacksum.algorithms.md.Romulus_H
sha0, sha-0
algorithm name:
SHA-0
length:
160 bits
type:
cryptographic hash function
published:
1993
comment:
the Secure Hash Algorithm, as defined 1993 in the National
Institute of Standards and Technology's Federal Information
Processing Standard (FIPS PUB 180). It was withdrawn by NIST
in 1995 and was superseded by the revised version, published
in 1995 in FIPS PUB 180-1 and commonly referred to as
"SHA-1".
The default encoding is hexadecimal.
Use option "--style openssl" to get the openssl output format.
broken:
yes, 2004: the collision resistance of the full SHA-0 is broken
in practice, a collision was first computed in 2^39 operations
(Wang et al., 2005) and later in about one hour on a PC (Manuel
and Peyrin, 2008); NIST had already withdrawn SHA-0 in 1995, it
is supported for edu purposes only
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> sha0
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha0
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -sha
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -sha
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Sha0 (by jonelo)
sha-1, sha, sha1, sha1sum, sha160, sha-160, dss1
algorithm name:
SHA-1
length:
160 bits
type:
cryptographic hash function
published:
1995
standard:
NIST FIPS 180-1
comment:
the Secure Hash Algorithm, as defined 1995 in the National
Institute of Standards and Technology's Federal Information
Processing Standard (NIST FIPS 180-1).
The default encoding is hexadecimal.
Use -C solaris-tagged or -C solaris-untagged to print the
Solaris digest style variants.
Use -C openssl to print the openssl style.
Use -C tagged to print the "cksum -a sha1" style from
the GNU Core Utilities 9.0.
The alias called dss1 (SHA-1 as used with the Digital
Signature Standard, DSS) is used by OpenSSL.
broken:
yes, 02/2017: the first identical-prefix collision was computed
(SHAttered, 2^63.1), and in 01/2020 the first chosen-prefix
collision followed (SHA-1 is a Shambles, 2^63.4, about 45,000
USD of rented GPU time), which breaks SHA-1 for real protocols;
the preimage resistance is not broken (the best attacks reach
62 of 80 steps), but SHA-1 must not be used for signatures or
certificates anymore
see also https://shattered.io/ and https://sha-mbles.github.io/
compatibility:
- 7z: 7z h -scrcsha1
- 7zFM 24.09+: File -> CRC -> SHA-1
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sha1sum
/usr/bin/shasum [-a 1]
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha1sum
- CentOS: /bin/sha1sum
- ClamAV: sigtool --sha1
- DragonFly BSD: /sbin/sha1
- eComStation: C:\ecs\KLIBC\bin\sha1sum
- FreeBSD: /sbin/sha1
- FreeDOS: \FDOS\BIN\MD5SUM /M=sha
- GNU/Hurd: /usr/bin/sha1sum
/usr/bin/shasum [-a 1]
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha1
- GNU/Linux: /usr/bin/sha1sum
/usr/bin/shasum [-a 1]
(not available on every Linux)
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha1
- Go API: crypto/sha1.New()
- gpg: gpg --print-md sha1
- Haiku: /bin/sha1sum
- HashGarten: Algorithm -> sha-1
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha1
- Java API: java.security.MessageDigest.
MessageDigest.getInstance("SHA-1");
- Kali Linux: /usr/bin/sha1sum
/usr/bin/shasum [-a 1]
- LibreSSL: openssl dgst -sha1
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum [-a 1]
- Minix 3.2.1+: /usr/bin/sha1
/usr/bin/sum -a sha1
/usr/bin/cksum -a sha1
- MS-DOS: -
- NetBSD: /usr/bin/sha1
- NetBSD 9.2+: /usr/bin/sha1
/usr/bin/sum -a sha1
/usr/bin/cksum -a sha1
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a sha1
/usr/bin/sha1sum
/usr/bin/shasum [-a 1]
/usr/bin/digest -a sha1
- OpenSSL: openssl dgst -sha1
- PHP: hash("sha1", $input);
- Plan 9: /bin/sha1sum
- PowerShell: Get-FileHash -Algorithm SHA1
- Python 2.5+: hashlib.sha1()
- Solaris 10+: /usr/bin/digest -a sha1
- Solaris 11 Express:
/usr/bin/sum --method=sha1
/usr/bin/sha1sum
- Windows 7+: certutil -hashfile <file> SHA1
- Wolfram: Hash[expr, "SHA1", "HexString"]
since:
Jacksum 1.0.0, alias sha-1 since 1.2.0, aliases sha160 and
sha-160 since 1.5.0, aliases dss1 and sha1sum since 2.0.0,
default algorithm since 1.5.0 for the Jacksum 1.x family.
implementation:
java.security.MessageDigest as provided by the JRE.
gnu.crypto.hash.Sha160 is the alternative implementation and it
will be used if you have specified the option -A.
sha-224, sha224
algorithm name:
SHA-224
length:
224 bits
type:
cryptographic hash function
published:
2004
standard:
NIST FIPS 180-2
comment:
the Secure Hash Algorithm, as defined 2004 in the National
Institute of Standards and Technology's Federal Information
Processing Standard (NIST FIPS 180-2) and in RFC 3874.
SHA-224 is based on SHA-256, but it uses a different initial
value and the final hash is truncated to 224 bits.
The default encoding is hexadecimal.
Use -C tagged or -F "SHA224 (#FILENAME) = #DIGEST" to get the
"cksum -a sha224" output format from the GNU Core Utilities 9.0.
broken:
no, but legacy: the 224-bit output limits the collision
resistance to 2^112, and hash functions at that level have been
removed from the recommendations of the BSI (TR-02102-1);
moreover SHA-224 withholds only 32 bits of the internal state,
so a length-extension attack costs merely 2^32; prefer sha-256
or sha-512/256
see also https://www.bsi.bund.de/dok/TR-02102
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sha224sum
/usr/bin/shasum -a 224
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: /bin/sha224sum
- DragonFly BSD: -
- FreeBSD 12+: /sbin/sha224
- FreeDOS: -
- GNU/Hurd: /usr/bin/sha224sum
/usr/bin/shasum -a 224
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha224
- GNU/Linux: /usr/bin/sha224sum
(not available on every Linux)
/usr/bin/shasum -a 224
(not available on every Linux)
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha224
- Go API: crypto/sha256.New224()
- gpg: gpg --print-md sha224
- HashGarten: Algorithm -> sha-224
- Homebrew: sha3-224sum
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha224
- Java API: -
- Kali Linux: /usr/bin/sha224sum
/usr/bin/shasum -a 224
- LibreSSL: openssl dgst -sha224
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 224
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a sha224
/usr/bin/sha224sum
/usr/bin/shasum -a 224
- OpenSSL: openssl dgst -sha224
- PHP: hash("sha224", $input);
- Plan 9: -
- PowerShell: -
- Python 2.5+: hashlib.sha224()
- Solaris 10+: -
- Solaris 11.2+: /usr/bin/sha224sum
- Solaris 11 Express: -
- Windows: -
- Wolfram: Hash[expr, "SHA224", "HexString"]
Hash[expr, {"SHA", 224}, "HexString"]
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Sha224 (by jonelo)
sha-256, sha256
algorithm name:
SHA-256
length:
256 bits
type:
cryptographic hash function
published:
2001
standard:
NIST FIPS 180-2
comment:
the Secure Hash Algorithm, first published in 2001 as a draft
and defined in the National Institute of Standards and
Technology's Federal Information Processing Standard
(NIST FIPS 180-2) of August 2002. SHA-256 can be optionally
used by the file system called ZFS.
The default encoding is hexadecimal.
Use -C solaris-tagged or -C solaris-untagged to print the
Solaris digest style variants.
Use -C openssl to print the openssl style.
Use -C tagged to print the "cksum -a sha256" style from
the GNU Core Utilities 9.0.
broken:
no, but the best collision attacks reach 31 of 64 steps and are
practical at that step count (2024), the best preimage attacks
reach 41 of 64 steps; the full SHA-256 is unaffected, but as a
Merkle-Damgård construction it permits length-extension
attacks: use HMAC or sha-512/256 where that matters
see also https://eprint.iacr.org/2024/349.pdf
compatibility:
- 7z: 7z h -scrcsha256
- 7zFM 24.09+: File -> CRC -> SHA-256
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sha256sum
/usr/bin/shasum -a 256
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha256sum
- CentOS: /bin/sha256sum
- ClamAV: sigtool --sha256
- DragonFly BSD: /sbin/sha256
- FreeBSD 6+: /sbin/sha256
- FreeDOS: -
- GNU/Hurd: /usr/bin/sha256sum
/usr/bin/shasum -a 256
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha256
- GNU/Linux: /usr/bin/sha256sum
(not available on every Linux)
/usr/bin/shasum -a 256
(not available on every Linux)
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha256
- Go API: crypto/sha256.New()
- gpg: gpg --print-md sha256
- HashGarten: Algorithm -> sha-256
- Homebrew: sha3-256sum
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha256
- Java API: java.security.MessageDigest.
MessageDigest.getInstance("SHA-256");
- Kali Linux: /usr/bin/sha256sum
/usr/bin/shasum -a 256
- LibreSSL: openssl dgst -sha256
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 256
- Minix 3.2.1+: /usr/bin/sum -a sha256
/usr/bin/cksum -a sha256
- MS-DOS: -
- NetBSD 9.2+: /usr/bin/sum -a sha256
/usr/bin/cksum -a sha256
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a sha256
/usr/bin/sha256sum
/usr/bin/shasum -a 256
/usr/bin/digest -a sha256
- OpenSSL: openssl dgst -sha256
- PHP: hash("sha256", $input);
- Plan 9: -
- PowerShell: Get-FileHash -Algorithm SHA256
- Python 2.5+: hashlib.sha256()
- Solaris 10+: /usr/bin/digest -a sha256
- Solaris 11.2+: /usr/bin/sha256sum
- Solaris 11 Express:
/usr/bin/sum --method=sha256
- Windows 7+: certutil -hashfile <file> SHA256
- Wolfram: Hash[expr, "SHA256", "HexString"]
Hash[expr, {"SHA", 256}, "HexString"]
since:
Jacksum 1.3.0
implementation:
java.security.MessageDigest as provided by the JRE.
gnu.crypto.hash.Sha256 is an alternative implementation and it
is used if you have specified option -A.
sha-384, sha384
algorithm name:
SHA-384
length:
384 bits
type:
cryptographic hash function
published:
2001
standard:
NIST FIPS 180-2
comment:
the Secure Hash Algorithm, first published in 2001 as a draft
and defined in the National Institute of Standards and
Technology's Federal Information Processing Standard
(NIST FIPS 180-2) of August 2002.
The default encoding is hexadecimal.
Use -C solaris-tagged or -C solaris-untagged to print the
Solaris digest style variants.
Use -C openssl to print the openssl style.
Use -C tagged to print the "cksum -a sha384" style from
the GNU Core Utilities 9.0.
broken:
no; the best collision attacks against the underlying SHA-512
reach 31 of 80 steps, the full function is unaffected; unlike
sha-512, SHA-384 truncates the internal state by 128 bits and
is therefore not vulnerable to length-extension attacks
compatibility:
- 7z: -
- 7zFM 24.09+: File -> CRC -> SHA-384
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sha384sum
/usr/bin/shasum -a 384
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: /bin/sha384sum
- DragonFly BSD: -
- FreeBSD 11+: /sbin/sha384 (prob. earlier)
- FreeDOS: -
- GNU/Hurd: /usr/bin/sha384sum
/usr/bin/shasum -a 384
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha384
- GNU/Linux: /usr/bin/sha384sum
(not available on every Linux)
/usr/bin/shasum -a 384
(not available on every Linux)
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha384
- Go API: crypto/sha512.New384()
- gpg: gpg --print-md sha384
- HashGarten: Algorithm -> sha-384
- Homebrew: sha3-384sum
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha384
- Java API: java.security.MessageDigest.
MessageDigest.getInstance("SHA-384");
- Kali Linux: /usr/bin/sha384sum
/usr/bin/shasum -a 384
- LibreSSL: openssl dgst -sha384
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 384
- Minix 3.2.1+: /usr/bin/sum -a sha384
/usr/bin/cksum -a sha384
- MS-DOS: -
- NetBSD 9.2+: /usr/bin/sum -a sha384
/usr/bin/cksum -a sha384
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a sha384
/usr/bin/sha384sum
/usr/bin/shasum -a 384
/usr/bin/digest -a sha384
- OpenSSL: openssl dgst -sha384
- PHP: hash("sha384", $input);
- Plan 9: -
- PowerShell: Get-FileHash -Algorithm SHA384
- Python 2.5+: hashlib.sha384()
- Solaris 10+: /usr/bin/digest -a sha384
- Solaris 11.2+: /usr/bin/sha384sum
- Solaris 11 Express:
/usr/bin/sum --method=sha384
- Windows 7+: certutil -hashfile <file> SHA384
- Wolfram: Hash[expr, "SHA384", "HexString"]
Hash[expr, {"SHA", 384}, "HexString"]
since:
Jacksum 1.3.0
implementation:
java.security.MessageDigest as provided by the JRE.
gnu.crypto.hash.Sha384 is an alternative implementation and it
is used if you have specified option -A.
sha-512, sha512
algorithm name:
SHA-512
length:
512 bits
type:
cryptographic hash function
published:
2001
standard:
NIST FIPS 180-2
comment:
the Secure Hash Algorithm, first published in 2001 as a draft
and defined in the National Institute of Standards and
Technology's Federal Information Processing Standard
(NIST FIPS 180-2) of August 2002.
The default encoding is hexadecimal.
Use -C solaris-tagged or -C solaris-untagged to print the
Solaris digest style variants.
Use -C openssl to print the openssl style.
Use -C tagged to print the "cksum -a sha512" style from
the GNU Core Utilities 9.0.
broken:
no, but the best collision attacks reach 31 of 80 steps
(2^85.5, 2025) and are practical up to 29 steps, the best
preimage attacks reach 46 of 80 steps; the full SHA-512 is
unaffected, but as a Merkle-Damgård construction it permits
length-extension attacks: use HMAC or sha-512/256 where that
matters
compatibility:
- 7z: -
- 7zFM 24.09+: File -> CRC -> SHA-512
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sha512sum
/usr/bin/shasum -a 512
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha512sum
- CentOS: /bin/sha512sum
- DragonFly BSD: -
- FreeBSD 11+: /sbin/sha512 (probably also earlier)
- FreeDOS: -
- GNU/Hurd: /usr/bin/sha512sum
/usr/bin/shasum -a 512
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha512
- GNU/Linux: /usr/bin/sha512sum
(not available on every Linux)
/usr/bin/shasum -a 512
(not available on every Linux)
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sha512
- Go API: crypto/sha512.New()
- gpg: gpg --print-md sha512
- HashGarten: Algorithm -> sha-512
- Homebrew: sha3-512sum
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha512
- Java API: java.security.MessageDigest.
MessageDigest.getInstance("SHA-512");
- Kali Linux: /usr/bin/sha512sum
/usr/bin/shasum -a 512
- LibreSSL: openssl dgst -sha512
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 512
- Minix 3.2.1+: /usr/bin/sum -a sha512
/usr/bin/cksum -a sha512
- MS-DOS: -
- NetBSD 9.2+: /usr/bin/sum -a sha512
/usr/bin/cksum -a sha512
- NextStep: -
- OpenIndiana: /usr/gnu/bin/cksum -a sha512
/usr/bin/sha512sum
/usr/bin/shasum -a 512
/usr/bin/digest -a sha512
- OpenSSL: openssl dgst -sha512
- PHP: hash("sha512", $input);
- Plan 9: -
- PowerShell: Get-FileHash -Algorithm SHA512
- Python 2.5+: hashlib.sha512()
- Solaris 10+: /usr/bin/digest -a sha512
- Solaris 11.2+: /usr/bin/sha512sum
- Solaris 11 Express:
/usr/bin/sum --method=sha512
- Windows 7+: certutil -hashfile <file> SHA512
- Wolfram: Hash[expr, "SHA512", "HexString"]
Hash[expr, {"SHA", 512}, "HexString"]
since:
Jacksum 1.3.0
implementation:
java.security.MessageDigest as provided by the JRE.
gnu.crypto.hash.Sha512 is an alternative implementation and it
is used if you have specified option -A.
sha-512/224, sha512/224, sha512t224
algorithm name:
SHA-512/224
length:
224 bits
type:
cryptographic hash function
published:
03/2012
standard:
NIST FIPS 180-4
comment:
In March 2012, the secure hash standard was updated in
FIPS PUB 180-4, adding the hash function SHA-512/224.
broken:
no; SHA-512/224 is SHA-512 with a different initial value,
truncated to 224 bits, and the truncation removes the
length-extension weakness of sha-512; the 224-bit output limits
the collision resistance to 2^112 though, so sha-512/256 is the
better choice
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/shasum -a 512224
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: /usr/bin/shasum -a 512224
- GNU/Linux: /usr/bin/shasum -a 512224
(not available on every Linux)
- Go API: crypto/sha512.New512_224()
- gpg: -
- HashGarten: Algorithm -> sha-512/224
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha512/224
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA512/224");
- Kali Linux: -
- LibreSSL: -
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 512224
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: /usr/bin/shasum -a 512224
- OpenSSL 1.1.1+: openssl dgst -sha512-224
- PHP 7.1+: hash("sha512/224", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris 11.4+: /usr/bin/digest -a 512_t -t 224
- Ubuntu: /usr/bin/shasum -a 512224
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crytpo.digests.SHA512tDigest
sha-512/256, sha512/256, sha512t256
algorithm name:
SHA-512/256
length:
256 bits
type:
cryptographic hash function
published:
03/2012
standard:
NIST FIPS 180-4
comment:
In March 2012, the secure hash standard was updated in
FIPS 180-4, adding the hash function SHA-512/256.
broken:
no; SHA-512/256 is SHA-512 with a different initial value,
truncated to 256 bits, and the truncation removes the
length-extension weakness of sha-512; the best attacks against
SHA-512 reach 31 of 80 steps, the full function is unaffected
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/shasum -a 512256
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: /sbin/sha512t256
- FreeDOS: -
- GNU/Hurd: /usr/bin/shasum -a 512256
- GNU/Linux: /usr/bin/shasum -a 512256
(not available on every Linux)
- Go API: crypto/sha512.New512_256()
- gpg: -
- HashGarten: Algorithm -> sha-512/256
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha512/256
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA512/256");
- Kali Linux: -
- LibreSSL: -
- Mac OS X: -
- macOS 10.12+: /usr/bin/shasum -a 512256
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: /usr/bin/shasum -a 512256
- OpenSSL 1.1.1+: openssl dgst -sha512-256
- PHP 7.1+: hash("sha512/256", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris 11.4+: /usr/bin/digest -a 512_t -t 256
- Ubuntu: /usr/bin/shasum -a 512256
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crytpo.digests.SHA512tDigest
sha3-224, sha-3-224
algorithm name:
SHA-3
length:
224 bits
type:
cryptographic hash function
published:
08/2015
standard:
NIST FIPS 202 (SHA-3 Standard)
comment:
In 2007 NIST announced the competition called
"SHA-3 Cryptographic Hash Algorithm Competition" to determine
SHA-3. In 2012, the Keccak team's submission was announced as
the winner. However, in 2014 NIST made slight changes to the
Keccak proposal, and published FIPS 202. FIPS specifies
the new SHA-3 family of permutation-based hash functions that
were published as a standard on August 5, 2015. Note that only
the four fixed-length SHA-3 algorithms are NIST approved
hash algorithms: SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
broken:
no; the best published collision attacks reach 5 of 24 rounds
and the best preimage attacks 4 of 24 rounds, the full SHA3-224
is unaffected; as a sponge construction it is also immune to
length-extension attacks
see also https://eprint.iacr.org/2019/147
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha3sum [-a 224]
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.New224()
- gpg: -
- HashGarten: Algorithm -> sha3-224
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha3-224
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA3-224");
- Kali Linux: -
- KeccakSum: KeccakSum --sha3-224
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: openssl dgst -sha3-224
- PHP 7.1+: hash("sha3-224", $input);
- Plan 9: -
- PowerShell: -
- Python 3.6+: hashlib.sha3_224()
- Solaris 11.4+: /usr/bin/digest -a sha3_224
- Windows: -
- Wolfram: Hash[expr, "SHA3-224", "HexString"]
Hash[expr, {"SHA3", 224}, "HexString"]
since:
Jacksum 3.0.0
implementation:
java.security.MessageDigest, the alternative implementation
org.bouncycastle.crytpo.digests.SHA3Digest will be used if your
JRE/JDK doesn't support that algorithm, or if the option -A has
been specified.
sha3-256, sha-3-256
algorithm name:
SHA-3
length:
256 bits
type:
cryptographic hash function
published:
08/2015
standard:
NIST FIPS 202 (SHA-3 Standard)
comment:
In 2007 NIST announced the competition called
"SHA-3 Cryptographic Hash Algorithm Competition" to determine
SHA-3. In 2012, the Keccak team's submission was announced as
the winner. However, in 2014 NIST made slight changes to the
Keccak proposal, and published FIPS 202. FIPS specifies
the new SHA-3 family of permutation-based hash functions that
were published as a standard on August 5, 2015. Note that only
the four fixed-length SHA-3 algorithms are NIST approved hash
algorithms: SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
broken:
no; the best published collision attacks reach 5 of 24 rounds
and the best preimage attacks 4 of 24 rounds, the full SHA3-256
is unaffected; as a sponge construction it is also immune to
length-extension attacks
see also https://eprint.iacr.org/2019/147
compatibility:
- 7z: -
- 7zFM 24.09+: File -> CRC -> SHA3-256
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha3sum -a 256
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.New256()
- gpg: -
- HashGarten: Algorithm -> sha3-256
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha3-256
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA3-256");
- Kali Linux: -
- KeccakSum: KeccakSum --sha3-256
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: openssl dgst -sha3-256
- PHP 7.1+: hash("sha3-256", $input);
- Plan 9: -
- PowerShell: -
- Python 3.6+: hashlib.sha3_256()
- Solaris 11.4+: /usr/bin/digest -a sha3_256
- Windows: -
- Wolfram: Hash[expr, "SHA3-256", "HexString"]
Hash[expr, {"SHA3", 256}, "HexString"]
since:
Jacksum 3.0.0
implementation:
java.security.MessageDigest, the alternative implementation
org.bouncycastle.crytpo.digests.SHA3Digest will be used if your
JRE/JDK doesn't support that algorithm, or if the option -A has
been specified.
sha3-384, sha-3-384
algorithm name:
SHA-3
length:
384 bits
type:
cryptographic hash function
published:
08/2015
standard:
NIST FIPS 202 (SHA-3 Standard)
comment:
In 2007 NIST announced the competition called
"SHA-3 Cryptographic Hash Algorithm Competition"
to determine SHA-3. In 2012, the Keccak team's submission was
announced as the winner. However, in 2014 NIST made slight
changes to the Keccak proposal, and published FIPS 202. FIPS
specifies the new SHA-3 family of permutation-based hash
functions that were published as a standard on August 5, 2015.
Note that only the four fixed-length SHA-3 algorithms are NIST
approved hash algorithms: SHA3-224, SHA3-256, SHA3-384,
and SHA3-512.
broken:
no; the larger capacity of SHA3-384 makes it even harder to
attack than SHA3-256, for which the best published collision
attacks reach 5 of 24 rounds; as a sponge construction it is
also immune to length-extension attacks
see also https://keccak.team/third_party.html
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha3sum -a 384
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.New384()
- gpg: -
- HashGarten: Algorithm -> sha3-384
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha3-384
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA3-384");
- Kali Linux: -
- KeccakSum: KeccakSum --sha3-384
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NextStep: -
- NetBSD: -
- OpenIndiana: -
- OpenSSL 1.1.1+: openssl dgst -sha3-384
- PHP 7.1+: hash("sha3-384", $input);
- Plan 9: -
- PowerShell: -
- Python 3.6+: hashlib.sha3_384()
- Solaris 11.4+: /usr/bin/digest -a sha3_384
- Windows: -
- Wolfram: Hash[expr, "SHA3-384", "HexString"]
Hash[expr, {"SHA3", 384}, "HexString"]
since:
Jacksum 3.0.0
implementation:
java.security.MessageDigest, the alternative implementation
org.bouncycastle.crytpo.digests.SHA3Digest will be used if your
JRE/JDK doesn't support that algorithm, or if the option -A has
been specified.
sha3-512, sha-3-512
algorithm name:
SHA-3
length:
512 bits
type:
cryptographic hash function
published:
08/2015
standard:
NIST FIPS 202 (SHA-3 Standard)
comment:
In 2007 NIST announced the competition called
"SHA-3 Cryptographic Hash Algorithm Competition" to determine
SHA-3. In 2012, the Keccak team's submission was announced as
the winner. However, in 2014 NIST made slight changes to the
Keccak proposal, and published FIPS 202. FIPS specifies
the new SHA-3 family of permutation-based hash functions that
were published as a standard on August 5, 2015. Note that only
the four fixed-length SHA-3 algorithms are NIST approved
hash algorithms: SHA3-224, SHA3-256, SHA3-384, and SHA3-512.
broken:
no; the larger capacity of SHA3-512 makes it even harder to
attack than SHA3-256, for which the best published collision
attacks reach 5 of 24 rounds; as a sponge construction it is
also immune to length-extension attacks
see also https://keccak.team/third_party.html
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: /bin/sha3sum -a 512
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.New512()
- gpg: -
- HashGarten: Algorithm -> sha3-512
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sha3-512
- Java 9+: java.security.MessageDigest.
MessageDigest.getInstance("SHA3-512");
- Kali Linux: -
- KeccakSum: KeccakSum --sha3-512
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+: openssl dgst -sha3-512
- PHP 7.1+: hash("sha3-512", $input);
- Plan 9: -
- PowerShell: -
- Python 3.6+: hashlib.sha3_512()
- Solaris 11.4+: /usr/bin/digest -a sha3_512
- Windows: -
- Wolfram: Hash[expr, "SHA3-512", "HexString"]
Hash[expr, {"SHA3", 512}, "HexString"]
since:
Jacksum 3.0.0
implementation:
java.security.MessageDigest, the alternative implementation
org.bouncycastle.crytpo.digests.SHA3Digest will be used if your
JRE/JDK doesn't support that algorithm, or if the option -A has
been specified.
shabal<length>, shabal-<length>
algorithm name:
Shabal
length:
192, 224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
10/2008
website:
https://web.archive.org/web/20161203012059/http://www.shabal.com/
comment:
Shabal is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition
(2007-2012). Shabal was submitted by the French research
project SAPHIR to NIST's international competition on hash
functions.
Shabal did not pass the final (3rd) round of the NIST SHA-3
competition, see "broken" above. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
(Shabal specification from Oct 28, 2008)
broken:
no, but several non-randomness properties of the underlying
keyed permutation are known (2009-2010), as well as
pseudo-collisions for the compression function (2^84); the
designers showed that these distinguishers do not weaken Shabal
with its recommended parameters, and the full Shabal has no
collision or preimage attack
since:
Jacksum 4.0.0
implementation:
fr.cryptohash.Shabal<length>
shake128
algorithm name:
SHAKE128 (Secure Hash Algorithm KECCAK, 128 bit security)
length:
256 bits
type:
XOF as a cryptographic hash function with a fixed output length
published:
08/2015
website:
https://csrc.nist.gov/publications/detail/fips/202/final
standard:
NIST FIPS PUB 202 (SHA-3 Standard)
comment:
FIPS 202 from NIST specifies the new SHA-3 family of
permutation-based hash functions, which were published as a
standard on August 5, 2015.
In addition to the four fixed-length hash functions, FIPS 202
also defines two "eXtendable Output Functions (XOF)",
SHAKE128 and SHAKE256.
An XOF is a powerful new kind of cryptographic primitive that
offers the flexibility to produce outputs with any desired
length.
The suffixes "128" and "256" indicate the security strengths
that these two XOFs can generally support, in contrast to the
suffixes for the fixed-length-hash functions, which indicate
the digest lengths.
The XOF can be specialized to a hash function by selecting a
fixed output length.
The SHAKE128 function has a generic security strength of 128
bits against all attacks, provided that at least 2x128 bits
of the output are used.
Requesting more than 256 bits of output does not increase the
collision-resistance of the SHAKE128 function.
Jacksum takes those considerations into account and restricts
the set of the supported values for the output length to
256 bits in order to define a reasonable hash function.
broken:
no; SHAKE128 uses the same Keccak permutation as SHA-3, for
which the best published collision attacks reach 6 of 24
rounds; note that as an extendable output function SHAKE128
provides at most 128 bits of security no matter how long the
requested output is; it is immune to length-extension attacks
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.NewShake128()
- gpg: -
- HashGarten: Algorithm -> shake128
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a shake128
- Java 9+: -
- KeccakSum: KeccakSum [--shake128] --hex --outputbits 256
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+ (128 bits only): openssl dgst -shake128
- PHP 7.1+: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.SHAKEDigest
shake256
algorithm name:
SHAKE256 (Secure Hash Algorithm KECCAK, 256 bit security)
length:
512 bits
type:
XOF as a cryptographic hash function with a fixed output length
published:
08/2015
website:
https://csrc.nist.gov/publications/detail/fips/202/final
standard:
NIST FIPS PUB 202 (SHA-3 Standard)
comment:
FIPS 202 from NIST specifies the new SHA-3 family of
permutation-based hash functions, which were published as a
standard on August 5, 2015.
In addition to the four fixed-length hash functions, FIPS 202
also defines two "eXtendable Output Functions (XOF)",
SHAKE128 and SHAKE256.
An XOF is a powerful new kind of cryptographic primitive that
offers the flexibility to produce outputs with any desired
length.
The suffixes "128" and "256" indicate the security strengths
that these two XOFs can generally support, in contrast to the
suffixes for the fixed-length-hash functions, which indicate
the digest lengths.
The XOF can be specialized to a hash function by selecting a
fixed output length.
The SHAKE256 function has a generic security strength of 256
bits against all attacks, provided that at least 2x256 bits
of the output are used.
Requesting more than 512 bits of output does not increase the
collision-resistance of the SHAKE256 function.
Jacksum takes those considerations into account and restricts
the set of the supported values for the output length to
512 bits in order to define a reasonable hash function.
broken:
no; SHAKE256 uses the same Keccak permutation as SHA-3, for
which the best published collision attacks reach 6 of 24
rounds; note that as an extendable output function SHAKE256
provides at most 256 bits of security no matter how long the
requested output is; it is immune to length-extension attacks
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD 10.4+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: golang.org/x/crypto/sha3.NewShake256()
- gpg: -
- HashGarten: Algorithm -> shake256
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a shake256
- Java API: -
- Kali Linux: -
- KeccakSum: KeccakSum --shake256 --hex --outputbits 512
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL 1.1.1+ (256 bits): openssl dgst -shake256
- PHP 7.1+: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Ubuntu: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.SHAKEDigest
simd<length>, simd-<length>
algorithm name:
SIMD
length:
224, 256, 384 or 512 bits
type:
cryptographic hash function
published:
09/2009
website:
https://who.rocq.inria.fr/Gaetan.Leurent/simd.html
comment:
SIMD is one of 14 hash functions that had made it into the
second round of the NIST SHA-3 competition
(2007-2012). SIMD was submitted by Gaëtan Leurent, France.
SIMD did not pass the final (3rd) round of the
NIST SHA-3 competition, see "broken" above. This is the latest
implementation according to the second round of the NIST SHA-3
competition.
(SIMD specification from Sep 15, 2009)
broken:
no, but 2010: a distinguisher for the full compression function
with complexity 1 is known, and free-start near-collisions
reach 20 of 32 rounds (2^107); the full SIMD hash function has
no collision or preimage attack
see also https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7764.pdf
since:
Jacksum 4.0.0
implementation:
fr.cryptohash.SIMD<length>
skein-256, skein-256-<length>, skein256
algorithm name:
Skein-256
length:
customizable (<length> > 0 and <length> % 8 = 0),
<length> = 256 bits if <length> is not specified
type:
cryptographic hash function
published:
10/2010
website:
http://www.skein-hash.info/
https://www.schneier.com/academic/skein/
https://en.wikipedia.org/wiki/Skein_(hash_function)
comment:
Skein is a cryptographic hash function and one of the five
finalists in the NIST hash function competition.
The name Skein refers to how the Skein function intertwines the
input, similar to a skein of yarn. Skein was created by
Bruce Schneier, Niels Ferguson, Stefan Lucks, Doug Whiting,
Mihir Bellare, Tadayoshi Kohno, Jon Callas and Jesse Walker.
Skein supports internal state sizes of 256, 512 and 1024 bits,
and arbitrary output sizes.
This is the implementation of version 1.3 of Skein, which was
presented to NIST for the 3rd and final round of the competition
in October 2010.
Note: for the submission to NIST, the authors used an internal
state of 512 bits for the digest widths 224, 256, 384, and 512.
If you want to verify test vectors of the 256 bit width
submitted for the NIST competition, you must specify the
algorithm as skein-512-256 and not as skein-256. The skein256
command that comes with FreeBSD 11.1 and later, uses an internal
state of 256 bits.
broken:
no; the best published collision attacks reach 12 of 72 rounds
(2^126.5), the full Skein-256 is unaffected; Skein was one of
the five SHA-3 finalists and kept a large security margin
throughout the competition
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: /sbin/skein256
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> skein-256-<length>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a skein-256-<length>
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.SkeinDigest
skein-512, skein-512-<length>, skein512
algorithm name:
Skein-512
length:
customizable (<length> > 0 and <length> % 8 = 0),
<length> = 512 bits if <length> is not specified
type:
cryptographic hash function
published:
10/2010
website:
http://www.skein-hash.info/
https://www.schneier.com/academic/skein/
https://en.wikipedia.org/wiki/Skein_(hash_function)
comment:
Skein is a cryptographic hash function and one of the five
finalists in the NIST hash function competition.
The name Skein refers to how the Skein function intertwines the
input, similar to a skein of yarn. Skein was created by
Bruce Schneier, Niels Ferguson, Stefan Lucks, Doug Whiting,
Mihir Bellare, Tadayoshi Kohno, Jon Callas and Jesse Walker.
Skein supports internal state sizes of 256, 512 and 1024 bits,
and arbitrary output sizes.
This is the implementation of version 1.3 of Skein, which was
presented to NIST for the 3rd and final round of the competition
in October 2010.
Note: for the submission to NIST, the authors used an internal
state of 512 bits for the digest widths 224, 256, 384, and 512.
If you want to verify test vectors submitted for the NIST
competition, you must specify the algorithm as skein-512-224,
skein-512-256, skein-512-384 or skein-512-512.
broken:
no, but a preimage attack on the full 72-round Skein-512 is
known (2^511.76, 2012); it is only marginally faster than the
generic 2^512 and has no practical relevance; the best
collision attacks reach 14 of 72 rounds, the full Skein-512 has
no collision attack
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: /sbin/skein512
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> skein-512-<length>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a skein-512-<length>
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.SkeinDigest
skein-1024, skein-1024-<length>, skein1024
algorithm name:
Skein-1024
length:
customizable (<length> > 0 and <length> % 8 = 0),
<length> = 1024 bits if <length> is not specified
type:
cryptographic hash function
published:
10/2010
website:
http://www.skein-hash.info/
https://www.schneier.com/academic/skein/
https://en.wikipedia.org/wiki/Skein_(hash_function)
comment:
Skein is a cryptographic hash function and one of the five
finalists in the NIST hash function competition.
The name Skein refers to how the Skein function intertwines the
input, similar to a skein of yarn. Skein was created by
Bruce Schneier, Niels Ferguson, Stefan Lucks, Doug Whiting,
Mihir Bellare, Tadayoshi Kohno, Jon Callas and Jesse Walker.
Skein supports internal state sizes of 256, 512 and 1024 bits,
and arbitrary output sizes.
This is the implementation of version 1.3 of Skein, which was
presented to NIST for the 3rd and final round of the competition
in October 2010.
broken:
no; no attack on the full Skein-1024 is known; note that it
received considerably less public analysis than Skein-512,
which was the primary submission to the SHA-3 competition
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: /sbin/skein1024
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> skein-1024-<length>
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a skein-1024-<length>
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.SkeinDigest
streebog256, streebog-256
algorithm name:
Streebog Hash Function (GOST R 34.11-2012)
length:
256 bits
type:
cryptographic hash function
published:
2012
website:
https://www.streebog.net/
standards:
GOST R 34.11-2012
RFC 6986
comment:
Streebog is a cryptographic hash function defined in the Russian
national standard GOST R 34.11-2012. It was co-developed by the
FSB (Federalnaja Sluschba Besopasnosti), the Federal Security
Service of the Russian Federation to replace the obsolete GOST
hash function defined in the old standard GOST R 34.11-94, and
as an asymmetric reply to SHA-3 competition by the US NIST.
broken:
no; the second-preimage attack of 2014 applies to Streebog-512
only and is not better than generic attacks for the 256-bit
variant; no collision attack against Streebog is known; note
that the origin of the S-box remained undocumented until it was
reverse-engineered in 2016
see also https://eprint.iacr.org/2014/675
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> streebog256
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a streebog256
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -strebog256
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.GOST3411_2012_256Digest
streebog512, streebog-512
algorithm name:
Streebog Hash Function (GOST R 34.11-2012)
length:
512 bits
type:
cryptographic hash function
published:
2012
website:
https://www.streebog.net/
standards:
GOST R 34.11-2012
RFC 6986
comment:
Streebog is a cryptographic hash function defined in the Russian
national standard GOST R 34.11-2012. It was co-developed by the
FSB (Federalnaja Sluschba Besopasnosti), the Federal Security
Service of the Russian Federation to replace the obsolete GOST
hash function defined in the old standard GOST R 34.11-94, and
as an asymmetric reply to SHA-3 competition by the US NIST.
broken:
partly, 2014: the second-preimage resistance of the full
Streebog-512 is broken in theory for long messages (2^266
instead of 2^512, far from practical) because of the way the
HAIFA counter is used; no collision attack against Streebog is
known, and the attack does not threaten the plain hashing of
files
see also https://eprint.iacr.org/2014/675
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BusyBox: -
- BeOS: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> streebog512
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a streebog512
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -strebog512
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
org.bouncycastle.crypto.digests.GOST3411_2012_512Digest
sm3
algorithm name:
SM3
length:
256 bits
type:
cryptographic hash function
published:
12/2010
comment:
SM3 is a cryptographic hash function used in the "Chinese
National Standard". It was published by the State Cryptography
Administration on December 17, 2010 and was standardized
later as GM/T 0004-2012 (issued on March 21, 2012) and as the
national standard GB/T 32905-2016.
Use -C linux-tagged or -F "SM3 (#FILENAME) = #DIGEST" to get the
"cksum -a sm3" output format from the GNU Core Utilities 9.0.
broken:
no; the best published preimage attacks reach 32 of 64 steps
(2^254.5) and pseudo-collisions 33 of 64 steps, the full SM3 is
unaffected; as a Merkle-Damgård construction SM3 permits
length-extension attacks, so use HMAC where that matters
see also https://eprint.iacr.org/2012/640
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 11.1+: -
- FreeDOS: -
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sm3
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sm3
- Go API: -
- gpg: -
- HashGarten: Algorithm -> sm3
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sm3
- Java API: -
- Kali Linux: -
- LibreSSL: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sm3
- OpenSSL: openssl dgst -sm3
- PHP: -
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.0.0
sum<length>, sum-<length>
algorithm name:
Sum
length:
8, 16, 24, 32, 40, 48, 56, or 64 bits
type:
checksum
comment:
classic checksum, value is computed by adding together all
values in the input data stream modulo 2^<length>.
This algorithm does not consider the order of the bytes in the
data stream. And since the algorithm only adds up the values of
the bytes, all zero bytes are ignored.
The default encoding is decimal.
sum8 is used by the Intel HEX file format for example.
since:
Jacksum 1.3.0; 40, 48, and 56 bits are available since
Jacksum 3.0.0; 64 bits are available since Jacksum 3.6.0
implementation:
net.jacksum.algorithms.checksums.Sum*
sum_bsd, bsd, bsdsum, sumbsd
algorithm name:
BSD checksum algorithm
length:
16 bits
type:
checksum
comment:
output format is exactly like the native program sum (size in
1024 byte blocks). The default encoding is decimal.
See also sysv
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sum [-r]
- Angstrom: -
- BeOS: /bin/sum [-r]
- BusyBox: /bin/sum [-r]
- CentOS: -
- eComStation: C:\ecs\KLIBC\bin\sum [-r]
- FreeBSD: /usr/bin/sum
/usr/bin/cksum -o 1
- FreeDOS: -
- GNU/Hurd: /usr/bin/sum [-r]
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a bsd
- GNU/Linux: /usr/bin/sum [-r]
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a bsd
- Go API: -
- Haiku: /bin/sum [-r]
- HashGarten: Algorithm -> sum_bsd
- HP-UX: /usr/bin/sum -r
- IBM AIX: /usr/bin/sum [-r]
- Jacksum: jacksum -a sum_bsd
- Kali Linux: /usr/bin/sum [-r]
- macOS: /usr/bin/sum
/usr/bin/cksum -o 1
- Minix: -
- MS-DOS: -
- NetBSD: /usr/bin/sum -o 1
/usr/bin/sum -a old1
/usr/bin/cksum -o 1
/usr/bin/cksum -a old1
- NextStep: /usr/bin/sum
- OpenIndiana: /usr/bin/cksum -a bsd|--algorithm=bsd
/usr/gnu/bin/sum [-r]
- PHP: -
- Plan 9: /bin/sum -r
- SCO UnixWare: /bin/sum -r
- Solaris -10: /usr/ucb/sum
- Solaris 11 Express:
/usr/bin/sum -r|--bsd|--method=<bsd|ucb>
- Tcl: crc::sum [-bsd]
- Tru64 Unix: /usr/bin/sum [-r]
- Ultrix: /usr/bin/sum
- Windows: -
- OpenSSL: -
- Wolfram: -
since:
Jacksum 1.0.0, alias "bsdsum" since 1.2.0, alias "sumbsd"
since 1.6.0, "sum_bsd" since 2.0.0)
implementation:
net.jacksum.algorithms.checksums.SumBSD
sum_minix
algorithm name:
Minix' sum
length:
16 bits
type:
checksum
comment:
it is the same as the bsd algorithm, with the exception that
the size is printed in 512 byte blocks rather than in 1024 byte
blocks.
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> sum_minix
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a sum_minix
- Kali Linux: -
- macOS: -
- Minix: /usr/bin/sum
- MS-DOS: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: -
- Solaris: -
- Windows: -
- OpenSSL: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
net.jacksum.algorithms.SumBSD_Minix
sum_plan9, crc32_fddi
algorithm name:
FDDI CRC / Plan 9 sum
length:
32 bits
type:
CRC
comment:
The default encoding is decimal.
The sum command on Plan 9 prints the CRC in hex, in order to get
the output of Plan 9, specify the option -E hex.
The FDDI CRC cannot be described completely by the Rocksoft-
Model, because the algorithm includes the xor'ed length to the
CRC. Without this peculiarity, the definition would be:
crc:32,04C11DB7,00000000,true,true,00000000
With the additional length parameter the algorithm can be
expressed as
crc:32,04C11DB7,00000000,true,true,00000000,true,CC55CC55
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- HashGarten: Algorithm -> crc_fddi
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a crc_fddi
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- OpenIndiana: -
- OpenSSL: -
- PHP: -
- Plan 9: /bin/sum
- Solaris 11 Express:
/usr/bin/sum --method=fddi
- Windows: -
- OpenSSL: -
- Wolfram: -
since:
Jacksum 3.0.0
implementation:
crc:32,04C11DB7,00000000,true,true,00000000,true,CC55CC55
sum_sysv, sysv, sysvsum, sumsysv
algorithm name:
UNIX System V checksum algorithm
length:
16 bits
type:
checksum
comment:
output format is exactly like the native program sum
(size in 512 bytes blocks), see also bsd.
The default encoding is decimal.
compatibility:
- 7z: -
- 7zFM: -
- Azure Cloud Shell (Common Base Linux 10):
/usr/bin/sum -s|--sysv
- Angstrom: -
- BeOS: /bin/sum -s
- BusyBox: /bin/sum -s
- CentOS: -
- eComStation: C:\ecs\KLIBC\bin\sum -s|--sysv
- FreeBSD: /usr/bin/cksum -o 2
- FreeDOS: -
- GNU/Hurd: /usr/bin/sum -s
- GNU/Hurd (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sysv
- GNU/Linux: /usr/bin/sum -s
- GNU/Linux (with GNU Core Utilities 9.0):
/usr/bin/cksum -a sysv
- Go API: -
- Haiku: /bin/sum -s
- HashGarten: Algorithm -> sum_sysv
- HP-UX: /usr/bin/sum
- IBM AIX: -
- Jacksum: jacksum -a sum_sysv
- Kali Linux: /usr/bin/sum -s
- macOS: /usr/bin/cksum -o 2
- Minix 3.2.1+: /usr/bin/sum -a old2
/usr/bin/sum -o 2
/usr/bin/cksum -a old2
/usr/bin/cksum -o 2
- MS-DOS: -
- NetBSD: /usr/bin/cksum -o 2
/usr/bin/sum -o 2
/usr/bin/cksum -a old2
/usr/bin/sum -a old2
- NextStep: -
- OpenIndiana: /usr/bin/cksum -a sysv|--algorithm=sysv
/usr/gnu/bin/sum -s|--sysv
- OpenSSL: -
- PHP: -
- Plan 9: /bin/sum -5
- SCO UnixWare: /bin/sum
- Solaris -10: /usr/bin/sum
- Solaris 11 Express:
/usr/bin/sum -s|--sysv|
--method=<att|sys5|s5|default>
- Tcl: crc::sum -sysv
- Tru64 Unix: /usr/bin/sum -o
- Windows: -
- OpenSSL: -
- Wolfram: -
since:
Jacksum 1.2.0, alias "sumsysv" since 1.6.0,
alias "sum_sysv" since 2.0.0
implementation:
net.jacksum.algorithms.checksums.SumSysV
tiger128, tiger-128
algorithm name:
Tiger 128
length:
128 bits
type:
cryptographic hash function
published:
1996
comment:
the hash value is the first 128 bits of the result of Tiger-192.
The default encoding is hexadecimal.
broken:
no, but the same caveats as for tiger apply, and the truncation
to 128 bits additionally lowers the generic collision
resistance to 2^64, which is not sufficient anymore; the
truncation itself is not a weakness
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD 5.3+: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger128
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger128
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("tiger128,3", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Tiger160 (by jonelo)
tiger-128-4-php, tiger_128_4_php
algorithm name:
PHP's variant on Tiger with 32 rounds called tiger128,4
length:
128 bits
type:
cryptographic hash function
published:
2005
comment:
PHP's tiger128,4 extends the standard Tiger 128 from 24 (3*8)
to 32 (4*8) rounds. See also https://bit.ly/3BoVyo0
Actually the hash value is the first 128 bits of the result of
tiger-192-4-php.
The default encoding is hexadecimal.
broken:
no, but the same caveats as for tiger-192-4-php apply, and the
truncation to 128 bits additionally lowers the generic
collision resistance to 2^64, which is not sufficient anymore;
the truncation itself is not a weakness
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger128-4-php
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger128-4-php
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.1+: hash("tiger128,4", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.6.0
implementation:
mini-modification on bouncycastle's TigerDigest
tiger160, tiger-160
algorithm name:
Tiger 160
length:
160 bits
type:
cryptographic hash function
published:
1996
comment:
The hash value is the first 160 bits of the result of Tiger-192.
The default encoding is hexadecimal.
broken:
no, but the same caveats as for tiger apply, and the truncation
to 160 bits additionally lowers the generic collision
resistance to 2^80, which is not sufficient anymore; the
truncation itself is not a weakness
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger160
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger160
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP: hash("tiger160,3", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Tiger160 (by jonelo)
tiger-160-4-php, tiger_160_4_php
algorithm name:
PHP's variant on Tiger with 32 rounds called tiger160,4
length:
160 bits
type:
cryptographic hash function
published:
2005
comment:
PHP's tiger160,4 extends the standard Tiger 160 from 24 (3*8)
to 32 (4*8) rounds. See also https://bit.ly/3BoVyo0
Actually the hash value is the first 160 bits of the result of
tiger-192-4-php.
The default encoding is hexadecimal.
broken:
no, but the same caveats as for tiger-192-4-php apply, and the
truncation to 160 bits additionally lowers the generic
collision resistance to 2^80, which is not sufficient anymore;
the truncation itself is not a weakness
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger160-4-php
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger160-4-php
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.1+: hash("tiger160,4", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.6.0
implementation:
mini-modification on bouncycastle's TigerDigest
tiger, tiger192, tiger-192
algorithm name:
Tiger
length:
192 bits
type:
cryptographic hash function
published:
1996
comment:
developed by Ross Anderson and Eli Biham, 1995.
The default encoding is hexadecimal.
Note that PHP 5.3 and earlier has a bug in the tiger192,3
implementation (bug #60221 Tiger hash output byte order) which
resulted in a non-big-endian representation. PHP 5.4 fixed that.
See also https://bugs.php.net/bug.php?id=60221 and
https://www.php.net/ChangeLog-5.php#PHP_5_4
broken:
no, but 2007: the best collision attack reaches 19 of 24 rounds
(2^62) and a pseudo-near-collision for the full function needs
about 2^47 (Mendel and Rijmen); no collision attack against the
full Tiger is known, but the security margin has shrunk and the
192-bit output limits the generic collision resistance to 2^96
see also https://www.iacr.org/archive/asiacrypt2007/48330539/48330539.pdf
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.4+: hash("tiger192,3", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.4.0
implementation:
gnu.crypto.hash.Tiger
tiger-192-4-php, tiger_192_4_php
algorithm name:
PHP's variant on Tiger with 32 rounds called tiger192,4
length:
192 bits
type:
cryptographic hash function
published:
2005
comment:
Tiger was developed by Ross Anderson and Eli Biham, 1995.
The default encoding is hexadecimal.
PHP's tiger192,4 extends the standard Tiger from 24 (3*8)
to 32 (4*8) rounds. See also https://bit.ly/3BoVyo0
broken:
no, but this variant extends Tiger from 24 to 32 rounds and is
therefore at least as strong as Tiger: the best collision
attack on Tiger reaches 19 rounds, which is an even smaller
fraction here; the 192-bit output limits the generic collision
resistance to 2^96; see also tiger
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- CentOS: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> tiger-192-4-php
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a tiger-192-4-php
- Java API: -
- Kali Linux: -
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: -
- PHP 5.1+: hash("tiger192,4", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 3.6.0
implementation:
mini-modification on bouncycastle's TigerDigest
tiger2
algorithm name:
Tiger2
length:
192 bits
type:
cryptographic hash function
published:
2005
comment:
Tiger2 is a variant of Tiger by the same authors, Ross
Anderson and Eli Biham, that differs from Tiger only in the
padding byte. It was never published as a paper; its
official test vectors are dated 2005.
The default encoding is hexadecimal.
broken:
no, but Tiger2 differs from Tiger only in the padding byte, so
its cryptanalytic status is the same as that of Tiger: no
collision attack on the full function, but the best attack
reaches 19 of 24 rounds and the 192-bit output limits the
generic collision resistance to 2^96; see also tiger
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Tiger2 (by jonelo)
tth, tree:tiger, tree:tiger192, tree:tiger-192
algorithm name:
Tiger Tree Hash (based on a Hash tree/Merkle tree)
length:
192 bits
published:
Merkle tree was published in 1979, tiger was published in 1996.
type:
hash tree
comment:
tiger is the underlying algorithm for the hash tree.
The hash tree was invented by Ralph Merkle, 1979. A hash tree is
a tree of hashes in which the leaves are hashes of data blocks.
The Tiger Tree Hash uses a binary hash tree (two child nodes
under each node), with a data block size of 1024 bytes.
Tiger Tree Hashes are used in P2P file sharing protocols and
in file sharing applications.
The default encoding is base32_nopad.
broken:
no, the same as tiger: the Merkle tree mode introduces no
weakness of its own, the security depends entirely on the
underlying Tiger, for which no collision attack on the full
function is known, but whose 192-bit output limits the generic
collision resistance to 2^96; see also tiger
since:
Jacksum 1.7.0
implementation:
net.jacksum.algorithms.wrappers.MDTigerTree
tth2, tree:tiger2
algorithm name:
Tiger Tree Hash 2 (based on a Hash tree/Merkle tree)
length:
192 bits
published:
Merkle tree was published in 1979, tiger2 was published in 2005.
type:
hash tree
comment:
tiger2 is the underlying algorithm for the hash tree.
The hash tree was invented by Ralph Merkle, 1979. A hash tree is
a tree of hashes in which the leaves are hashes of data blocks.
The Tiger Tree Hash uses a binary hash tree (two child nodes
under each node), with a data block size of 1024 bytes.
Tree hashes are used in P2P file sharing protocols and
applications.
The default encoding is base32_nopad.
broken:
no, the same as tiger2: the Merkle tree mode introduces no
weakness of its own, the security depends entirely on the
underlying Tiger2, for which no collision attack on the full
function is known, but whose 192-bit output limits the generic
collision resistance to 2^96; see also tiger2
since:
Jacksum 1.7.0
implementation:
net.jacksum.algorithms.wrappers.MDTigerTree
vsh, vsh-1024
algorithm name:
VSH (Very Smooth Hash)
length:
1024 bits
type:
cryptographic hash function
published:
11/2005
website:
http://www.nist.gov/hash-function (archived)
http://www.csrc.nist.gov/pki/HashWorkshop/2005/Nov1_Presentations/LENSTRA_vsh.pdf (archived)
comment:
In response to the SHA-1 vulnerability that was announced in
Feb. 2005, NIST held a Cryptographic Hash Workshop on
Oct. 31-Nov. 1, 2005 to solicit public input on its
cryptographic hash function policy and standards.
VSH was presented on Nov 1, 2005 by scientists from the
Macquarie University, Sydney and Bell Laboratories (Lucent
Technologies) at this first NIST Hash Workshop.
The NIST conducted also a second workshop.
However, NIST did not select an algorithm immediately, but held
a public competition from 2007 to 2012 (SHA-3 Competition) to
find a successor for SHA-1 and the SHA-2 family.
broken:
partly, 2006: the preimage resistance is broken and VSH values
have undesirable multiplicative properties, so that related
hash values can be constructed at will (Saarinen); the
collision resistance is provably related to a factoring problem
and no collision attack is known, but VSH must not be used as a
general-purpose hash function
see also https://eprint.iacr.org/2006/103.pdf
since:
Jacksum 3.0.0
implementation:
de.flexiprovider.core.md.VSH
whirlpool0, whirlpool-0
algorithm name:
Whirlpool-0
length:
512 bits
type:
cryptographic hash function
published:
2000
comment:
The Whirlpool Hashing Function by Paulo S.L.M. Barreto and
Vincent Rijmen, 2000. This is the original specification of
Whirlpool from 2000.
The default encoding is hexadecimal.
broken:
no, but superseded: no attack targeting Whirlpool-0 itself has
been published, but its S-box was replaced in 2001 and the
diffusion matrix was corrected in 2003 because a flaw in it
lowered the estimated security below the potential of the
design; use whirlpool (the final 2003 version) instead
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Whirlpool (by jonelo)
whirlpool1, whirlpool-1, whirlpool-t
algorithm name:
Whirlpool-1
length:
512 bits
type:
cryptographic hash function
published:
2001
comment:
The Whirlpool Hashing Function by Paulo S.L.M. Barreto and
Vincent Rijmen, 2001. This is the first revision of the
specification of Whirlpool from 2001 with improved S-box design:
"We propose renaming the original algorithm Whirlpool-0 and
using the term Whirlpool for the final, modified version that
uses the improved S-box design."
Since March 2007 the Whirlpool authors name this whirlpool
revision "Whirlpool-T".
The default encoding is hexadecimal.
broken:
no, but superseded: no attack targeting Whirlpool-1 itself has
been published, but it still contains the flaw in the diffusion
matrix that was corrected only in the final 2003 version and
that lowered the estimated security below the potential of the
design; use whirlpool instead
since:
Jacksum 1.2.0
implementation:
gnu.crypto.hash.Whirlpool
whirlpool, whirlpool2, whirlpool-2
algorithm name:
Whirlpool
length:
512 bits
type:
cryptographic hash function
published:
2003
comment:
The Whirlpool Hashing Function by Paulo S.L.M. Barreto and
Vincent Rijmen. This is the second revision of the specification
of Whirlpool from 2003 with improved diffusion matrix:
"Recently [March 11, 2003], Shirai and Shibutani discovered a
flaw in the Whirlpool diffusion matrix that made its branch
number suboptimal. Although this flaw per se does not seem to
introduce an effective vulnerability, the present document
replaces that matrix [May 24, 2003]"
This whirlpool revision was adopted by the International
Organization for Standardization (ISO) in the
ISO/IEC 10118-3:2004 standard.
The default encoding is hexadecimal.
broken:
no, but 2009/2010: rebound attacks yield collisions for 4.5 of
10 rounds (2^120), semi-free-start collisions for 5.5 rounds
and a distinguisher for the full compression function (2^188);
the full Whirlpool has no collision or preimage attack
see also https://eprint.iacr.org/2010/198
compatibility:
- 7z: -
- 7zFM: -
- Angstrom: -
- BeOS: -
- BusyBox: -
- DragonFly BSD: -
- FreeBSD: -
- FreeDOS: -
- GNU/Hurd: -
- GNU/Linux: -
- Go API: -
- gpg: -
- HashGarten: Algorithm -> whirlpool2
- HP-UX: -
- IBM AIX: -
- Jacksum: jacksum -a whirlpool2
- Java API: -
- Kali Linux: -
- LibreSSL: openssl dgst -whirlpool
- macOS: -
- Minix: -
- MS-DOS: -
- NetBSD: -
- NextStep: -
- OpenIndiana: -
- OpenSSL: openssl dgst -whirlpool
- PHP: hash("whirlpool", $input);
- Plan 9: -
- PowerShell: -
- Python: -
- Solaris: -
- Windows: -
- Wolfram: -
since:
Jacksum 1.6.0
implementation:
gnu.crypto.hash.Whirlpool (by jonelo)
xoodyak
algorithm name:
Xoodyak
length:
256 bits
type:
cryptographic hash function
published:
05/2021
website:
https://keccak.team/xoodyak.html
comment:
Xoodyak is a versatile cryptographic scheme that can be used for
hashing, encryption, MAC computation and authenticated encryption.
Jacksum supports the hashing part of Xoodyak.
Xoodyak was one of the 10 finalists of the NIST Lightweight
Cryptography competition (2019-2023).
Xoodyak was created by Joan Daemen, Seth Hoffert,
Michaël Peeters, Gilles Van Assche, Ronny Van Keer, and
Silvia Mella.
broken:
no; no attack on the full Xoodyak is known that is faster than
generic attacks; Xoodyak was a finalist of the NIST Lightweight
Cryptography competition (2019-2023) but was not selected; as a
sponge construction it is immune to length-extension attacks
since:
Jacksum 3.6.0
implementation:
org.bouncycastle.crypto.digests.XoodyakDigest
xor8, xor-8
algorithm name:
Exclusive-OR
length:
8 bits
type:
checksum
comment:
value computed by xoring all values in the input data stream.
This algorithm doesn't care about the arrangement of bytes in a
file. The default encoding is decimal.
since:
Jacksum 1.3.0
implementation:
net.jacksum.algorithms.checksums.Xor8
xxhash32, xxh32
algorithm name:
xxHash32 (XXH32)
length:
32 bits
type:
non-cryptographic hash function
published:
2012
website:
https://xxhash.com/
comment:
The default output is equivalent to the Open Source program
called xxhsum: hex lowercase checksum, big endian,
without message length.
compatibility:
- xxhsum: xxhsum -H0
xxhsum -H32
since:
Jacksum 3.0.0
implementation:
org.apache.commons.codec.digest.XXHash32
The default output format of Jacksum:
If you specify neither a predefined format (option -C/--style) nor a
customized format (option -F), the following default format is used.
Actually it is a very flexible format which is based on the BSD
reversed mode format (it doesn't use a character to distinguish
binary and text mode), but it allows you to include optionally file
size, and time stamp, and to flag/enable filename escaping as
suggested by the GNU coreutils to ensure one single line per file on
standard output - even if the file name has problematic characters
such as newlines or carriage returns on Unix and GNU/Linux.
[escchar]checksum<sep>[filesize<sep>][timestamp<sep>]<filename>
escchar optional. The escape character can only be a backslash.
The existance of the backslash represents whether file
name escaping is required or not for the line. You can
enable GNU escaping by setting the option
--gnu-filename-escaping.
checksum is a checksum, CRC or a hash value or even a concatenation
of multiple different hash values if you select multiple
algorithms; by default the encoding/representation of the
hash value (or concatenated hash values) depends on the
option -a, but you can specify the encoding explicitly by
setting -E, -g, -G, -x, and -X.
<sep> is the separator string; it can be modified by -s,
otherwise it depends on the -a setting.
filesize optional. It is the size (in bytes or blocks) of a file,
the actual representation for the size depends on the -a
setting, often it is a normal decimal representation.
The filesize won't be written by any crytographic hash
function, but it can be forced by setting the option
called --filesize.
timestamp optional. It is the timestamp of a file; timestamps
can be requested and configured with option -t.
filename is the name of a file. Paths can be omitted by option
--no-path, made absolute by option --path-absolute, and
made relative to another path by setting the option called
--path-relative-to. Furthermore the path separator can be
specified by -P, and problematic characters in file names
can be escaped by setting --gnu-filename-escaping.
If there is no file name at all, for example if a sequence
is being hashed by option -q, neither the file name nor the
separator in front of it is written, so that the line does
not end with a separator.
Customized output format:
Output can not only occur in the default format, several well-known
predefined format sets are also available to keep input and output
compatibility with other hashing tools.
See also the option called --style.
A highly customizable user-defined format is supported as well.
See also the option called --format.
EXIT STATUS
If Jacksum exists, the exit code reflects the following:
0 - everything is OK
1 - there was at least one mismatch during the verification process, or
the search of an exact help (--exact -h <word>) was unsuccessful
>1 - in case of a parameter-, .jacksum- or I/O-error
EXAMPLES
Calculate hashes from standard input (stdin):
> echo -n "Hello World" | jacksum -V summary -
Calculates a SHA3-256 hash (default) from standard input stream (stdin).
Enabling the option `--verbose summary` or `-V summary` make sense in
some cases, because it will show how many bytes have been read actually.
Note: the echo command could behave on your platform/environment
completely different! A more platform independent way is to use the -q
option.
> printf "Hello World\r\n" | jacksum -
Returns the SHA3-256 (default) of the input "Hello World\r\n".
printf is a shell builtin in GNU/Linux shells such as bash and zsh.
A more platform independent way is to use the -q option.
> jacksum -a md5 -
Calculates the MD5 hash from input that is entered in the terminal.
Hit Ctrl+Z on GNU/Linux and macOS, and Ctrl+D on Windows to end the
input.
> cat fat.iso | jacksum -
prints the SHA3-256 (default) of the binary file called fat.iso on
GNU/Linux and macOS. Use type rather than cat on Microsoft Windows.
Calculate hashes from the command line:
> jacksum -q txt:"The quick brown fox jumps over the lazy dog"
calculates the sha3-256 (default) hash from the given string.
> jacksum -a crc32 -q 'txt:Hello World!'
calculates a 32-bit CRC of the text "Hello World!". In GNU/Linux
shells such as bash you have to enclose characters in single quotes
rather than double quotes in order to preserve the literal value of each
character within the quotes. On Windows you can use double quotes.
> jacksum -q txtf:"Hallo Welt\r\n"
Returns the SHA3-256 (default) of the input "Hallo Welt\r\n",
interpreted as UTF-8 String and using of escape sequences.
> jacksum -a crc32 -q 48656C6C6F20576F726C6421
calculates a 32-bit CRC of the hex sequence
48656C6C6F20576F726C6421 which actually represents the string
"Hello World!" (without the quotes)
> jacksum -a crc64 -q txt:
calculates a 64-bit CRC of an empty string (the result is the same
if you calculate the 64-bit CRC of a file with a file size of 0 bytes)
> jacksum -V summary -q txtf:abc\n -F "#ALGONAME(#SEQUENCE) = #HASH" -x
calculates the sha3-256 (default) of 4 input bytes. Since you have
specified #SEQUENCE and -V summary, you can see not only the input as
hex, but also the number of bytes that have been read.
Calculate hashes from files on the file system:
> jacksum -a crc32 -x *.txt
calculates a 32 bit CRC of all text files within the current folder.
The checksum will be printed in a hexadecimal format (-x).
> jacksum -a crc32 -t default .
not only CRCs will be printed, but also timestamps (-t) of all
files within the current folder (.)
> jacksum -a crc:16,1021,FFFF,false,false,0 .
a CRC with customized parameters has been used: 16 bits, Polynomial 1021
(hex, without the leading bit), initvalue FFFF (hex), mirror neither
the input nor the output, no xor.
> jacksum -a haval_256_5 .
calculates a 256 bit hash with 5 rounds by using the haval
algorithm (haval_256_5) of all files within the current folder (.)
> jacksum -a cksum /mnt/share
calculates a 32 bit CRC with the standard Unix-algorithm cksum
of all files /mnt/share and it's sub folders
> jacksum -A -a md5 -V summary bigfile.iso
Among others it also returns the elapsed time (-V summary) which was
necessary to calculate the MD5 Hash of the file called bigfile.iso
by using the alternative MD5 implementation (-A).
Calculate hashes from file lists:
> jacksum --file-list filelist.txt
for each filename in filelist.txt, read the file and calculate the
hashes.
> jacksum --file-list filelist.txt *.mp3 *.info myfolder
for each filename in filelist.txt, for all *.mp3 and *.info files, and
for any files under myfolder, read the files and calculate the hashes.
> chcp 65001 & echo "a filename that contains unicode chars" |
jacksum --utf8 --file-list - --file-list-format ssv
on the Windows' cmd, change the code page to UTF-8, and pass a filename
that contains unicode characters through a pipe to Jacksum
(--file-list -). The file list format has been specified as ssv which
stands for space separated values. --utf8 has been set in order to
read the filenames from the pipe in UTF-8 mode.
Create hash lists for later verification:
> jacksum -o hashes.list /data
calculates the Message-Digest SHA3-256 (default) of all files in /data
and it's subfolders, and stores the output to hashes.list, path
information is stored absolutely since your path started with /.
> jacksum -o hashes.list data
calculates the Message-Digest SHA3-256 (default) of all files in data
and it's sub folders, and stores output to hashes.list, path
information is stored relatively, because your path didn't start with /.
> jacksum -a blake3+ -o hashes.list data
calculates the Message-Digest Blake3 of all files in data
and it's sub folders, and stores output to hashes.list. Since the + has
been used, filesizes are also stored to hashes.list.
> jacksum -a blake3+ -E base64 -t iso8601 -o hashes.list data
calculates the Message-Digest Blake3 of all files in data
and it's sub folders, and stores output to hashes.list. Hashes are
stored in base64 format. Since the + has been used, filesizes are also
stored to hashes.list, and since the -t iso8601 has been used,
timestamps are also stored to hashes.list.
> jacksum -a sm3 -E base64 -o hashes.txt -C linux *.txt
calculates the SM3 hashes in base64 encoding for all txt-files
using the linux compatibility output format.
Check/verify hashes:
> jacksum -a sha256 -E hex -e
5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5
ubuntu-20.04.3-desktop-amd64.iso
checks the Ubuntu iso in the current working directory with an expected
SHA256, hexadecimal message digest.
> echo "5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 *ubuntu-20.04.3-desktop-amd64.iso"
| jacksum -a sha256 -C linux --check-file -
checks the SHA256 message digest for the Ubuntu iso on GNU/Linux
> echo 5fdebc435ded46ae99136ca875afc6f05bde217be7dd018e1841924f71db46b5 *ubuntu-20.04.3-desktop-amd64.iso|
jacksum -a sha256 -C linux --check-file -
checks the SHA256 message digest for the ubuntu iso on Microsoft Windows.
Note that you have to remove the quotes and the blanks, otherwise
the echo command will pass those characters to the pipe.
> jacksum -a blake3+ -E base64 -t iso8601 -c hashes.list
verifies all checksums stored in a file called hashes.list. You have to
specify -a blake3+ and -E hex, because Blake3 was the algorithm, and hex
was the encoding that was used when the hashes.list was generated.
> jacksum -a blake3+ -E base64 -t iso8601 -c hashes.list data
same as above, but the data folder will be searched for new files as well.
> jacksum -C bsd -a sha3-256 -c bsd-hashes.list .
checks the integrity of the sha3-256 hashes for all filenames stored in
the hashes.list, and it also finds all new files that are being stored
anywhere in the directory tree below the current working directory.
> jacksum -c my.hashes -a sha3-256 -E hex --list --list-filter bad
--verbose nosummary
lists filenames for bad files (failed or missing) only.
Customize the output:
> jacksum -C bsd -a sha3-256 .
calculates the SHA3-256 hashes for all files in the current
directory recursively in BSD-style format.
> jacksum -a md5+sha1 -F "MD5-SHA1(#FILENAME)= #HASH{hex}" file
produces the same output as `openssl dgst -md5-sha1 file`
> jacksum -a ed2k -F
"ed2k://|file|#FILENAME{name}|#FILESIZE|#HASH{hex}|/" .
produces ed2k-links
> jacksum -a tth+ed2k+sha1+md5 -F
"magnet:?xl=#FILESIZE&dn=#FILENAME{name}
&xt=urn:tree:tiger:#HASH{tth,base32}
&xt=urn:ed2k:#HASH{ed2k,hex}
&xt=urn:bitprint:#HASH{sha1,base32}.#HASH{tth,base32}
&xt=urn:sha1:#HASH{sha1,base32}
&xt=urn:md5:#HASH{md5,hex}" -
produces magnet-links
> jacksum -a sumsysv -E dec -t unixtime -F
"1 i #FILENAME{name} #FILESIZE #CHECKSUM #TIMESTAMP"
install/*
prints appropriate entries that are compatible with the
syntax of a Solaris 10+ pkgmap file - that is useful if you
want to patch a Solaris patch for example.
Find files having the same hash (find all duplicates of the file):
> jacksum -a md5 -E hex -F #FILENAME -e 9666f5e2632d05b806e782d7d50855e8 .
finds all files below the current working directory, that produces
the given hex-encoded MD5-hash. Only the filenames of those files
will be printed.
Find the algorithm that produces a particular hash:
> jacksum -a unknown:16 -q hex:050000 -E hex -e d893
Finds all algorithms with a digest length of 16 bits that can produce
the hex output d893 for the hex input 050000. The example above returns
20 potential algorithms, each of those returns the same checksum. Test
with more input/output sequences in order to find the right algorithm.
Customize the output format:
> jacksum -a sha256 -P / -F "<a href=\"#FILENAME\">#HASH</a><br>" mp4s
prints the SHA256 hashes for all files in the mp4s folder as hyperlinks
with the slash as path separator, even on Windows where the path
separator would be the back slash.
> jacksum -a sumsysv -E dec -t unixtime
-F "1 i #FILENAME{name} #FILESIZE #CHECKSUM #TIMESTAMP" install/*
prints appropriate entries that are compatible with the syntax of
Solaris 10's pkgmap file (useful if you want to patch a Solaris patch)
> jacksum -a sha1 -s "\t" -t "EEE, MMM d, yyyy 'at' h:mm a" .
calculates a 160 bit SHA-1 Message-Digest of all files within the
current folder. The separator string (-s) is set to the tabulator
char ("\t"). Timestamps of files will be printed out in a customized
format (-t).
> jacksum -a md5 -f -F "#FINGERPRINT #FILESIZE #FILENAME" *
calculates the Message-Digest MD5 of all files in the current
directory. The output format is customized, it prints also
the filesize.
> jacksum -a crc32 -X -f -F "#FILENAME #CHECKSUM" -o list.sfv *
prints CRC-32 values in the Simple File Verificator (SFV) format
> jacksum --style sfv -f -o list.sfv *
prints CRC-32 values in the Simple File Verificator (SFV) format
> jacksum -a ed2k -f -F
"ed2k://|file|#FILENAME|#FILESIZE|#FINGERPRINT|" *
calculates the edonkey hash of all files in the current directory
with a customized output format
> jacksum -a ed2k -f -P / -F "<a href=#QUOTEed2k://|file
|#FILENAME|#FILESIZE|#FINGERPRINT|#QUOTE>#FILENAME</a>" .
calculates the edonkey hash of all files in the current directory
and it's sub folders with a customized output format (HTML)
> jacksum -a tree:tiger -F "urn:#ALGONAME:#FINGERPRINT" -q hex:
calculates the root hash of the Tiger Tree Hash (a widely used form of
the Merkle tree). The underlying Tiger algorithm is used with an empty
input.
Working with multiple algorithms:
> jacksum -a sha1+crc32 .
calculates the sha1 hash and the crc32 as a chained checksum
> jacksum -a sha1+crc32 -F "sha1=#CHECKSUM{0} crc32=#CHECKSUM{1} #FILENAME" .
calculates the sha1 hash and the crc32, printed separately
> jacksum -a all -F "#ALGONAME{i} (#FILENAME) = #CHECKSUM{i}" .
calculates all supported algorithms on all files in a customized format
> jacksum -a all -q txt: -F "#ALGONAME{i}"
returns all supported algorithm IDs only, a more elegant way is to type
`jacksum -a all --list` however
> jacksum -a all:224 -q txt: -F "#ALGONAME{i}"
returns all supported algorithm IDs that have a bit-length of 224 only
a more elegant way is to type `jacksum -a all:224 --list` however
> jacksum -a crc32+md5+sha1 -F
"#SEPARATOR#ALGONAME{i}(#FILENAME):hex=#DIGEST{i,hex}
#SEPARATOR#ALGONAME{i}(#FILENAME):HEX=#DIGEST{i,hex-uppercase}
#SEPARATOR#ALGONAME{i}(#FILENAME):base64=#DIGEST{i,base64}"
-s "\n" -r .
for all files, including all subdirectories, calculate the crc32, md5
and sha1 hash and for each of those algorithms print the digest encoded
in hex, uppercase hex and base64
> jacksum -a sha3-512+blake2b -q txtf:"Hello World\x0a" -s \n -F
"#ALGONAME{0} (#SEQUENCE)[hex] = #DIGEST{0,hex}#SEPARATOR
#ALGONAME{1} (#SEQUENCE)[bb] = #DIGEST{1,bb}"
Returns the SHA3-512 digest hexadecimal and the blake2b Digest in the
BubbleBabble format for the input that has been specified with -q.
> cat template.txt
INPUT:
hex: #SEQUENCE{hex}
base32: #SEQUENCE{base32}
base64: #SEQUENCE{base64}
OUTPUT of #ALGONAME{i}:
hex: #CHECKSUM{i,base16}
base32: #CHECKSUM{i,base32}
base64: #CHECKSUM{i,base64}
> jacksum -a blake2b+sha3-512 -q txtf:123456789\x0a -E hex -g 1 -F \
"$(cat template.txt)"
with the help of a template that is stored in a plain text file, not
only the input "123456789\x0a", but also the hashes are being encoded
as hex, base32 and base64 for both algorithms blake2s and sha3-512.
> jacksum -s \n -a sha1+sha1+sha3-256 -F
"#ALGONAME{0}/hex: #CHECKSUM{0,hex} #FILENAME{name}#SEPARATOR
#ALGONAME{1}/base32: #CHECKSUM{1,base32} #FILENAME{name}#SEPARATOR
#ALGONAME{2}/base64: #CHECKSUM{2,base64} #FILENAME{name}#SEPARATOR"
*.txt
You want different encodings, such as hex and base32 for SHA-1, and
base64 for SHA3-256?
Each text file will be read only once and also sha1's engine will run
only once for each file.
Gather Information
Get information about one algorithm:
> jacksum -h blake2b
prints the BLAKE2b section from the help file, including a compatibility
list.
> jacksum -a blake2b --info
prints implementation details about the BLAKE2b algorithm, such as hash
length in bits and bytes, blocksize if applicable, relative speed rank,
and whether an alternative implementation is available.
> jacksum -a crc64_xz --info
prints implementation details about the CRC64_xz. Since it is a CRC,
also all CRC parameters are printed, including the polynomial in
several representations (mathematical, normal, reversed, and Koopman),
and the reciprocal poly which has a similar error detection strength.
Get information about multiple algorithms:
> jacksum -h algorithms
prints the entire ALGORITHMS section of the help file.
> jacksum -a all --list
prints a list of all supported algorithm IDs that can be passed to -a.
> jacksum -a all --list --verbose summary
prints a list of all supported algorithm IDs and the count of the
algorithms.
> jacksum -a all:skein --list
prints a list of all supported algorithm IDs that has skein in their
names.
> jacksum -a all:128 --list
prints a list of all supported algorithm IDs that produce a digest
length of 128 bits.
> jacksum -a all:8 --list --info
prints a list of all supported algorithms IDs that produce a digest
length of 8 bits, and for each algorithm ID additional information is
printed.
Get information on style definitions:
> jacksum --style bsd --info
all properties of the compatibility definition for bsd are printed out.
Get information about the program:
> jacksum -v
> jacksum --version
returns the version of Jacksum
> jacksum -h
> jacksum --help
prints the entire manpage
> jacksum --info
returns the version of Jacksum, primary IDs of all supported algorithms
and their descriptions, number of supported algorithms, supported
character sets, number of supported character sets, system properties,
available processors for the application and many more.
Useful for support requests.
Get legal stuff:
> jacksum --license
prints the entire license text.
> jacksum --copyright
prints out the copyrights and license information for all portions
of the software that Jacksum licensed.
Working with the help
Print the entire help
> jacksum -h
prints the entire help
> jacksum -h | more
prints the entire help, pagewise ("less" is also fine on macOS and
Linux flavours, but the "more" command works on Windows as well)
Print entire help sections
> jacksum -h synopsis
> jacksum -h syn
prints the entire SYNOPSIS section
> jacksum -h exit
> jacksum -h exi
prints the entire EXIT STATUS section
> jacksum -h options
> jacksum -h opt
prints the entire OPTIONS section
> jacksum -h "operating modes"
prints the entire OPERATING MODES section
> jacksum -h "option "
prints both sections OPTION TYPES and OPTION SUPPORT, because they
start with "option "
> jacksum -h examples
> jacksum -h exa
prints the entire EXAMPLES section
> jacksum -h ex
prints both sections EXIT STATUS and EXAMPLES,
because both starts with "ex"
Print information about algorithms
> jacksum -h whirlpool
prints information about all algorithms that starting with whirlpool
Get information about options
> jacksum -h -h
prints the help on the -h option
> jacksum -h --path
prints information about all available options starting with --path
> jacksum -h -
prints all options (since each option starts with a minus sign)
> jacksum --exact -h -
prints information about the option "-" only
> jacksum --exact -h --
prints information about the option "--" only
> jacksum --exact -h --path
prints nothing, because there is no option called exactly "--path"
REPORTING BUGS
Report bugs to <https://github.com/jonelo/jacksum/issues>
COPYRIGHT
Copyright (c) 2001-2026 Dipl.-Inf. (FH) Johann N. Loefflmann
Type `jacksum --copyright` to see the entire copyright section.
LICENSE
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or any
later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program. If not, see <https://www.gnu.org/licenses/>.
SEE ALSO
Homepage: <https://jacksum.net/>
Source code repository: <https://github.com/jonelo/jacksum>
Jacksum Wiki: <https://github.com/jonelo/jacksum/wiki>
