Xorshift RNGs-based encryption scheme. Please be patient and take a

good statistical properties. The algorithm has two operating modes: standard mode and stream mode.<br><br> Standard mode seems very strong against chosen ciphertext attacks, but requires one computation of SHA1 applied to the plaintext (which must be known entirely) and produces a ciphertext that is 20 bytes longer than the plaintext. Stream mode does not alter plaintext length, has no SHA1(plaintext) computation (and thus is also a bit faster) but is weaker against chosen ciphertext attacks. Short description of standard mode encryption: .<br><br> Compute SHA1(key + SHA1(plaintext)) (where + means concatenation) . Output this value ("footprint") as first 20 bytes of ciphertext . Initialize all 648 xorshift RNG seeds by using SHA1 (see source code).<br><br> Calculated values depend on key and footprint. The entire process costs 130 SHA1 applications on 40 2byte inputs. .<br><br> For each plaintext char "pch": . Choose one of the 648 xorshift RNG. The decision is based on a value ("rng_state") that is modified at each iteration by xoring its value with sci.crypt: Xorshift RNGs 2based encryption scheme.<br><br> Please be patient and take a look!! : 2) Xorshift RNGs 2based encryption scheme. Please be patient and take a look!!<br><br> : 2)1 the seed of the RNG _preceding_ (mod 648) the chosen one. A sequential counter is also used in the decision, to eliminate eventual cycles. .<br><br> Use the chosen RNG to generate a new 32bit number (update it's state/seed) . Xor 2fold it down to 8 bits. .<br><br> Xor this value with "pch" and output it as ciphertext char. Standard mode decryption is achieved by using the same algorithm, but with the footprint directly read from the ciphertext file. Stream mode differs only in the initialization part: the first two points are absent and the 648 RNG seeds depend only on the key.<br><br> What looks good to me: 1) Changing one bit of the key (or the plaintext, in standard mode) alters the entire ciphertext with a very high probability. 2) Encryption/decryption loop is fast. 3) Ciphertext passes all of DIEHARD tests (even GORILLA, the one that a single xorshift RNG would not pass).<br><br> I've tryed it on a 640MB linux iso. 4) It's suitable for trasmission over noisy channels: altering any number of ciphertext characters does not compromise the correct decryption of the rest. (the first 20 bytes are crucial, but only in standard mode) 5) It's easy to implement and analyze (no multiple rounds, no magic s 2boxes) and compact.<br><br> Its data arrays fit easily in CPU caches. 6) Key size can be easily scaled. 7) I can't figure out how to attack it.<br><br> By looking (say) at the first ciphertext character (knowing the corresponding plain) you get a 8bit value that is a xorfold from a 32bit one. This gives you 2^24 possibilities for this value. Even knowing the right 32bit value doesn't give you a clue of _which_ RNG was used (any of them can generate that number, with the proper seed).<br><br> Without this information you can't say anything on RNG seeds. Additionally, note that the choice of which RNG to use is unrelated to the _current_ 32bit value used for encryption. It's based on a value that (a) has never been used till now or (b) has been used for encryption of one of the preceding chars, but you don't know which one.<br><br> Having the possibility of applying chosen ciphertext attacks on stream 2mode encrypted chars makes things easier: a small effort is required to obtain each plaintext char sequentially (by brute force). But such attacks should be very unlikely to happen in the majority of situations,right? Using a SHA1 value as key has the advantage of making good passwords from anything.<br><br> Also, this scheme comes into my mind: A and B wants to communicate. They agree on a start password (by using a trusted authority or by agreeing on the choice of the file to apply SHA1 on). A sends a message to B, encrypted with this first password.<br><br> B decrypts it and by applying SHA1 on it finds the password to encrypt its response to A. A in turn does the same. Such a scheme seems better than reusing the same password until you think it is compromised, at least if attackers don't know exactly the entire contents of a message.<br><br> To my eyes, even if they can almost decrypt a message (say 10 bytes less), they can't calculate the next SHA1 by brute force. Additionally, you limit the amount of plaintext sci.crypt: Xorshift RNGs 2based encryption scheme. Please be patient and take a look!!<br><br> : 2) Xorshift RNGs 2based encryption scheme. Please be patient and take a look!! : 2)2 encoded with the same key, giving less information to an attacker.<br><br> Immediate improvements: on 64bit architectures security can be improved by using the battery of 2200 64bit xorshift RNGs, with a very small speed loss. Maybe RNG seed initialization can be speeded up without affecting security, and maybe avoinding shuffling the xorshift battery does not decrease security significantly. Here is the C code (please take a look at it!!): http://www.codewiz.org/~nevez/xse.c (also requires http://www.codewiz.org/~nevez/sha1.c to compile) It's far from perfect: it's not optimized, it's architecture dependent (only 32bit int environments).<br><br> But it allows anyone interested to try it... I've compiled it under Windows with gcc, here is the executable: http://www.codewiz.org/~nevez/xse.exe PS: Don't rely on pipes under Windows...they never work! Posted from X 2Privat Free NNTP server 2 www.x 2privat.org sci.crypt: Xorshift RNGs 2based encryption scheme.<br><br> Please be patient and take a look!! : 2) Xorshift RNGs 2based encryption scheme. Please be patient and take a look!!<br><br> : 2)3

less