Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Jan 2013 13:08:57 +0100
From: Frank Dittrich <>
Subject: Supporting different hash algorithms with a single format?

Hi all,

I don't know how many cases of a single format supporting completely
different hash algorithms exist.

One example is the odf format.

Until 1.7.9-jumbo-6, only "ODF SHA-1 Blowfish" has been supported.
Commits 50d403f4b035716906f16fbe961ef73d27a107b9 and
c1f2c82031c84b26d9574b4c3e93f0624bec6da0 added support for "SHA-256 AES"
and changed the format description to "ODF SHA-1 Blowfish / SHA-256 AES".

For a performance comparison, I compiled two john versions, commenting
out all but one ODF test.
On my system, there is a significant performance difference between
"ODF SHA-1 Blowfish" and "ODF SHA-256 AES".
(That's why, IMHO, it wouldn't be a good idea to map "ODF SHA-1 Blowfish
/ SHA-256 AES" to "ODF SHA-1 Blowfish" in the benchmark-unify script.

I think mixing support of different hash algorithms in the same file is
OK, if there are enough similarities.
But it certainly would have been better to make this two separate
formats, e.g.:
-odf-sha1-bf "ODF SHA-1 Blowfish"
-odf-sha256-aes "ODF SHA-256 AES"

If we split the odf format into two separate formats before the next
jumbo version gets released, it would be possible to compare the
performance of "ODF SHA-1 Blowfish" with the 1.7.9-jumbo-6 relbench script.

The OpenCL version also claims to support "ODF SHA-1 Blowfish / SHA-256
AES", but AFAIK, it currently just supports ODF SHA-1 Blowfish.
I think, the format description should be corrected.
If "ODF SHA-256 AES" will be added, this should be a separate format.

Other examples of mixed hash algorithms include:
BTW: sh and ssh_ng seem to support the same hash algorithm(s) and the
same maximum password length.
But since the description differs, the relbench script will handle them
separately, instead of just picking the fastest of these implementations
for comparison (which is done for nt and nt2).
Should this be changed?
BTW2: The ssh format description (or, more precisely, the benchmark
comment) is not even correct anymore:
SSH RSA/DSA (one 2048-bit RSA and one 1024-bit DSA key)
Since commit 87f0ed13, 3 more tests have been added to ssh (but not to

What do you think? Should separate hash algorithms be supported by
different formats, instead of mixing different hash algorithms into the
same format?
(I know that even for a single algorithm the performance depends on the
test vectors, e.g., with different iteration counts.)

Are you aware of other formats mixing different hash algorithms?


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ