[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP238981FE36AC6C7A8296516FDB10@phx.gbl>
Date: Thu, 9 Jan 2014 00:41:31 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Should several more hash formats be changed from using hex to base64
before releasing unstable and bleeding?
AFAIK, the latest jumbo that has been officially released has been
1.7.9-jumbo-7.
This version did not have several formats that use extremely long hashes
which could be made shorter by converting hex encoding to base64 encoding.
(If we plan such a change after the current unstable-jumbo or
bleeding-jumbo have been officially released, we might need to support
both encodings for backwards compatibility.
That's why I think, the earlier we decide to change formats, the better.
Of course, when we change the canonical representation of a particular
hash format, all implementations need to be adjusted (e.g., several
different CPU implementations + OpenCL + CUDA).
I just extracted the test hashes, and ran "./john --format=...
--single=none" and ./john --format=... --wordlist=..." against them, to
see what ends up in the pot files.
Bleeding-jumbo formats with test hashes that are least 400 characters
long, but shorter than 1000 characters:
7z
Blockchain
IKE
PBKDF2-HMAC-SHA512
PDF
PKZIP
krb5
kwallet
openssl-enc
Bleeding-jumbo formats with test hashes that are at least 1000
characters long:
KeePass
LUKS (uses base64 for some parts, hex encoding for other parts)
ODF
PFX
PuTTY
SSH
SSH-ng
STRIP
agilekeychain
cloudkeychain
dmg
fde
gpg
keystore
sxc
tc_ripemd160
tc_sha512
tc_whirlpool
The only format with extra long hashes using base64 is wpapsk.
OK, these are longer than 2000 characters even with base64 encoding. Due
to a huge number of '.' characters, we could probably make the hashes
smaller by adding compression;)
John version 1.7.9-jumbo-7 segfaults on the corresponding bleeding-jumbo
test hashes for these formats:
pdf
sip
These 1.7.9-jumbo-7 formats wrote hashes >= 1000 characters long into
the pot file:
keepass
odf
ssh
These 1.7.9-jumbo-7 formats wrote hashes >= 400 characters long, but
shorter than 1000 characters, into the pot file:
krb5
pkzip
In addition to 1.7.9-jumbo-7, these unstable-jumbo formats wrote hashes
>= 1000 characters long into the pot file (so when we change the
bleeding-jumbo format, we need to change unstable-jumbo as well):
agilekeychain
dmg
gpg
pfx
putty
ssh-ng
strip
sxc
tc_ripemd160
tc_sha512
tc_whirlpool
In addition to 1.7.9-jumbo-7, these unstable-jumbo formats wrote hashes
>= 1000 characters long into the pot file (so when we change the
bleeding-jumbo format, we need to change unstable-jumbo as well):
ike
kwallet
pbkdf2-hmac-sha512
I know that changing the canonical format representation isn't fun,
especially not if you have a format2john and multiple implementations
that need to be changed as well.
However, if we change certain formats before they appear in an
"official" jumbo release, the change will be less painful than a change
after the format has been released.
(If we decide to change certain formats, I suggest changing the CPU
implementations first, hunting down any new bugs in valid(), and then
adjusting the GPU formats.)
Frank
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
