| Sapphire.java |
1 /**
2 * Distribution License:
3 * JSword is free software; you can redistribute it and/or modify it under
4 * the terms of the GNU Lesser General Public License, version 2.1 as published by
5 * the Free Software Foundation. This program is distributed in the hope
6 * that it will be useful, but WITHOUT ANY WARRANTY; without even the
7 * implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
8 * See the GNU Lesser General Public License for more details.
9 *
10 * The License is available on the internet at:
11 * http://www.gnu.org/copyleft/lgpl.html
12 * or by writing to:
13 * Free Software Foundation, Inc.
14 * 59 Temple Place - Suite 330
15 * Boston, MA 02111-1307, USA
16 *
17 * Copyright: 2005
18 * The copyright to this program is held by it's authors.
19 *
20 * ID: $Id: Sapphire.java 1971 2009-12-04 03:05:54Z dmsmith $
21 */
22 package org.crosswire.common.crypt;
23
24 /**
25 * The Sapphire II Stream Cipher is a port of Sword's C++ implementation of
26 * Michael Paul Johnson's 2 January 1995 public domain cipher. Below is the
27 * documentation that he originally provided for it. It has been converted to
28 * JavaDoc and the C++ fragment has been removed.
29 *
30 * <h1>THE SAPPHIRE II STREAM CIPHER</h1>
31 *
32 * <p>
33 * The Sapphire II Stream Cipher is designed to have the following properties:
34 * </p>
35 * <ul>
36 *
37 * <li>Be useful for generation of cryptographic check values as well as
38 * protecting message privacy.</li>
39 *
40 * <li>Accept a variable length key.</li>
41 *
42 * <li>Strong enough to justify <i>at least</i> a 64 bit key for balanced
43 * security.</li>
44 *
45 * <li>Small enough to be built into other applications with several keys active
46 * at once.</li>
47 *
48 * <li>Key setup fast enough to support frequent key change operations but slow
49 * enough to discourage brute force attack on the key.</li>
50 *
51 * <li>Fast enough to not significantly impact file read & write operations on
52 * most current platforms.</li>
53 *
54 * <li>Portable among common computers and efficient in C, C++, and Pascal.</li>
55 *
56 * <li>Byte oriented.</li>
57 *
58 * <li>Include both ciphertext and plain text feedback (for both optimal data
59 * hiding and value in creation of cryptographic check values).</li>
60 *
61 * <li>Acceptable performance as a pure pseudorandom number generator without
62 * providing a data stream for encryption or decryption.</li>
63 *
64 * <li>Allow <i>limited</i> key reuse without serious security degradation.</li>
65 * </ul>
66 *
67 * <h2>HISTORY AND RELATED CIPHERS</h2>
68 *
69 * <p>
70 * The Sapphire Stream Cipher is very similar to a cipher I started work on in
71 * November 1993. It is also similar in some respects to the alledged RC-4 that
72 * was posted to sci.crypt recently. Both operate on the principle of a mutating
73 * permutation vector. Alledged RC-4 doesn't include any feedback of ciphertext
74 * or plain text, however. This makes it more vulnerable to a known plain text
75 * attack, and useless for creation of cryptographic check values. On the other
76 * hand, alledged RC-4 is faster.
77 * </p>
78 *
79 * <p>
80 * The Sapphire Stream Cipher is used in the shareware product Quicrypt, which
81 * is available at ftp://ftp.csn.net/mpj/qcrypt10.zip and on the Colorado
82 * Catacombs BBS (303-772-1062). There are two versions of Quicrypt: the
83 * exportable version (with a session key limited to 32 bits but with strong
84 * user keys allowed) and the commercial North American version (with a session
85 * key of 128 bits). A variant of the Sapphire Stream Cipher is also used in the
86 * shareware program Atbash, which has no weakened exportable version.
87 * </p>
88 *
89 * <p>
90 * The Sapphire II Stream Cipher is a modification of the Sapphire Stream Cipher
91 * designed to be much more resistant to adaptive chosen plaintext attacks (with
92 * reorigination of the cipher allowed). The Sapphire II Stream Cipher is used
93 * in an encryption utility called ATBASH2.
94 * </p>
95 *
96 *
97 * <h2>OVERVIEW</h2>
98 *
99 * <p>
100 * The Sapphire Stream Cipher is based on a state machine. The state consists of
101 * 5 index values and a permutation vector. The permutation vector is simply an
102 * array containing a permutation of the numbers from 0 through 255. Four of the
103 * bytes in the permutation vector are moved to new locations (which may be the
104 * same as the old location) for every byte output. The output byte is a
105 * nonlinear function of all 5 of the index values and 8 of the bytes in the
106 * permutation vector, thus frustrating attempts to solve for the state
107 * variables based on past output. On initialization, the permutation vector
108 * (called the cards array in the source code below) is shuffled based on the
109 * user key. This shuffling is done in a way that is designed to minimize the
110 * bias in the destinations of the bytes in the array. The biggest advantage in
111 * this method is not in the elimination of the bias, per se, but in slowing
112 * down the process slightly to make brute force attack more expensive.
113 * Eliminating the bias (relative to that exhibited by RC-4) is nice, but this
114 * advantage is probably of minimal cryptographic value. The index variables are
115 * set (somewhat arbitrarily) to the permutation vector elements at locations 1,
116 * 3, 5, 7, and a key dependent value (rsum) left over from the shuffling of the
117 * permutation vector (cards array).
118 * </p>
119 *
120 *
121 * <h2>KEY SETUP</h2>
122 *
123 * <p>
124 * Key setup (illustrated by the function initialize(), below) consists of three
125 * parts:
126 * </p>
127 * <ol>
128 * <li>Initialize the index variables.</li>
129 * <li>Set the permutation vector to a known state (a simple counting sequence).
130 * </li>
131 * <li>Starting at the end of the vector, swap each element of the permutation
132 * vector with an element indexed somewhere from 0 to the current index (chosen
133 * by the function keyrand()).</li>
134 * </ol>
135 * <p>
136 * The keyrand() function returns a value between 0 and some maximum number
137 * based on the user's key, the current state of the permutation vector, and an
138 * index running sum called rsum. Note that the length of the key is used in
139 * keyrand(), too, so that a key like "abcd" will not result in the same
140 * permutation as a key like "abcdabcd".
141 * </p>
142 *
143 *
144 * <h2>ENCRYPTION</h2>
145 *
146 * <p>
147 * Each encryption involves updating the index values, moving (up to) 4 bytes
148 * around in the permutation vector, selecting an output byte, and adding the
149 * output byte bitwise modulo-2 (exclusive-or) to the plain text byte to produce
150 * the cipher text byte. The index values are incremented by different rules.
151 * The index called rotor just increases by one (modulo 256) each time. Ratchet
152 * increases by the value in the permutation vector pointed to by rotor.
153 * Avalanche increases by the value in the permutation vector pointed to by
154 * another byte in the permutation vector pointed to by the last cipher text
155 * byte. The last plain text and the last cipher text bytes are also kept as
156 * index variables. See the function called encrypt(), below for details.
157 * </p>
158 *
159 *
160 * <h2>PSUEDORANDOM BYTE GENERATION</h2>
161 *
162 * <p>
163 * If you want to generate random numbers without encrypting any particular
164 * ciphertext, simply encrypt 0. There is still plenty of complexity left in the
165 * system to ensure unpredictability (if the key is not known) of the output
166 * stream when this simplification is made.
167 * </p>
168 *
169 *
170 * <h2>DECRYPTION</h2>
171 *
172 * <p>
173 * Decryption is the same as encryption, except for the obvious swapping of the
174 * assignments to last_plain and last_cipher and the return value. See the
175 * function decrypt(), below.
176 * </p>
177 *
178 *
179 * <h2>C++ SOURCE CODE FRAGMENT</h2>
180 *
181 * <p>
182 * The original implimentation of this cipher was in Object Oriented Pascal, but
183 * C++ is available for more platforms.
184 * </p>
185 *
186 * <h2>GENERATION OF CRYPTOGRAPHIC CHECK VALUES (HASH VALUES)</h2>
187 *
188 * <p>
189 * For a fast way to generate a cryptographic check value (also called a hash or
190 * message integrity check value) of a message of arbitrary length:
191 * </p>
192 * <ol>
193 * <li>Initialize either with a key (for a keyed hash value) or call hash_init
194 * with no key (for a public hash value).</li>
195 *
196 * <li>Encrypt all of the bytes of the message or file to be hashed. The results
197 * of the encryption need not be kept for the hash generation process.
198 * (Optionally decrypt encrypted text, here).</li>
199 *
200 * <li>Call hash_final, which will further "stir" the permutation vector by
201 * encrypting the values from 255 down to 0, then report the results of
202 * encrypting 20 zeroes.</li>
203 * </ol>
204 *
205 * <h2>SECURITY ANALYSIS</h2>
206 *
207 * <p>
208 * There are several security issues to be considered. Some are easier to
209 * analyze than others. The following includes more "hand waving" than
210 * mathematical proofs, and looks more like it was written by an engineer than a
211 * mathematician. The reader is invited to improve upon or refute the following,
212 * as appropriate.
213 * </p>
214 *
215 *
216 * <h2>KEY LENGTH</h2>
217 *
218 * <p>
219 * There are really two kinds of user keys to consider: (1) random binary keys,
220 * and (2) pass phrases. Analysis of random binary keys is fairly straight
221 * forward. Pass phrases tend to have much less entropy per byte, but the
222 * analysis made for random binary keys applies to the entropy in the pass
223 * phrase. The length limit of the key (255 bytes) is adequate to allow a pass
224 * phrase with enough entropy to be considered strong.
225 * </p>
226 *
227 * <p>
228 * To be real generous to a cryptanalyst, assume dedicated Sapphire Stream
229 * Cipher cracking hardware. The constant portion of the key scheduling can be
230 * done in one cycle. That leaves at least 256 cycles to do the swapping
231 * (probably more, because of the intricacies of keyrand(), but we'll ignore
232 * that, too, for now). Assume a machine clock of about 256 MegaHertz (fairly
233 * generous). That comes to about one key tried per microsecond. On average, you
234 * only have to try half of the keys. Also assume that trying the key to see if
235 * it works can be pipelined, so that it doesn't add time to the estimate. Based
236 * on these assumptions (reasonable for major governments), and rounding to two
237 * significant digits, the following key length versus cracking time estimates
238 * result:
239 * </p>
240 *
241 * <pre>
242 * Key length, bits Time to crack
243 * ---------------- -------------
244 * 32 35 minutes (exportable in qcrypt)
245 * 33 1.2 hours (not exportable in qcrypt)
246 * 40 6.4 days
247 * 56 1,100 years (kind of like DES's key)
248 * 64 290,000 years (good enough for most things)
249 * 80 19 billion years (kind of like Skipjack's key)
250 * 128 5.4E24 years (good enough for the clinically paranoid)
251 * </pre>
252 *
253 * <p>
254 * Naturally, the above estimates can vary by several orders of magnitude based
255 * on what you assume for attacker's hardware, budget, and motivation.
256 * </p>
257 *
258 * <p>
259 * In the range listed above, the probability of spare keys (two keys resulting
260 * in the same initial permutation vector) is small enough to ignore. The proof
261 * is left to the reader.
262 * </p>
263 *
264 *
265 * <h2>INTERNAL STATE SPACE</h2>
266 *
267 * <p>
268 * For a stream cipher, internal state space should be at least as big as the
269 * number of possible keys to be considered strong. The state associated with
270 * the permutation vector alone (256!) constitutes overkill.
271 * </p>
272 *
273 *
274 * <h2>PREDICTABILITY OF THE STATE</h2>
275 *
276 * <p>
277 * If you have a history of stream output from initialization (or equivalently,
278 * previous known plaintext and ciphertext), then rotor, last_plain, and
279 * last_cipher are known to an attacker. The other two index values, flipper and
280 * avalanche, cannot be solved for without knowing the contents of parts of the
281 * permutation vector that change with each byte encrypted. Solving for the
282 * contents of the permutation vector by keeping track of the possible positions
283 * of the index variables and possible contents of the permutation vector at
284 * each byte position is not possible, since more variables than known values
285 * are generated at each iteration. Indeed, fewer index variables and swaps
286 * could be used to achieve security, here, if it were not for the hash
287 * requirements.
288 * </p>
289 *
290 *
291 * <h2>CRYPTOGRAPHIC CHECK VALUE</h2>
292 *
293 * <p>
294 * The change in state altered with each byte encrypted contributes to an
295 * avalanche of generated check values that is radically different after a
296 * sequence of at least 64 bytes have been encrypted. The suggested way to
297 * create a cryptographic check value is to encrypt all of the bytes of a
298 * message, then encrypt a sequence of bytes counting down from 255 to 0. A
299 * single bit change in a message causes a radical change in the check value
300 * generated (about half of the bits change). This is an essential feature of a
301 * cryptographic check value.
302 * </p>
303 *
304 * <p>
305 * Another good property of a cryptographic check value is that it is too hard
306 * to compute a message that results in a certain check value. In this case, we
307 * assume the attacker knows the key and the contents of a message that has the
308 * desired check value, and wants to compute a bogus message having the same
309 * check value. There are two obvious ways to do this attack. One is to solve
310 * for a sequence that will restore the state of the permutation vector and
311 * indices back to what it was before the alteration. The other one is the
312 * so-called "birthday" attack that is to cryptographic hash functions what
313 * brute force is to key search.
314 * </p>
315 *
316 * <p>
317 * To generate a sequence that restores the state of the cipher to what it was
318 * before the alteration probably requires at least 256 bytes, since the index
319 * "rotor" marches steadily on its cycle, one by one. The values to do this
320 * cannot easily be computed, due to the nonlinearity of the feedback, so there
321 * would probably have to be lots of trial and error involved. In practical
322 * applications, this would leave a gaping block of binary garbage in the middle
323 * of a document, and would be quite obvious, so this is not a practical attack,
324 * even if you could figure out how to do it (and I haven't). If anyone has a
325 * method to solve for such a block of data, though, I would be most interested
326 * in finding out what it is. Please email me at
327 * <m.p.johnson@ieee.org> if you find one.
328 * </p>
329 *
330 * <p>
331 * The "birthday" attack just uses the birthday paradox to find a message that
332 * has the same check value. With a 20 byte check value, you would have to find
333 * at least 80 bits to change in the text such that they wouldn't be noticed (a
334 * plausible situation), then try the combinations until one matches. 2 to the
335 * 80th power is a big number, so this isn't practical either. If this number
336 * isn't big enough, you are free to generate a longer check value with this
337 * algorithm. Someone who likes 16 byte keys might prefer 32 byte check values
338 * for similar stringth.
339 * </p>
340 *
341 *
342 * <h2>ADAPTIVE CHOSEN PLAIN TEXT ATTACKS</h2>
343 *
344 * <p>
345 * Let us give the attacker a keyed black box that accepts any input and
346 * provides the corresponding output. Let us also provide a signal to the black
347 * box that causes it to reoriginate (revert to its initial keyed state) at the
348 * attacker's will. Let us also be really generous and provide a free copy of
349 * the black box, identical in all respects except that the key is not provided
350 * and it is not locked, so the array can be manipulated directly.
351 * </p>
352 *
353 * <p>
354 * Since each byte encrypted only modifies at most 5 of the 256 bytes in the
355 * permutation vector, and it is possible to find different sequences of two
356 * bytes that leave the five index variables the same, it is possible for the
357 * attacker to find sets of chosen plain texts that differ in two bytes, but
358 * which have cipher texts that are the same for several of the subsequent
359 * bytes. Modeling indicates that as many as ten of the following bytes
360 * (although not necessarily the next ten bytes) might match. This information
361 * would be useful in determining the structure of the Sapphire Stream Cipher
362 * based on a captured, keyed black box. This means that it would not be a good
363 * substitute for the Skipjack algorithm in the EES, but we assume that the
364 * attacker already knows the algorithm, anyway. This departure from the
365 * statistics expected from an ideal stream cipher with feedback doesn't seem to
366 * be useful for determining any key bytes or permutation vector bytes, but it
367 * is the reason why post-conditioning is required when computing a
368 * cryptographic hash with the Sapphire Stream Cipher. Thanks to Bryan G.
369 * Olson's <olson@umbc.edu> continued attacks on the Sapphire Stream
370 * Cipher, I have come up with the Sapphire II Stream Cipher. Thanks again to
371 * Bryan for his valuable help.
372 * </p>
373 *
374 * <p>
375 * Bryan Olson's "differential" attack of the original Sapphire Stream Cipher
376 * relies on both of these facts:
377 * </p>
378 *
379 * <ol>
380 * <li>By continual reorigination of a black box containing a keyed version of
381 * the Sapphire Stream Cipher, it is possible to find a set of input strings
382 * that differ only in the first two (or possibly three) bytes that have
383 * identical output after the first three (or possibly four) bytes. The output
384 * suffixes so obtained will not contain the values of the permutation vector
385 * bytes that <i>differ</i> because of the different initial bytes encrypted.</li>
386 *
387 * <li>Because the five index values are initialized to constants that are known
388 * by the attacker, most of the locations of the "missing" bytes noted in the
389 * above paragraph are known to the attacker (except for those indexed by the
390 * ratchet index variable for encryptions after the first byte).</li>
391 * </ol>
392 *
393 * <p>
394 * I have not yet figured out if Bryan's attack on the original Sapphire Stream
395 * Cipher had complexity of more or less than the design strength goal of 2^64
396 * encryptions, but some conservative estimations I made showed that it could
397 * possibly come in significantly less than that. (I would probably have to
398 * develop a full practical attack to accurately estimate the complexity more
399 * accurately, and I have limited time for that). Fortunately, there is a way to
400 * frustrate this type of attack without fully developing it.
401 * </p>
402 *
403 * <p>
404 * Denial of condition 1 above by increased alteration of the state variables is
405 * too costly, at least using the methods I tried. For example, doubling the
406 * number of index variables and the number of permutation vector items
407 * referenced in the output function of the stream cipher provides only doubles
408 * the cost of getting the data in item 1, above. This is bad crypto-economics.
409 * A better way is to change the output function such that the stream cipher
410 * output byte is a combination of two permutation vector bytes instead of one.
411 * That means that all possible output values can occur in the differential
412 * sequences of item 1, above.
413 * </p>
414 *
415 * <p>
416 * Denial of condition 2 above, is simpler. By making the initial values of the
417 * five index variables dependent on the key, Bryan's differential attack is
418 * defeated, since the attacker has no idea which elements of the permutation
419 * vector were different between data sets, and exhaustive search is too
420 * expensive.
421 * </p>
422 *
423 *
424 * <h2>OTHER HOLES</h2>
425 *
426 * <p>
427 * Are there any? Take you best shot and let me know if you see any. I offer no
428 * challenge text with this algorithm, but you are free to use it without
429 * royalties to me if it is any good.
430 * </p>
431 *
432 *
433 * <h2>CURRENT STATUS</h2>
434 *
435 * <p>
436 * This is a new (to the public) cipher, and an even newer approach to
437 * cryptographic hash generation. Take your best shot at it, and please let me
438 * know if you find any weaknesses (proven or suspected) in it. Use it with
439 * caution, but it still looks like it fills a need for reasonably strong
440 * cryptography with limited resources.
441 * </p>
442 *
443 *
444 * <h2>LEGAL STUFF</h2>
445 *
446 * <p>
447 * The intention of this document is to share some research results on an
448 * informal basis. You may freely use the algorithm and code listed above as far
449 * as I'm concerned, as long as you don't sue me for anything, but there may be
450 * other restrictions that I am not aware of to your using it. The C++ code
451 * fragment above is just intended to illustrate the algorithm being discussed,
452 * and is not a complete application. I understand this document to be
453 * Constitutionally protected publication, and not a munition, but don't blame
454 * me if it explodes or has toxic side effects.
455 * </p>
456 *
457 * <pre>
458 * ___________________________________________________________
459 * | |
460 * |\ /| | | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 |
461 * | \/ |o| | PO Box 1151, Longmont CO 80502-1151 USA John 3:16-17 |
462 * | | | / _ | mpj&#064csn.org aka mpj&#064netcom.com m.p.johnson&#064ieee.org |
463 * | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 |
464 * | |||\ ( | ftp://ftp.netcom.com/pub/mp/mpj/README -. --- ----- .... |
465 * | ||| \ \_/ | PGPprint=F2 5E A1 C1 A6 CF EF 71 12 1F 91 92 6A ED AE A9 |
466 * |___________________________________________________________|
467 * </pre>
468 *
469 * Regarding this port to Java and not the original code, the following license
470 * applies:
471 *
472 * @see gnu.lgpl.License for license details.<br>
473 * The copyright to this program is held by it's authors.
474 * @author Michael Paul Johnson [ kahunapule at mpj dot cx] Original code
475 * @author unascribed Sword's C++ implementation
476 * @author DM Smith [ dmsmith555 at yahoo dot com] Java port from Sword's C++
477 * implementation
478 */
479 public class Sapphire {
480
481 /**
482 * Construct a Sapphire Stream Cipher from a key, possibly null or empty.
483 */
484 public Sapphire(byte[] aKey) {
485 byte[] key = aKey;
486 if (key == null) {
487 key = new byte[0];
488 }
489 cards = new int[256];
490 if (key.length > 0) {
491 initialize(key);
492 } else {
493 hashInit();
494 }
495 }
496
497 /**
498 * Decipher a single byte, presumably the next.
499 *
500 * @param b
501 * the next byte to decipher
502 */
503 public byte cipher(byte b) {
504 // Picture a single enigma rotor with 256 positions, rewired
505 // on the fly by card-shuffling.
506
507 // This cipher is a variant of one invented and written
508 // by Michael Paul Johnson in November, 1993.
509
510 // Shuffle the deck a little more.
511
512 // Convert from a byte to an int, but prevent sign extension.
513 // So -16 becomes 240
514 int bVal = b & 0xFF;
515 ratchet += cards[rotor++];
516 // Keep ratchet and rotor in the range of 0-255
517 // The C++ code relied upon overflow of an unsigned char
518 ratchet &= 0xFF;
519 rotor &= 0xFF;
520 int swaptemp = cards[lastCipher];
521 cards[lastCipher] = cards[ratchet];
522 cards[ratchet] = cards[lastPlain];
523 cards[lastPlain] = cards[rotor];
524 cards[rotor] = swaptemp;
525 avalanche += cards[swaptemp];
526 // Keep avalanche in the range of 0-255
527 avalanche &= 0xFF;
528
529 // Output one byte from the state in such a way as to make it
530 // very hard to figure out which one you are looking at.
531 lastPlain = bVal ^ cards[(cards[ratchet] + cards[rotor]) & 0xFF] ^ cards[cards[(cards[lastPlain] + cards[lastCipher] + cards[avalanche]) & 0xFF]];
532
533 lastCipher = bVal;
534
535 // Convert back to a byte
536 // E.g. 240 becomes -16
537 return (byte) lastPlain;
538 }
539
540 public void burn() {
541 // Destroy the key and state information in RAM.
542 for (int i = 0; i < 256; i++) {
543 cards[i] = 0;
544 }
545 rotor = 0;
546 ratchet = 0;
547 avalanche = 0;
548 lastPlain = 0;
549 lastCipher = 0;
550 }
551
552 /**
553 * @param hash
554 */
555 public void hashFinal(byte[] hash) { // Destination
556 for (int i = 255; i >= 0; i--) {
557 cipher((byte) i);
558 }
559 for (int i = 0; i < hash.length; i++) {
560 hash[i] = cipher((byte) 0);
561 }
562 }
563
564 /**
565 * Initializes the cards array to be deterministically random based upon the
566 * key.
567 * <p>
568 * Key size may be up to 256 bytes. Pass phrases may be used directly, with
569 * longer length compensating for the low entropy expected in such keys.
570 * Alternatively, shorter keys hashed from a pass phrase or generated
571 * randomly may be used. For random keys, lengths of from 4 to 16 bytes are
572 * recommended, depending on how secure you want this to be.
573 * </p>
574 *
575 * @param key
576 * used to initialize the cipher engine.
577 */
578 private void initialize(byte[] key) {
579
580 // Start with cards all in order, one of each.
581 for (int i = 0; i < 256; i++) {
582 cards[i] = i;
583 }
584
585 // Swap the card at each position with some other card.
586 int swaptemp;
587 int toswap = 0;
588 keypos = 0; // Start with first byte of user key.
589 rsum = 0;
590 for (int i = 255; i >= 0; i--) {
591 toswap = keyrand(i, key);
592 swaptemp = cards[i];
593 cards[i] = cards[toswap];
594 cards[toswap] = swaptemp;
595 }
596
597 // Initialize the indices and data dependencies.
598 // Indices are set to different values instead of all 0
599 // to reduce what is known about the state of the cards
600 // when the first byte is emitted.
601 rotor = cards[1];
602 ratchet = cards[3];
603 avalanche = cards[5];
604 lastPlain = cards[7];
605 lastCipher = cards[rsum];
606
607 // ensure that these have no useful values to those that snoop
608 toswap = 0;
609 swaptemp = toswap;
610 rsum = swaptemp;
611 keypos = rsum;
612 }
613
614 /**
615 * Initialize non-keyed hash computation.
616 */
617 private void hashInit() {
618
619 // Initialize the indices and data dependencies.
620 rotor = 1;
621 ratchet = 3;
622 avalanche = 5;
623 lastPlain = 7;
624 lastCipher = 11;
625
626 // Start with cards all in inverse order.
627
628 int j = 255;
629 for (int i = 0; i < 256; i++) {
630 cards[i] = j--;
631 }
632 }
633
634 private int keyrand(int limit, byte[] key) {
635 int u; // Value from 0 to limit to return.
636
637 if (limit == 0) {
638 return 0; // Avoid divide by zero error.
639 }
640
641 int retry_limiter = 0; // No infinite loops allowed.
642
643 // Fill mask with enough bits to cover the desired range.
644 int mask = 1;
645 while (mask < limit) {
646 mask = (mask << 1) + 1;
647 }
648
649 do {
650 // Convert a byte from the key to an int, but prevent sign
651 // extension.
652 // So -16 becomes 240
653 // Also keep rsum in the range of 0-255
654 // The C++ code relied upon overflow of an unsigned char
655 rsum = (cards[rsum] + (key[keypos++] & 0xFF)) & 0xFF;
656
657 if (keypos >= key.length) {
658 keypos = 0; // Recycle the user key.
659 rsum += key.length; // key "aaaa" != key "aaaaaaaa"
660 rsum &= 0xFF;
661 }
662
663 u = mask & rsum;
664
665 if (++retry_limiter > 11) {
666 u %= limit; // Prevent very rare long loops.
667 }
668 } while (u > limit);
669 return u;
670 }
671
672 private int[] cards;
673 private int rotor;
674 private int ratchet;
675 private int avalanche;
676 private int lastPlain;
677 private int lastCipher;
678 private int keypos;
679 private int rsum;
680 }
681