mirror of
git://sourceware.org/git/glibc.git
synced 2024-11-21 01:12:26 +08:00
841785bad1
This is a major rewrite of the description of 'crypt', 'getentropy', and 'getrandom'. A few highlights of the content changes: - Throughout the manual, public headers, and user-visible messages, I replaced the term "password" with "passphrase", the term "password database" with "user database", and the term "encrypt(ion)" with "(one-way) hashing" whenever it was applied to passphrases. I didn't bother making this change in internal code or tests. The use of the term "password" in ruserpass.c survives, because that refers to a keyword in netrc files, but it is adjusted to make this clearer. There is a note in crypt.texi explaining that they were traditionally called passwords but single words are not good enough anymore, and a note in users.texi explaining that actual passphrase hashes are found in a "shadow" database nowadays. - There is a new short introduction to the "Cryptographic Functions" section, explaining how we do not intend to be a general-purpose cryptography library, and cautioning that there _are_, or have been, legal restrictions on the use of cryptography in many countries, without getting into any kind of detail that we can't promise to keep up to date. - I added more detail about what a "one-way function" is, and why they are used to obscure passphrases for storage. I removed the paragraph saying that systems not connected to a network need no user authentication, because that's a pretty rare situation nowadays. (It still says "sometimes it is necessary" to authenticate the user, though.) - I added documentation for all of the hash functions that glibc actually supports, but not for the additional hash functions supported by libxcrypt. If we're going to keep this manual section around after the transition is more advanced, it would probably make sense to add them then. - There is much more detailed discussion of how to generate a salt, and the failure behavior for crypt is documented. (Returning an invalid hash on failure is what libxcrypt does; Solar Designer's notes say that this was done "for compatibility with old programs that assume crypt can never fail".) - As far as I can tell, the header 'crypt.h' is entirely a GNU invention, and never existed on any other Unix lineage. The function 'crypt', however, was in Issue 1 of the SVID and is now in the XSI component of POSIX. I tried to make all of the @standards annotations consistent with this, but I'm not sure I got them perfectly right. - The genpass.c example has been improved to use getentropy instead of the current time to generate the salt, and to use a SHA-256 hash instead of MD5. It uses more random bytes than is strictly necessary because I didn't want to complicate the code with proper base64 encoding. - The testpass.c example has three hardwired hashes now, to demonstrate that different one-way functions produce different hashes for the same input. It also demonstrates how DES hashing only pays attention to the first eight characters of the input. - There is new text explaining in more detail how a CSPRNG differs from a regular random number generator, and how getentropy/getrandom are not exactly a CSPRNG. I tried not to make specific falsifiable claims here. I also tried to make the blocking/cancellation/error behavior of both getentropy and getrandom clearer. |
||
|---|---|---|
| .. | ||
| badsalttest.c | ||
| cert.c | ||
| cert.input | ||
| crypt_util.c | ||
| crypt-entry.c | ||
| crypt-private.h | ||
| crypt.c | ||
| crypt.h | ||
| Makefile | ||
| md5-block.c | ||
| md5-crypt.c | ||
| md5.c | ||
| md5.h | ||
| md5c-test.c | ||
| md5test-giant.c | ||
| md5test.c | ||
| README.ufc-crypt | ||
| sha256-block.c | ||
| sha256-crypt.c | ||
| sha256.c | ||
| sha256.h | ||
| sha256c-test.c | ||
| sha256test.c | ||
| sha512-block.c | ||
| sha512-crypt.c | ||
| sha512.c | ||
| sha512.h | ||
| sha512c-test.c | ||
| sha512test.c | ||
| speeds.c | ||
| ufc-crypt.h | ||
| ufc.c | ||
| Versions | ||
The following is the README for UFC-crypt, with those portions deleted that are known to be incorrect for the implementation used with the GNU C library. UFC-crypt: ultra fast 'crypt' implementation ============================================ @(#)README 2.27 11 Sep 1996 Design goals/non goals: ---------------------- - Crypt implementation plugin compatible with crypt(3)/fcrypt. - High performance when used for password cracking. - Portable to most 32/64 bit machines. - Startup time/mixed salt performance not critical. Features of the implementation: ------------------------------ - On most machines, UFC-crypt runs 30-60 times faster than crypt(3) when invoked repeated times with the same salt and varying passwords. - With mostly constant salts, performance is about two to three times that of the default fcrypt implementation shipped with Alec Muffets 'Crack' password cracker. For instructions on how to plug UFC-crypt into 'Crack', see below. - With alternating salts, performance is only about twice that of crypt(3). - Requires 165 kb for tables. Author & licensing etc ---------------------- UFC-crypt is created by Michael Glad, email: glad@daimi.aau.dk, and has been donated to the Free Software Foundation, Inc. It is covered by the GNU library license version 2, see the file 'COPYING.LIB'. NOTES FOR USERS OUTSIDE THE US: ------------------------------ The US government limits the export of DES based software/hardware. This software is written in Aarhus, Denmark. It can therefore be retrieved from ftp sites outside the US without breaking US law. Please do not ftp it from american sites. Benchmark table: --------------- The table shows how many operations per second UFC-crypt can do on various machines. |--------------|-------------------------------------------| |Machine | SUN* SUN* HP* DecStation HP | | | 3/50 ELC 9000/425e 3100 9000/720 | |--------------|-------------------------------------------| | Crypt(3)/sec | 4.6 30 15 25 57 | | Ufc/sec | 220 990 780 1015 3500 | |--------------|-------------------------------------------| | Speedup | 48 30 52 40 60 | |--------------|-------------------------------------------| *) Compiled using special assembly language support module. It seems as if performance is limited by CPU bus and data cache capacity. This also makes the benchmarks debatable compared to a real test with UFC-crypt wired into Crack. However, the table gives an outline of what can be expected. Optimizations: ------------- Here are the optimizations used relative to an ordinary implementation such as the one said to be used in crypt(3). Major optimizations ******************* - Keep data packed as bits in integer variables -- allows for fast permutations & parallel xor's in CPU hardware. - Let adjacent final & initial permutations collapse. - Keep working data in 'E expanded' format all the time. - Implement DES 'f' function mostly by table lookup - Calculate the above function on 12 bit basis rather than 6 as would be the most natural. - Implement setup routines so that performance is limited by the DES inner loops only. - Instead of doing salting in the DES inner loops, modify the above tables each time a new salt is seen. According to the BSD crypt code this is ugly :-) Minor (dirty) optimizations *************************** - combine iterations of DES inner loop so that DES only loops 8 times. This saves a lot of variable swapping. - Implement key access by a walking pointer rather than coding as array indexing. - As described, the table based f function uses a 3 dimensional array: sb ['number of 12 bit segment']['12 bit index']['48 bit half index'] Code the routine with 4 (one dimensional) vectors. - Design the internal data format & uglify the DES loops so that the compiler does not need to do bit shifts when indexing vectors. Revision history **************** UFC patchlevel 0: base version; released to alt.sources on Sep 24 1991 UFC patchlevel 1: patch released to alt.sources on Sep 27 1991. No longer rebuilds sb tables when seeing a new salt. UFC-crypt pl0: Essentially UFC pl 1. Released to comp.sources.misc on Oct 22 1991. UFC-crypt pl1: Released to comp.sources.misc in march 1992 * setkey/encrypt routines added * added validation/benchmarking programs * reworked keyschedule setup code * memory demands reduced * 64 bit support added