Ruby  2.5.0dev(2017-10-22revision60238)
crypt.h
Go to the documentation of this file.
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
234 
235  /* ==================================== */
236 
237  char cryptresult[1+4+4+11+1]; /* encrypted result */
238 };
239 
240 #define SIZEOF_CRYPT_DATA (KS_SIZE*8+(1+4+4+11+1))
241 
242 char *crypt(const char *key, const char *setting);
243 void setkey(const char *key);
244 void encrypt(char *block, int flag);
245 
246 char *crypt_r(const char *key, const char *setting, struct crypt_data *data);
247 void setkey_r(const char *key, struct crypt_data *data);
248 void encrypt_r(char *block, int flag, struct crypt_data *data);
249 
250 #endif /* CRYPT_H */
char * crypt_r(const char *key, const char *setting, struct crypt_data *data)
Definition: crypt.c:396
void setkey_r(const char *key, struct crypt_data *data)
Definition: crypt.c:807
void encrypt(char *block, int flag)
void setkey(const char *key)
char cryptresult[1+4+4+11+1]
Definition: crypt.h:237
long i0
Definition: crypt.h:211
C_block KS[KS_SIZE]
Definition: crypt.h:233
char * crypt(const char *key, const char *setting)
void encrypt_r(char *block, int flag, struct crypt_data *data)
Definition: crypt.c:835
long i1
Definition: crypt.h:212
#define KS_SIZE
Definition: crypt.h:232
Definition: crypt.h:203