Criticism of a proposed stream cipher requested.
in [Cryptography]
|
Prev: A simple scheme of combining PRNGs
Next: Criticism of a proposed floating point (cs)prng requested.
From: Francois Grieu on 3 Jun 2010 02:45 On 03/06/2010 05:09, Keith F. Lynch wrote: > The "proposed stream cipher" is mine. Except that it's neither > "proposed" (I've been using it for years) nor a stream cipher. > Peter only explained a part of it, though I explained the whole > thing to him. > > Key distribution is a non-issue, since I only use it for backups, > not for communicating with others, as I also explained to Peter. > > The part he left out is what I call "stirring." This consists of > repeatedly reversing substrings within the plaintext. For each of the > 256 possible characters, one at a time, in order, I use that character > as a delimiter, breaking up the text into some number of substrings. > Each of those substrings I reverse in place. I do so circularly, so > that the first and last characters also get moved. For instance: > > Criticism of a proposed stream cipher requested. > > would get turned into: > > equed a opriseream phestipof red.Cr strosm cicit > > Note that this is not a fixed transposition, but depends on the > characters in it. For instance: > > This is what is called a transposition cipher. > > turns into > > sihpi dellarti t sita noic snac ahT.rehw sopsi > > but > > Is this what is called a transposition cipher? > > turns into > > dellarta noihw snac ahpit t sopsisic sI?rehti > > Note that it was rearranged in a completely different order. > > My complete system consists of: > > * Generate S, the hashed together key-defined subset of the square > roots of the first hundred primes, as many binary digits of each > as there are bits in the plaintext file. > * Hash the plaintext with S. > * "Stir" the result. > * Hash this new result with a "stirred" copy of S. > * Reverse-stir the latest result (i.e. start at the end of the > 256-character "alphabet" and work backwards). > * Hash the latest result with S. > > Please tell me if any of this is at all unclear. I'll assume that in the enumeration above, "Hash" is used where the standard terminology is Exclusive OR. I remark that if the plaintext is all-zeroes * [Hash the plaintext with S] gives S; * ["Stir" the result] and ["stirred" copy of S] are the same; * [Hash this new result with a "stirred" copy of S] is all-zeroes; * [Reverse-stir the latest result] is all-zeroes; * [Hash the latest result with S] is S; hence the ciphertext is S. This hypothesis can be easily tested and the key recovered using the linearity-based attack proposed by Paul Rubin. From an academic standpoint, this is an attack (for an ideal cipher, the ciphertext should never leak any information on the plaintext, beside its length perhaps, and even known plaintext should not reveal the key). It is not clear is the same key (thus S) is reused for different plaintexts; and if not, how the keys are chosen. This is important to an analysis. If the key is reused, it is enough for an adversary to manage to inject one short all-zeroes file in the plaintext files to recover the key and decipher all the other files. That can occur in real life (you receive a number of interesting test cases and incorporate them in your plaintext files, inclusing the rogue one). If keys are not reused, much depends on how theses keys are generated. > One feature it has is that it's the same forwards and backwards: > I don't have to specify whether I'm encrypting or decrypting. In some contexts that property is a weakness. In particular, if the adversary can inject a ciphertext as plaintext, the cipher is broken. > The plaintext is typically a compressed file of English ASCII text, > compressed using either gzip or bzip2. If that's taken into consideration, we are getting far from a simple, analysable cipher. Yes, systematically compressing the plaintext before encryption tends to increase security. > Why did I design and write my own system? Mostly just for fun. But > also because that way I know for an absolute fact that neither the > algorithm nor the program that implements it has any secret back > doors. That "no backdoor" argument also applies if you implement a simple standard cipher yourself (e.g. AES-CTR) which is probably easier to implement than yours. And standard ciphers have test vectors so that you can check that your implementation does what it is designed to do. > Nor has anyone ever worked on breaking this cipher. This does nothing to demonstrate that the cipher is secure; on the contrary. > Nor is anyone ever likely to Now that the cipher is on sci.crypt, that no longer stands :-) > unless someone *really* wants to read my files, > which seems unlikely. > > "Stirring" has some interesting mathematical properties. Yes, but it is slow (256 operations per byte of plaintext for each of the three stirring). > Some fairly > obvious series which I can generate with it (e.g. what's the maximum > repetition time as a function of string length) are *not* in the > On-Line Encyclopedia of Integer Sequences, implying that it's original > with me. Fran�ois Grieu
From: Phil Carmody on 3 Jun 2010 05:19 "Keith F. Lynch" <kfl(a)KeithLynch.net> writes: > The "proposed stream cipher" is mine. Except that it's neither > "proposed" (I've been using it for years) nor a stream cipher. > Peter only explained a part of it, though I explained the whole > thing to him. > > Key distribution is a non-issue, since I only use it for backups, > not for communicating with others, as I also explained to Peter. > > The part he left out is what I call "stirring." This consists of > repeatedly reversing substrings within the plaintext. For each of the > 256 possible characters, one at a time, in order, I use that character > as a delimiter, breaking up the text into some number of substrings. > Each of those substrings I reverse in place. I do so circularly, so > that the first and last characters also get moved. For instance: There's no cryptographic benefit to this stage. The linear algebra attack still works. > Criticism of a proposed stream cipher requested. > > would get turned into: > > equed a opriseream phestipof red.Cr strosm cicit > > Note that this is not a fixed transposition, but depends on the > characters in it. For instance: > > This is what is called a transposition cipher. > > turns into > > sihpi dellarti t sita noic snac ahT.rehw sopsi > > but > > Is this what is called a transposition cipher? > > turns into > > dellarta noihw snac ahpit t sopsisic sI?rehti > > Note that it was rearranged in a completely different order. So completely different that they don't share the substrings 'dellart' or ' snac ', and 'ta noi'? Look again. > My complete system consists of: > > * Generate S, the hashed together key-defined subset of the square > roots of the first hundred primes, as many binary digits of each > as there are bits in the plaintext file. > * Hash the plaintext with S. > * "Stir" the result. > * Hash this new result with a "stirred" copy of S. > * Reverse-stir the latest result (i.e. start at the end of the > 256-character "alphabet" and work backwards). > * Hash the latest result with S. > > Please tell me if any of this is at all unclear. Your use of the verb 'hash'. > One feature it has is that it's the same forwards and backwards: > I don't have to specify whether I'm encrypting or decrypting. > > The plaintext is typically a compressed file of English ASCII text, > compressed using either gzip or bzip2. > > Why did I design and write my own system? Mostly just for fun. But > also because that way I know for an absolute fact that neither the > algorithm nor the program that implements it has any secret back > doors. Nor has anyone ever worked on breaking this cipher. Nor is > anyone ever likely to unless someone *really* wants to read my files, > which seems unlikely. If people aren't so interested in your files, then ROT13 is almost as good, strength-wise, but vastly superior from the computational effort aspect. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Phil Carmody on 3 Jun 2010 05:27 Francois Grieu <fgrieu(a)gmail.com> writes: > On 03/06/2010 05:09, Keith F. Lynch wrote: > > The plaintext is typically a compressed file of English ASCII text, > > compressed using either gzip or bzip2. > > If that's taken into consideration, we are getting far from a simple, > analysable cipher. Yes, systematically compressing the plaintext before > encryption tends to increase security. Not when it puts known plaintext (such as header bytes) into every message. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Tom St Denis on 3 Jun 2010 06:49 On Jun 2, 11:09 pm, "Keith F. Lynch" <k...(a)KeithLynch.net> wrote: > The "proposed stream cipher" is mine. Except that it's neither > "proposed" (I've been using it for years) nor a stream cipher. > Peter only explained a part of it, though I explained the whole > thing to him. > > Key distribution is a non-issue, since I only use it for backups, > not for communicating with others, as I also explained to Peter. Question, why didn't you just use something like RC4 or AES in CTR mode? [or better yet a standard crypto tool like gpg?] Tom
From: Mike Amling on 3 Jun 2010 09:17
Keith F. Lynch wrote: > The "proposed stream cipher" is mine. Except that it's neither > "proposed" (I've been using it for years) nor a stream cipher. > Peter only explained a part of it, though I explained the whole > thing to him. > > Key distribution is a non-issue, since I only use it for backups, > not for communicating with others, as I also explained to Peter. > > The part he left out is what I call "stirring." This consists of > repeatedly reversing substrings within the plaintext. For each of the > 256 possible characters, one at a time, in order, I use that character > as a delimiter, breaking up the text into some number of substrings. > Each of those substrings I reverse in place. I do so circularly, so > that the first and last characters also get moved. For instance: > > Criticism of a proposed stream cipher requested. > > would get turned into: > > equed a opriseream phestipof red.Cr strosm cicit > > Note that this is not a fixed transposition, but depends on the > characters in it. For instance: > > This is what is called a transposition cipher. > > turns into > > sihpi dellarti t sita noic snac ahT.rehw sopsi > > but > > Is this what is called a transposition cipher? > > turns into > > dellarta noihw snac ahpit t sopsisic sI?rehti > > Note that it was rearranged in a completely different order. > > My complete system consists of: > > * Generate S, the hashed together key-defined subset of the square > roots of the first hundred primes, as many binary digits of each > as there are bits in the plaintext file. > * Hash the plaintext with S. > * "Stir" the result. > * Hash this new result with a "stirred" copy of S. > * Reverse-stir the latest result (i.e. start at the end of the > 256-character "alphabet" and work backwards). > * Hash the latest result with S. > > Please tell me if any of this is at all unclear. What is the "Hash X with S"? The output of a hash function has a fixed length, presumed shorter than most plaintexts. --Mike Amling |