Lines Matching refs:and
7 This program is free software; you can redistribute it and/or modify
43 and then move on to the common abstract skeleton with this one in mind.
57 and password cracking, i haven't really bothered yet to speed up
70 encryption/decryption is still slower on the sparc and 68000.
71 more specifically, 19-40% slower on the 68020 and 11-35% slower
89 it's 39%-106% slower. because he was interested in fast crypt(3) and
98 crypt function and i didn't feel like ripping it out and measuring
100 des iteration; above, Quick (64k) takes 21 and Small (2k) takes 37.
102 to use only 128k. his tables and code are machine independent.
117 of tables and appears to be slow.
120 ``highly optimized'' and tweaked Kerberos/Athena code (byte-order dependent):
135 motivation and history
137 a while ago i wanted some des routines and the routines documented on sun's
139 and knew that it used des, so i figured i'd use its routines. but once
140 i got it and looked at the code, it really set off a lot of pet peeves -
142 advantage of the regular structure of operations such as IP, E, and FP
143 (i.e. the author didn't sit down and think before coding),
146 instead of simplifying his implementation and cutting down on all data
147 movement (in particular, his use of L1, R1, L2, R2), and it was full of
150 from his verification program and rewrote everything else.
154 than one (and using a MUCH larger table in the process) emboldened me to
159 it in the form for the first half and use a simple rotate to get the other
160 half. this means i have (almost) half the data manipulation and half
165 portable (the ifdef's are performance enhancements) and it is faster
172 which depended on endedness and other machine quirks,
173 and which necessarily produced different code and different lookup tables
176 obfuscate the code and in the end were slower than a simpler machine
178 considerations of some kind, and i have included some options
183 depend on the byte order, and that bytes are 8 bits.
184 i assume word pointers can be freely cast to and from char pointers.
192 in the data loading and storing code surrounding the key iterations
194 the input and output work areas do not need to be word-aligned.
205 ROR and ROL macros to use machine rotate instructions if you have them.
206 this will save 2 instructions and a temporary per use,
219 (it appears that gcc can use ebx, esi and edi to hold register variables).
221 and if you use ALL of them, use `scaled by 8' address modes with displacement
222 and other tricks, you can get reasonable routines for DesQuickCore... with
224 des_keymap, i.e., now the sbox # is the high part of the index and
228 to put everything in registers(!), and generate about 370 instructions apiece
241 anything more than 12 bits (bad for RISC and CISC)
245 b) the compiler may be too stupid to realize table and table+256 should
246 be assigned to different constant registers and instead repetitively
248 when possible and helpful.
252 this assumption is reversed for 68k and vax.
255 or from a register and a small constant.
256 for the 68000, the `two registers and small offset' form is used sparingly.
284 used to hold keys and input/output blocks to des.
298 which must have odd parity (or -1 is returned) and which must
309 on some machines. and yes, each byte controls
314 this would entail some byte concatenation and rotation.
321 and final permutation is done; if not, then the data is loaded
322 and stored in a nonstandard bit order (FIPS w/o IP/FP).
340 Speeding up kerberos (and/or its des library)
343 through the functions des_key_sched() and des_ecb_encrypt().