This is the freeware version of sha-1 provided by Paul E. Jones (see
license.txt), with minor modifications to fit into iRODS.  Where I've
modified a .h or .c file, I've kept the original in a _.h.orig or
_.c.orig file.  The sha.c and shatest.c are test programs in the
original that can be linked in with it.  sha1.c contains the sha
library functions used in iRODS.



git-svn-id: svn://irodssvn.ucsd.edu/trunk@5412 ea137bd6-aa86-47b6-b90d-b101d9f19a90
Optionally use SHA-1 instead of MD5 in iRODS password authentication
and obfuscation.

This is for sites that have a security policy requiring software to
not use MD5 due to weaknesses discovered in it.  However, the
weaknesses found do not actually affect iRODS authentication as the
primary property needed for iRODS is simply the one-way aspect of the
hash (i.e. one can't derive the password from its hash (so that
monitoring the network traffic doesn't reveal the password)), and MD5
is quite strong in this regard.  The MD5 flaw is that it is not as
collision resistant as previously thought; it is possible for one to
design a file that has different content but the same MD5 hash as
another file.

In the iRODS authentication protocol a challenge value is hashed with
the password, which is returned to the server as proof that the
password is known.  As long as this hash is one-way and collisions are
rare, this is fine.  Even with the MD5 limitations, collisions are
extremely rare.  And since the challenge is unique (64 pseudo-random
bytes), one cannot attack the authentication sub-system with prepared
responses.

SHA-1 has since been found to be vulnerable in this manner as well,
altho it, like MD5, is still completely sufficient for iRODS
authentication.

----

Currently, to enable SHA-1 as the default authentication/obfuscation
hash edit the lib/core/src/obf.c and change the line:
static int defaultHashType=HASH_TYPE_MD5;
to:
static int defaultHashType=HASH_TYPE_SHA1;

I may add a micro-service/rule so that this can be set by updating a
rule but, for now, you can edit this setting.  There's also a
function, obfSetDefaultHashType, that can used to set this (this is
used in iadmin for some tests).

To maintain good backward compatability, and well as between the
various clients and servers and for inter-zone operations, the iRODS
system and protocol will determine which hash is available and fall
back to MD5 when needed.  For example, for a site that configures
SHA-1 as preferred, the servers will indicate to clients that SHA-1 is
preferred and if the client is SHA-1 enabled, it will recognize this
and return to the server a SHA-1 hash.  The server is able to tell if
the client actually used SHA-1 in the returned values.  This
complicates the implementation (actually represents most of the
development effort), but is critical for this SHA-1 capability to be
available and reliable.

For iRODS obfuscation capabilities, many various cases also now use
SHA-1 instead for MD5 when SHA-1 is preferred.  As for authetication,
the system is able to determine if SHA-1 was used and switch back to
MD5 if not.  This is only obfucation though, and with the iRODS source
code one can de-scramble obfuscated values.  It does avoid completely
plain text tho, and avoids inadvertant disclosure of values.  But it
is not critical that SHA1 is used in all cases, as both are fine.

The obfEncodeByKey function will now add the string 'sha1' at the
beginning of the output string and the obfDecodeByKey function will
look for this at the beginning of the input string and if found, will
skip past it use sha1 to decode.

A open-source version of sha-1 has been added to the iRODS source tree
under lib/sha1 and is now built with iRODS in a manner similar to how
MD5 is.  See lib/sha1/README.txt for more.

There is a new iadmin sub-commands to test SHA-1: 'sethash', 'md5',
and 'sha1'.  See the diffs and code for how these work. I didn't add
them to the help text since they are just for test.

I also plan to modify the DICE continuous build/test system to
configure an instance with SHA-1 enabled occasional (probably daily).
Since there are no new ICAT SQL forms with this, no new SQL-specific
tests were needed.



git-svn-id: svn://irodssvn.ucsd.edu/trunk@5413 ea137bd6-aa86-47b6-b90d-b101d9f19a90