Lines Matching +full:data +full:- +full:independent
1 .. SPDX-License-Identifier: GPL-2.0
13 ------------------------------------------------------------------------------
15 des - fast & portable DES encryption & decryption.
42 2. PORTABILITY to any byte-addressable host with a 32bit unsigned C type
43 3. Plug-compatible replacement for KERBEROS's low-level routines.
46 register-starved machines. My discussions with Richard Outerbridge,
51 up in a parameterized fashion so it can easily be modified by speed-daemon
58 compile on a SPARCStation 1 (cc -O4, gcc -O2):
60 this code (byte-order independent):
62 - 30us per encryption (options: 64k tables, no IP/FP)
63 - 33us per encryption (options: 64k tables, FIPS standard bit ordering)
64 - 45us per encryption (options: 2k tables, no IP/FP)
65 - 48us per encryption (options: 2k tables, FIPS standard bit ordering)
66 - 275us to set a new key (uses 1k of key tables)
71 the key setting routine. also, i have no interest in re-implementing
74 used as drop-in replacements with mit's code or any of the mit-
80 - 53us per encryption (uses 2k of tables)
81 - 96us to set a new key (uses 2.25k of key tables)
86 more specifically, 19-40% slower on the 68020 and 11-35% slower
93 gcc 2.1 -O2 Sun 3/110 304 uS 369.5uS 461.8uS 22%
94 cc -O1 Sun 3/110 336 uS 436.6uS 399.3uS 19%
95 cc -O2 Sun 3/110 360 uS 532.4uS 505.1uS 40%
96 cc -O4 Sun 3/110 365 uS 532.3uS 505.3uS 38%
97 gcc 2.1 -O2 Sun 4/50 48 uS 53.4uS 57.5uS 11%
98 cc -O2 Sun 4/50 48 uS 64.6uS 64.7uS 35%
99 cc -O4 Sun 4/50 48 uS 64.7uS 64.9uS 35%
106 - 68us per encryption (uses 2k of tables)
107 - 96us to set a new key (uses 2.25k of key tables)
111 it's a bit weak on common low-level optimizations which is why
112 it's 39%-106% slower. because he was interested in fast crypt(3) and
113 password-cracking applications, he also used the same ideas to
114 speed up the key-setting routines with impressive results.
127 to use only 128k. his tables and code are machine independent.
133 - 108us per encryption (uses 34k worth of tables)
134 - 134us to set a new key (uses 32k of key tables to get this speed!)
136 the tables used seem to be machine-independent;
151 ``highly optimized`` and tweaked Kerberos/Athena code (byte-order dependent):
153 - 165us per encryption (uses 6k worth of tables)
154 - 478us to set a new key (uses <1k of key tables)
158 machine-independent.
161 UC Berkeley code (depends on machine-endedness):
162 - 226us per encryption
163 - 10848us to set a new key
175 i got it and looked at the code, it really set off a lot of pet peeves -
180 by adding MORE statements to make the data movement more ``consistent``
181 instead of simplifying his implementation and cutting down on all data
184 speedups but which did obfuscate everything. so i took the test data
190 do the same - it was a trivial change from which i had been scared away
192 the working data in TWO forms, one for easy use of half the sboxes in
195 half. this means i have (almost) half the data manipulation and half
197 to crypt(3) in his tables - i didn't check.
201 than versions hand-written in assembly for the sparc!
211 of what i didn't want to do; all their endedness-specific ``optimizations``
213 independent approach. however, there are always some portability
227 the (worst-case) cost of my NOT doing endedness-specific optimizations
228 in the data loading and storing code surrounding the key iterations
230 the input and output work areas do not need to be word-aligned.
250 be able to get performance equal to assembly-coding, except that:
255 2) if your machine has less than 12 32-bit registers i doubt your compiler will
260 however, if you like assembly coding, the 386 does have 7 32-bit registers,
265 the 6 bits of data is the low part; it helps to exchange these.
285 - anything more than 12 bits (bad for RISC and CISC)
286 - greater than 127 in value (can't use movq or byte immediate on CISC)
287 - 9-127 (may not be able to use CISC shift immediate or add/sub quick),
288 - 1-8 were never registered, being the cheapest constants.
302 all index scaling is done explicitly - no hidden shifts by log2(sizeof).
314 special efficient data format
338 used to hold full 768-bit key.
339 must be long-aligned.
349 which must have odd parity (or -1 is returned) and which must
350 not be a (semi-)weak key (or -2 is returned).
357 m yourself, you will get a 768bit key - but then it won't
365 provide a routine that converts 128 6-bit bytes (specified in
366 S-box mapping order or something) into the right format for you.
378 and final permutation is done; if not, then the data is loaded
393 there are no machine-dependencies in the code (see porting),
395 ALL generated tables are machine independent.
403 note that i have included a kerberos-compatible interface in desUtil.c
405 to use these with kerberos or kerberos-compatible code put desCore.a
406 ahead of the kerberos-compatible library on your linker's command line.