The algorithm used is essentially PBKDF1 from RFC 2898 but using
hmac_sha1 rather than SHA1 directly (suggested by smb@research.att.com).
* The format of the encrypted password is:
* $<tag>$<iterations>$<salt>$<digest>
*
* where:
* <tag> is "sha1"
* <iterations> is an unsigned int identifying how many rounds
* have been applied to <digest>. The number
* should vary slightly for each password to make
* it harder to generate a dictionary of
* pre-computed hashes. See crypt_sha1_iterations.
* <salt> up to 64 bytes of random data, 8 bytes is
* currently considered more than enough.
* <digest> the hashed password.
hmac.c implementes HMAC as defined in RFC 2104 and includes a unit
test for both hmac_sha1 and hmac_sha1 using a selection of the Known
Answer Tests from RFC 2202.
It is worth noting that to be FIPS compliant the hmac key (password)
should be 10-20 chars.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
adding support for Heimdal/KTH Kerberos where easy to do so. Eliminate
bsd.crypto.mk.
There is still a bunch more work to do, but crypto is now more-or-less
fully merged into the base NetBSD distribution.
password map was split and master.passwd.byname was introduced.
XXX This is a temporary fix until luke finds some time to add
the necessary support glue to libc for TRT.
YP server. This is required if the passwd database is to stay in sync
if this program is run on the YP server. Note, local passwd database
operations can still be performed by passing the -l flag.
Also, some minor cleanup and RCS id police.
sjg