On Tue, 12 Sep 2006, Tamas TEVESZ wrote:
> from what i can gather, it's exactly the same method, with crypt16()
> being limited to 16 characters of input, and bigcrypt() to something a
> bit bigger.
I have been sent this comment:
There is an algorithm named "crypt16" in Ultrix and Tru64. It crypts
the first 8 characters of the password using a 20-round version of crypt
(standard crypt does 25 rounds). It then crypts the next 8 characters,
or an empty block if the password is less than 9 characters, using a
20-round version of crypt and the same salt as was used for the first
block. Charaters after the first 16 are ignored. It always generates
a 16-byte hash, which is expressed together with the salt as a string
of 24 base 64 digits. Here are some links to peruse:
http://cvs.pld.org.pl/pam/pamcrypt/crypt16.c?rev=1.2
http://seclists.org/bugtraq/1999/Mar/0076.html
There's a different algorithm named "bigcrypt" in HP-UX, Digital Unix,
and OSF/1. This is the same as the standard crypt if given a password
of 8 characters or less. If given more, it first does the same as crypt
using the first 8 characters, then crypts the next 8 (the 9th to 16th)
using as salt the first two base 64 digits from the first hash block.
If the password is more than 16 characters then it crypts the 17th to 24th
characters using as salt the first two base 64 digits from the second hash
block. And so on: I've seen references to it cutting off the password at
40 characters (5 blocks), 80 (10 blocks), or 128 (16 blocks). Some links:
http://cvs.pld.org.pl/pam/pamcrypt/bigcrypt.c?rev=1.2
http://seclists.org/bugtraq/1999/Mar/0109.html
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R2D-
http:TET1_html/sec.c222.html#no_id_208
This suggests that there *is* a difference between the crypt16() and
bigcrypt() algorithms. That's what made me ask my question.
> ideally the exim-builtin crypt16 could be extended to
> emulate bigcrypt. about a year ago someone asked about this, then i
> got a bunch of test data from that chap (he was on hp-ux, i reckon),
> which i can dig up if needed. i also have some test data which was
> compiled on a tru64 or a digital unix (these were used to check the
> current exim implementation).
If current operating systems contain suitable functions, I don't see the
need for having one built into Exim any more.
> technically, i think, this whole shebang can be pretty well automated
> (from exim's point of view), with a bigcrypt implementation that
> follows the way quoted above from the hpux manaual (that is, no need
> to have {crypt} {crypt16} {bigcrypt} stuff, but {builtincrypt},
> depending on the length of the input, could decide how many "passes"
> to apply.
Possible, I suppose. As I said, nobody has to my knowledge had problems
recently, so I do wonder how much effort it is worth expending on this.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
