Re: [exim-dev] crypt, crypt16, and bigcrypt - worth changing?

2006-09-12 Thread Tamas TEVESZ
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.

is this of any help?

-- 
[-]

mkdir /nonexistent

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details 
at http://www.exim.org/ ##


Re: [exim-dev] crypt, crypt16, and bigcrypt - worth changing?

2006-09-12 Thread Kjetil Torgrim Homme
On Tue, 2006-09-12 at 14:37 +0100, Philip Hazel wrote:
 However, the first question is: should any change be made? I don't
 recall anybody reporting problems, and I suspect that the world is
 moving on to other encryption methods such as {sha1} these days.

I think it's more common to stick to {crypt}, but crypt(3c) is more
clever these days and is extensible in itself.  from /etc/shadow on a
typical Linux system:

   $1$Bn7P0ASN$baWgRvs/4RPe1q8Ba12Ky0

as you can see, it's longer than the traditional crypt strings, and it's
separated into fields with dollar signs.  $1 means use the algorithm
salted MD5, the salt comes next, and finally the crypted password.
*BSD and Solaris supports this scheme, too.  (I think it actually
originated on FreeBSD, but don't shoot me if that's the wrong
attribution.)

I don't think you should worry too much about bigcrypt and other weird
extensions.  just make sure you pass along the _whole_ password to
crypt(3c), not just the first 8 characters.  crypt(3c) will chop off
excess characters itself if need be.

-- 
Kjetil T.



-- 
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details 
at http://www.exim.org/ ##