1CKSUM(1P) POSIX Programmer's Manual CKSUM(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
13 cksum — write file checksums and sizes
14
16 cksum [file...]
17
19 The cksum utility shall calculate and write to standard output a cyclic
20 redundancy check (CRC) for each input file, and also write to standard
21 output the number of octets in each file. The CRC used is based on the
22 polynomial used for CRC error checking in the ISO/IEC 8802‐3:1996 stan‐
23 dard (Ethernet).
24 The encoding for the CRC checksum is defined by the generating polyno‐
26 mial:
27 G(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
29 Mathematically, the CRC value corresponding to a given file shall be
31 defined by the following procedure:
32 1. The n bits to be evaluated are considered to be the coefficients of
34 a mod 2 polynomial M(x) of degree n−1. These n bits are the bits
35 from the file, with the most significant bit being the most signif‐
36 icant bit of the first octet of the file and the last bit being the
37 least significant bit of the last octet, padded with zero bits (if
38 necessary) to achieve an integral number of octets, followed by one
39 or more octets representing the length of the file as a binary
40 value, least significant octet first. The smallest number of octets
41 capable of representing this integer shall be used.
42 2. M(x) is multiplied by x32 (that is, shifted left 32 bits) and
44 divided by G(x) using mod 2 division, producing a remainder R(x) of
45 degree ≤ 31.
46 3. The coefficients of R(x) are considered to be a 32-bit sequence.
48 4. The bit sequence is complemented and the result is the CRC.
50
52 None.
53
55 The following operand shall be supported:
56 file A pathname of a file to be checked. If no file operands are
58 specified, the standard input shall be used.
59
61 The standard input shall be used if no file operands are specified, and
62 shall be used if a file operand is '−' and the implementation treats
63 the '−' as meaning standard input. Otherwise, the standard input shall
64 not be used. See the INPUT FILES section.
65
67 The input files can be any file type.
68
70 The following environment variables shall affect the execution of
71 cksum:
72 LANG Provide a default value for the internationalization vari‐
74 ables that are unset or null. (See the Base Definitions vol‐
75 ume of POSIX.1‐2008, Section 8.2, Internationalization Vari‐
76 ables for the precedence of internationalization variables
77 used to determine the values of locale categories.)
78 LC_ALL If set to a non-empty string value, override the values of
80 all the other internationalization variables.
81 LC_CTYPE Determine the locale for the interpretation of sequences of
83 bytes of text data as characters (for example, single-byte as
84 opposed to multi-byte characters in arguments).
85 LC_MESSAGES
87 Determine the locale that should be used to affect the format
88 and contents of diagnostic messages written to standard
89 error.
90 NLSPATH Determine the location of message catalogs for the processing
92 of LC_MESSAGES.
93
95 Default.
96
98 For each file processed successfully, the cksum utility shall write in
99 the following format:
100 "%u %d %s\n", <checksum>, <# of octets>, <pathname>
102 If no file operand was specified, the pathname and its leading <space>
104 shall be omitted.
105
107 The standard error shall be used only for diagnostic messages.
108
110 None.
111
113 None.
114
116 The following exit values shall be returned:
117 0 All files were processed successfully.
119 >0 An error occurred.
121
123 Default.
124 The following sections are informative.
126
128 The cksum utility is typically used to quickly compare a suspect file
129 against a trusted version of the same, such as to ensure that files
130 transmitted over noisy media arrive intact. However, this comparison
131 cannot be considered cryptographically secure. The chances of a damaged
132 file producing the same CRC as the original are small; deliberate
133 deception is difficult, but probably not impossible.
134 Although input files to cksum can be any type, the results need not be
136 what would be expected on character special device files or on file
137 types not described by the System Interfaces volume of POSIX.1‐2008.
138 Since this volume of POSIX.1‐2008 does not specify the block size used
139 when doing input, checksums of character special files need not process
140 all of the data in those files.
141 The algorithm is expressed in terms of a bitstream divided into octets.
143 If a file is transmitted between two systems and undergoes any data
144 transformation (such as changing little-endian byte ordering to big-
145 endian), identical CRC values cannot be expected. Implementations per‐
146 forming such transformations may extend cksum to handle such situa‐
147 tions.
148
150 None.
151
153 The following C-language program can be used as a model to describe the
154 algorithm. It assumes that a char is one octet. It also assumes that
155 the entire file is available for one pass through the function. This
156 was done for simplicity in demonstrating the algorithm, rather than as
157 an implementation model.
158 static unsigned long crctab[] = {
160 0x00000000,
161 0x04c11db7, 0x09823b6e, 0x0d4326d9, 0x130476dc, 0x17c56b6b,
162 0x1a864db2, 0x1e475005, 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6,
163 0x2b4bcb61, 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
164 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9, 0x5f15adac,
165 0x5bd4b01b, 0x569796c2, 0x52568b75, 0x6a1936c8, 0x6ed82b7f,
166 0x639b0da6, 0x675a1011, 0x791d4014, 0x7ddc5da3, 0x709f7b7a,
167 0x745e66cd, 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
168 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52, 0x8664e6e5, 0xbe2b5b58,
169 0xbaea46ef, 0xb7a96036, 0xb3687d81, 0xad2f2d84, 0xa9ee3033,
170 0xa4ad16ea, 0xa06c0b5d, 0xd4326d90, 0xd0f37027, 0xddb056fe,
171 0xd9714b49, 0xc7361b4c, 0xc3f706fb, 0xceb42022, 0xca753d95,
172 0xf23a8028, 0xf6fb9d9f, 0xfbb8bb46, 0xff79a6f1, 0xe13ef6f4,
173 0xe5ffeb43, 0xe8bccd9a, 0xec7dd02d, 0x34867077, 0x30476dc0,
174 0x3d044b19, 0x39c556ae, 0x278206ab, 0x23431b1c, 0x2e003dc5,
175 0x2ac12072, 0x128e9dcf, 0x164f8078, 0x1b0ca6a1, 0x1fcdbb16,
176 0x018aeb13, 0x054bf6a4, 0x0808d07d, 0x0cc9cdca, 0x7897ab07,
177 0x7c56b6b0, 0x71159069, 0x75d48dde, 0x6b93dddb, 0x6f52c06c,
178 0x6211e6b5, 0x66d0fb02, 0x5e9f46bf, 0x5a5e5b08, 0x571d7dd1,
179 0x53dc6066, 0x4d9b3063, 0x495a2dd4, 0x44190b0d, 0x40d816ba,
180 0xaca5c697, 0xa864db20, 0xa527fdf9, 0xa1e6e04e, 0xbfa1b04b,
181 0xbb60adfc, 0xb6238b25, 0xb2e29692, 0x8aad2b2f, 0x8e6c3698,
182 0x832f1041, 0x87ee0df6, 0x99a95df3, 0x9d684044, 0x902b669d,
183 0x94ea7b2a, 0xe0b41de7, 0xe4750050, 0xe9362689, 0xedf73b3e,
184 0xf3b06b3b, 0xf771768c, 0xfa325055, 0xfef34de2, 0xc6bcf05f,
185 0xc27dede8, 0xcf3ecb31, 0xcbffd686, 0xd5b88683, 0xd1799b34,
186 0xdc3abded, 0xd8fba05a, 0x690ce0ee, 0x6dcdfd59, 0x608edb80,
187 0x644fc637, 0x7a089632, 0x7ec98b85, 0x738aad5c, 0x774bb0eb,
188 0x4f040d56, 0x4bc510e1, 0x46863638, 0x42472b8f, 0x5c007b8a,
189 0x58c1663d, 0x558240e4, 0x51435d53, 0x251d3b9e, 0x21dc2629,
190 0x2c9f00f0, 0x285e1d47, 0x36194d42, 0x32d850f5, 0x3f9b762c,
191 0x3b5a6b9b, 0x0315d626, 0x07d4cb91, 0x0a97ed48, 0x0e56f0ff,
192 0x1011a0fa, 0x14d0bd4d, 0x19939b94, 0x1d528623, 0xf12f560e,
193 0xf5ee4bb9, 0xf8ad6d60, 0xfc6c70d7, 0xe22b20d2, 0xe6ea3d65,
194 0xeba91bbc, 0xef68060b, 0xd727bbb6, 0xd3e6a601, 0xdea580d8,
195 0xda649d6f, 0xc423cd6a, 0xc0e2d0dd, 0xcda1f604, 0xc960ebb3,
196 0xbd3e8d7e, 0xb9ff90c9, 0xb4bcb610, 0xb07daba7, 0xae3afba2,
197 0xaafbe615, 0xa7b8c0cc, 0xa379dd7b, 0x9b3660c6, 0x9ff77d71,
198 0x92b45ba8, 0x9675461f, 0x8832161a, 0x8cf30bad, 0x81b02d74,
199 0x857130c3, 0x5d8a9099, 0x594b8d2e, 0x5408abf7, 0x50c9b640,
200 0x4e8ee645, 0x4a4ffbf2, 0x470cdd2b, 0x43cdc09c, 0x7b827d21,
201 0x7f436096, 0x7200464f, 0x76c15bf8, 0x68860bfd, 0x6c47164a,
202 0x61043093, 0x65c52d24, 0x119b4be9, 0x155a565e, 0x18197087,
203 0x1cd86d30, 0x029f3d35, 0x065e2082, 0x0b1d065b, 0x0fdc1bec,
204 0x3793a651, 0x3352bbe6, 0x3e119d3f, 0x3ad08088, 0x2497d08d,
205 0x2056cd3a, 0x2d15ebe3, 0x29d4f654, 0xc5a92679, 0xc1683bce,
206 0xcc2b1d17, 0xc8ea00a0, 0xd6ad50a5, 0xd26c4d12, 0xdf2f6bcb,
207 0xdbee767c, 0xe3a1cbc1, 0xe760d676, 0xea23f0af, 0xeee2ed18,
208 0xf0a5bd1d, 0xf464a0aa, 0xf9278673, 0xfde69bc4, 0x89b8fd09,
209 0x8d79e0be, 0x803ac667, 0x84fbdbd0, 0x9abc8bd5, 0x9e7d9662,
210 0x933eb0bb, 0x97ffad0c, 0xafb010b1, 0xab710d06, 0xa6322bdf,
211 0xa2f33668, 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4
212 };
213 unsigned long memcrc(const unsigned char *b, size_t n)
215 {
216 /* Input arguments:
217 * const unsigned char* b == byte sequence to checksum
218 * size_t n == length of sequence
219 */
220 register size_t i;
222 register unsigned c, s = 0;
223 for (i = n; i > 0; −−i) {
225 c = *b++;
226 s = (s << 8) ^ crctab[(s >> 24) ^ c];
227 }
228 /* Extend with the length of the string. */
230 while (n != 0) {
231 c = n & 0377;
232 n >>= 8;
233 s = (s << 8) ^ crctab[(s >> 24) ^ c];
234 }
235 return ~s;
237 }
238 The historical practice of writing the number of ``blocks'' has been
240 changed to writing the number of octets, since the latter is not only
241 more useful, but also since historical implementations have not been
242 consistent in defining what a ``block'' meant.
243 The algorithm used was selected to increase the operational robustness
245 of cksum. Neither the System V nor BSD sum algorithm was selected.
246 Since each of these was different and each was the default behavior on
247 those systems, no realistic compromise was available if either were
248 selected—some set of historical applications would break. Therefore,
249 the name was changed to cksum. Although the historical sum commands
250 will probably continue to be provided for many years, programs designed
251 for portability across systems should use the new name.
252 The algorithm selected is based on that used by the ISO/IEC 8802‐3:1996
254 standard (Ethernet) for the frame check sequence field. The algorithm
255 used does not match the technical definition of a checksum; the term is
256 used for historical reasons. The length of the file is included in the
257 CRC calculation because this parallels inclusion of a length field by
258 Ethernet in its CRC, but also because it guards against inadvertent
259 collisions between files that begin with different series of zero
260 octets. The chance that two different files produce identical CRCs is
261 much greater when their lengths are not considered. Keeping the length
262 and the checksum of the file itself separate would yield a slightly
263 more robust algorithm, but historical usage has always been that a sin‐
264 gle number (the checksum as printed) represents the signature of the
265 file. It was decided that historical usage was the more important con‐
266 sideration.
267 Early proposals contained modifications to the Ethernet algorithm that
269 involved extracting table values whenever an intermediate result became
270 zero. This was demonstrated to be less robust than the current method
271 and mathematically difficult to describe or justify.
272 The calculation used is identical to that given in pseudo-code in the
274 referenced Sarwate article. The pseudo-code rendition is:
275 X <− 0; Y <− 0;
277 for i <− m −1 step −1 until 0 do
278 begin
279 T <− X(1) ^ A[i];
280 X(1) <− X(0); X(0) <− Y(1); Y(1) <− Y(0); Y(0) <− 0;
281 comment: f[T] and f'[T] denote the T-th words in the
282 table f and f' ;
283 X <− X ^ f[T]; Y <− Y ^ f'[T];
284 end
285 The pseudo-code is reproduced exactly as given; however, note that in
287 the case of cksum, A[i] represents a byte of the file, the words X and
288 Y are treated as a single 32-bit value, and the tables f and f' are a
289 single table containing 32-bit values.
290 The referenced Sarwate article also discusses generating the table.
292
294 None.
295
297 The Base Definitions volume of POSIX.1‐2008, Chapter 8, Environment
298 Variables
299
301 Portions of this text are reprinted and reproduced in electronic form
302 from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
303 -- Portable Operating System Interface (POSIX), The Open Group Base
304 Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
305 cal and Electronics Engineers, Inc and The Open Group. (This is
306 POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
307 event of any discrepancy between this version and the original IEEE and
308 The Open Group Standard, the original IEEE and The Open Group Standard
309 is the referee document. The original Standard can be obtained online
310 at http://www.unix.org/online.html .
311 Any typographical or formatting errors that appear in this page are
313 most likely to have been introduced during the conversion of the source
314 files to man page format. To report such errors, see https://www.ker‐
315 nel.org/doc/man-pages/reporting_bugs.html .
316IEEE/The Open Group 2013 CKSUM(1P)