1 /* 2 * Copyright (c) 1989, 1993 3 * The Regents of the University of California. All rights reserved. 4 * 5 * This code is derived from software contributed to Berkeley by 6 * Tom Truscott. 7 * 8 * Redistribution and use in source and binary forms, with or without 9 * modification, are permitted provided that the following conditions 10 * are met: 11 * 1. Redistributions of source code must retain the above copyright 12 * notice, this list of conditions and the following disclaimer. 13 * 2. Redistributions in binary form must reproduce the above copyright 14 * notice, this list of conditions and the following disclaimer in the 15 * documentation and/or other materials provided with the distribution. 16 * 3. Neither the name of the University nor the names of its contributors 17 * may be used to endorse or promote products derived from this software 18 * without specific prior written permission. 19 * 20 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23 * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30 * SUCH DAMAGE. 31 */ 32 33 #ifndef CRYPT_H 34 #define CRYPT_H 1 35 36 /* ===== Configuration ==================== */ 37 38 #ifdef CHAR_BITS 39 #if CHAR_BITS != 8 40 #error C_block structure assumes 8 bit characters 41 #endif 42 #endif 43 44 #ifndef LONG_LONG 45 # if SIZEOF_LONG_LONG > 0 46 # define LONG_LONG long long 47 # elif SIZEOF___INT64 > 0 48 # define HAVE_LONG_LONG 1 49 # define LONG_LONG __int64 50 # undef SIZEOF_LONG_LONG 51 # define SIZEOF_LONG_LONG SIZEOF___INT64 52 # endif 53 #endif 54 55 /* 56 * define "LONG_IS_32_BITS" only if sizeof(long)==4. 57 * This avoids use of bit fields (your compiler may be sloppy with them). 58 */ 59 #if SIZEOF_LONG == 4 60 #define LONG_IS_32_BITS 61 #endif 62 63 /* 64 * define "B64" to be the declaration for a 64 bit integer. 65 * XXX this feature is currently unused, see "endian" comment below. 66 */ 67 #if SIZEOF_LONG == 8 68 #define B64 long 69 #elif SIZEOF_LONG_LONG == 8 70 #define B64 LONG_LONG 71 #endif 72 73 /* 74 * define "LARGEDATA" to get faster permutations, by using about 72 kilobytes 75 * of lookup tables. This speeds up des_setkey() and des_cipher(), but has 76 * little effect on crypt(). 77 */ 78 #if defined(notdef) 79 #define LARGEDATA 80 #endif 81 82 /* compile with "-DSTATIC=int" when profiling */ 83 #ifndef STATIC 84 #define STATIC static 85 #endif 86 87 /* ==================================== */ 88 89 /* 90 * Cipher-block representation (Bob Baldwin): 91 * 92 * DES operates on groups of 64 bits, numbered 1..64 (sigh). One 93 * representation is to store one bit per byte in an array of bytes. Bit N of 94 * the NBS spec is stored as the LSB of the Nth byte (index N-1) in the array. 95 * Another representation stores the 64 bits in 8 bytes, with bits 1..8 in the 96 * first byte, 9..16 in the second, and so on. The DES spec apparently has 97 * bit 1 in the MSB of the first byte, but that is particularly noxious so we 98 * bit-reverse each byte so that bit 1 is the LSB of the first byte, bit 8 is 99 * the MSB of the first byte. Specifically, the 64-bit input data and key are 100 * converted to LSB format, and the output 64-bit block is converted back into 101 * MSB format. 102 * 103 * DES operates internally on groups of 32 bits which are expanded to 48 bits 104 * by permutation E and shrunk back to 32 bits by the S boxes. To speed up 105 * the computation, the expansion is applied only once, the expanded 106 * representation is maintained during the encryption, and a compression 107 * permutation is applied only at the end. To speed up the S-box lookups, 108 * the 48 bits are maintained as eight 6 bit groups, one per byte, which 109 * directly feed the eight S-boxes. Within each byte, the 6 bits are the 110 * most significant ones. The low two bits of each byte are zero. (Thus, 111 * bit 1 of the 48 bit E expansion is stored as the "4"-valued bit of the 112 * first byte in the eight byte representation, bit 2 of the 48 bit value is 113 * the "8"-valued bit, and so on.) In fact, a combined "SPE"-box lookup is 114 * used, in which the output is the 64 bit result of an S-box lookup which 115 * has been permuted by P and expanded by E, and is ready for use in the next 116 * iteration. Two 32-bit wide tables, SPE[0] and SPE[1], are used for this 117 * lookup. Since each byte in the 48 bit path is a multiple of four, indexed 118 * lookup of SPE[0] and SPE[1] is simple and fast. The key schedule and 119 * "salt" are also converted to this 8*(6+2) format. The SPE table size is 120 * 8*64*8 = 4K bytes. 121 * 122 * To speed up bit-parallel operations (such as XOR), the 8 byte 123 * representation is "union"ed with 32 bit values "i0" and "i1", and, on 124 * machines which support it, a 64 bit value "b64". This data structure, 125 * "C_block", has two problems. First, alignment restrictions must be 126 * honored. Second, the byte-order (e.g. little-endian or big-endian) of 127 * the architecture becomes visible. 128 * 129 * The byte-order problem is unfortunate, since on the one hand it is good 130 * to have a machine-independent C_block representation (bits 1..8 in the 131 * first byte, etc.), and on the other hand it is good for the LSB of the 132 * first byte to be the LSB of i0. We cannot have both these things, so we 133 * currently use the "little-endian" representation and avoid any multi-byte 134 * operations that depend on byte order. This largely precludes use of the 135 * 64-bit datatype since the relative order of i0 and i1 are unknown. It 136 * also inhibits grouping the SPE table to look up 12 bits at a time. (The 137 * 12 bits can be stored in a 16-bit field with 3 low-order zeroes and 1 138 * high-order zero, providing fast indexing into a 64-bit wide SPE.) On the 139 * other hand, 64-bit datatypes are currently rare, and a 12-bit SPE lookup 140 * requires a 128 kilobyte table, so perhaps this is not a big loss. 141 * 142 * Permutation representation (Jim Gillogly): 143 * 144 * A transformation is defined by its effect on each of the 8 bytes of the 145 * 64-bit input. For each byte we give a 64-bit output that has the bits in 146 * the input distributed appropriately. The transformation is then the OR 147 * of the 8 sets of 64-bits. This uses 8*256*8 = 16K bytes of storage for 148 * each transformation. Unless LARGEDATA is defined, however, a more compact 149 * table is used which looks up 16 4-bit "chunks" rather than 8 8-bit chunks. 150 * The smaller table uses 16*16*8 = 2K bytes for each transformation. This 151 * is slower but tolerable, particularly for password encryption in which 152 * the SPE transformation is iterated many times. The small tables total 9K 153 * bytes, the large tables total 72K bytes. 154 * 155 * The transformations used are: 156 * IE3264: MSB->LSB conversion, initial permutation, and expansion. 157 * This is done by collecting the 32 even-numbered bits and applying 158 * a 32->64 bit transformation, and then collecting the 32 odd-numbered 159 * bits and applying the same transformation. Since there are only 160 * 32 input bits, the IE3264 transformation table is half the size of 161 * the usual table. 162 * CF6464: Compression, final permutation, and LSB->MSB conversion. 163 * This is done by two trivial 48->32 bit compressions to obtain 164 * a 64-bit block (the bit numbering is given in the "CIFP" table) 165 * followed by a 64->64 bit "cleanup" transformation. (It would 166 * be possible to group the bits in the 64-bit block so that 2 167 * identical 32->32 bit transformations could be used instead, 168 * saving a factor of 4 in space and possibly 2 in time, but 169 * byte-ordering and other complications rear their ugly head. 170 * Similar opportunities/problems arise in the key schedule 171 * transforms.) 172 * PC1ROT: MSB->LSB, PC1 permutation, rotate, and PC2 permutation. 173 * This admittedly baroque 64->64 bit transformation is used to 174 * produce the first code (in 8*(6+2) format) of the key schedule. 175 * PC2ROT[0]: Inverse PC2 permutation, rotate, and PC2 permutation. 176 * It would be possible to define 15 more transformations, each 177 * with a different rotation, to generate the entire key schedule. 178 * To save space, however, we instead permute each code into the 179 * next by using a transformation that "undoes" the PC2 permutation, 180 * rotates the code, and then applies PC2. Unfortunately, PC2 181 * transforms 56 bits into 48 bits, dropping 8 bits, so PC2 is not 182 * invertible. We get around that problem by using a modified PC2 183 * which retains the 8 otherwise-lost bits in the unused low-order 184 * bits of each byte. The low-order bits are cleared when the 185 * codes are stored into the key schedule. 186 * PC2ROT[1]: Same as PC2ROT[0], but with two rotations. 187 * This is faster than applying PC2ROT[0] twice, 188 * 189 * The Bell Labs "salt" (Bob Baldwin): 190 * 191 * The salting is a simple permutation applied to the 48-bit result of E. 192 * Specifically, if bit i (1 <= i <= 24) of the salt is set then bits i and 193 * i+24 of the result are swapped. The salt is thus a 24 bit number, with 194 * 16777216 possible values. (The original salt was 12 bits and could not 195 * swap bits 13..24 with 36..48.) 196 * 197 * It is possible, but ugly, to warp the SPE table to account for the salt 198 * permutation. Fortunately, the conditional bit swapping requires only 199 * about four machine instructions and can be done on-the-fly with about an 200 * 8% performance penalty. 201 */ 202 203 typedef union { 204 unsigned char b[8]; 205 struct { 206 #if defined(LONG_IS_32_BITS) 207 /* long is often faster than a 32-bit bit field */ 208 long i0; 209 long i1; 210 #else 211 long i0: 32; 212 long i1: 32; 213 #endif 214 } b32; 215 #if defined(B64) 216 B64 b64; 217 #endif 218 } C_block; 219 220 #if defined(LARGEDATA) 221 /* Waste memory like crazy. Also, do permutations in line */ 222 #define LGCHUNKBITS 3 223 #define CHUNKBITS (1<<LGCHUNKBITS) 224 #else 225 /* "small data" */ 226 #define LGCHUNKBITS 2 227 #define CHUNKBITS (1<<LGCHUNKBITS) 228 #endif 229 230 struct crypt_data { 231 /* The Key Schedule, filled in by des_setkey() or setkey(). */ 232 #define KS_SIZE 16 233 C_block KS[KS_SIZE]; 234 235 /* ==================================== */ 236 237 char cryptresult[1+4+4+11+1]; /* encrypted result */ 238 }; 239 240 char *crypt(const char *key, const char *setting); 241 void setkey(const char *key); 242 void encrypt(char *block, int flag); 243 244 char *crypt_r(const char *key, const char *setting, struct crypt_data *data); 245 void setkey_r(const char *key, struct crypt_data *data); 246 void encrypt_r(char *block, int flag, struct crypt_data *data); 247 248 #endif /* CRYPT_H */ 249