There was some discussion of this on the list about a year ago, but I
don't think anything came of it. Recently I was sent more information.
I'm looking for people's views as to what, if anything, should be done.
The issue is the handling of password encryption using the
${crypteq{...}{...}} expansion condition.
The second argument is an encrypted password. Originally, it was assumed
encrypted with crypt(). Later, the ability to specify the encryption by
a leading {name} was added. Currently we have {crypt}, {crypt16}, {md5},
and {sha1}. The issue is with {crypt16}.
The default for when no {name} is given is defined by DEFAULT_CRYPT at
compile time. This defaults to "crypt"; it's suggested in EDITME that
you can change it to "crypt16", but in fact you can define it as any
function you like that takes two char* arguments and has the
specification of crypt().
When {crypt} is given, crypt() is called. When {crypt16} is given,
crypt16() is called. If HAVE_CRYPT16 is defined at compile time, the
operating system is assumed to have a function called crypt16().
Otherwise, an inbuilt Exim function is used.
The issue is that it appears that "crypt16" is ambiguous, and the
inbuild Exim function may be different to OS versions of crypt16().
I have been told that:
(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"
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
in Exim is the only one that has HAVE_CRYPT16 as a default. I don't have
access to an OSF/1 system to see if it has both crypt16() and bigcrypt()
and whether they are the same or different.]
(3) Exim's inbuilt crypt16() function is actually an implementation of
"bigcrypt", limited to 16 characters. It is compatible with "bigcrypt"
if the password is no longer than 16 characters.
To some extent I am confused, because I thought that OSF/1, Digital
Unix, and Tru64 were basically the same thing under different names. But
it is certainly somewhat of a mess.
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.
It was suggested that {crypt16} be deprecated in Exim, and replaced by
new names that more correctly indicate what encryption function is being
used. I am wondering if it really is worth the effort of doing this. An
alternative is just to update the documentation to make (1), (2), and
(3) above very clear.
If new names are to be used, we need names for
(1) Call the OS function crypt16().
(2) Call the OS function bigcrypt().
(3) Call Exim's built-in function, which is a sort of bigcrypt(), but
may give different results to an OS function for passwords longer than
16 characters.
Views?
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
don't think anything came of it. Recently I was sent more information.
I'm looking for people's views as to what, if anything, should be done.
The issue is the handling of password encryption using the
${crypteq{...}{...}} expansion condition.
The second argument is an encrypted password. Originally, it was assumed
encrypted with crypt(). Later, the ability to specify the encryption by
a leading {name} was added. Currently we have {crypt}, {crypt16}, {md5},
and {sha1}. The issue is with {crypt16}.
The default for when no {name} is given is defined by DEFAULT_CRYPT at
compile time. This defaults to "crypt"; it's suggested in EDITME that
you can change it to "crypt16", but in fact you can define it as any
function you like that takes two char* arguments and has the
specification of crypt().
When {crypt} is given, crypt() is called. When {crypt16} is given,
crypt16() is called. If HAVE_CRYPT16 is defined at compile time, the
operating system is assumed to have a function called crypt16().
Otherwise, an inbuilt Exim function is used.
The issue is that it appears that "crypt16" is ambiguous, and the
inbuild Exim function may be different to OS versions of crypt16().
I have been told that:
(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"
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
in Exim is the only one that has HAVE_CRYPT16 as a default. I don't have
access to an OSF/1 system to see if it has both crypt16() and bigcrypt()
and whether they are the same or different.]
(3) Exim's inbuilt crypt16() function is actually an implementation of
"bigcrypt", limited to 16 characters. It is compatible with "bigcrypt"
if the password is no longer than 16 characters.
To some extent I am confused, because I thought that OSF/1, Digital
Unix, and Tru64 were basically the same thing under different names. But
it is certainly somewhat of a mess.
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.
It was suggested that {crypt16} be deprecated in Exim, and replaced by
new names that more correctly indicate what encryption function is being
used. I am wondering if it really is worth the effort of doing this. An
alternative is just to update the documentation to make (1), (2), and
(3) above very clear.
If new names are to be used, we need names for
(1) Call the OS function crypt16().
(2) Call the OS function bigcrypt().
(3) Call Exim's built-in function, which is a sort of bigcrypt(), but
may give different results to an OS function for passwords longer than
16 characters.
Views?
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##