This algorithm is dangerously weak, and should not be used if at all possible.
This class implements the Crypt16 password hash, commonly found on Ultrix and Tru64. It’s a minor modification of des_crypt, which allows passwords of up to 16 characters.
password hash usage – for examples of how to use this class via the common hash interface.
This class implements the crypt16 password hash, and follows the Password Hash Interface.
It supports a fixed-length salt.
An example hash (of the string passphrase) is aaX/UmCcBrceQ0kQGGWKTbuE. A crypt16 hash string has the format saltchecksum_1checksum_2, where:
This hash is frequently confused with the bigcrypt hash algorithm, as it has the same size and uses the same character set as a bigcrypt hash of a password with 9 to 16 characters; though the actual algorithms are different.
The crypt16 algorithm uses a weakened version of the des-crypt algorithm:
Given a password string and a salt string.
The 2 character salt string is decoded to a 12-bit integer salt value; The salt string uses little-endian hash64 encoding.
If the password is larger than 16 bytes, the end is truncated to 16 bytes. If the password is smaller than 16 bytes, the end is NULL padded to 16 bytes.
The lower 7 bits of the first 8 characters of the password are used to form a 56-bit integer; with the first character providing the most significant 7 bits, and the 8th character providing the least significant 7 bits.
20 repeated rounds of modified DES encryption are performed; starting with a null input block, and using the 56-bit integer from step 4 as the DES key.
The salt value from step 2 is used to to mutate the normal DES encrypt operation by swapping bits i and i+24 in the DES E-Box output if and only if bit i is set in the salt value.
The 64-bit result of the last round of step 5 is then lsb-padded with 2 zero bits.
The resulting 66-bit integer is encoded in big-endian order using the hash64-big format. This is the first checksum segment.
The second checksum segment is created by repeating steps 4..7 using the second 8 bytes of the padding password (from step 3). The only difference is that step 5 uses only 5 rounds.
The final checksum string is the concatenation of the two checksum segments, in order.
Crypt16 is dangerously flawed:
This implementation of crypt16 deviates from public documentation of the format in one way:
The original crypt16 algorithm was designed for 7-bit us-ascii encoding only (as evidenced by the fact that it discards the 8th bit of all password bytes).
In order to provide support for unicode strings, Passlib will encode unicode passwords using utf-8 before running them through crypt16. If a different encoding is desired by an application, the password should be encoded before handing it to Passlib.
|||One source of information about bigcrypt & crypt16 - http://email@example.com/msg00970.html|