Autore: Tamas TEVESZ Data: To: exim-dev Oggetto: Re: [exim-dev] crypt, crypt16, and bigcrypt - worth changing?
On Tue, 12 Sep 2006, Philip Hazel wrote:
> (1) Ultrix and Tru64 have a function called "crypt16", which encrypts up
> to 16 characters of password in a particular way.
>
> (2) HP-UX, Digital Unix, and OSF/1 have a function called "bigcrypt"
digital unix 4.0b does not have it, but has crypt16, quoting manual:
"The crypt16 subroutine is identical to the crypt function except that
it will accept a password up to sixteen characters in length."
it does not go into details as to how exactly is this achieved.
hp-ux (10.20 and/or b.11.00) does have it, with the manual saying
"bigcrypt() acts like crypt(3C), but handles much larger strings.
bigcrypt takes the segments of cleartext and encrypts them
individually, at first using the salt passed in, and then using the
first two characters of the previous encrypted segment as the salt for
the next segment."
this is afair the same as the crypt16 implementation i dug up for
exim, with the difference of crypt16 only doing up to 16 characters,
and bigcrypt up to 40-something (iirc?).
> which encrypts some number of characters (may be up to 40 or more) in a
> subtly different way. [Despite this, the OS-specific Makefile for OSF/1
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. 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).
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.
