After implementing a novel encryption algorithm, how would one go about analyzing its security or get help from others in doing so? Preface: This question was originally asked on Theoretical Computer Science and later on Computer Science. The kind people on cstheory.SE referred me to this web site. It is being repeated here in an attempt to find a satisfying answer.



Over the years, two novel encryption techniques have come to mind and been implemented as programming libraries that could be integrated into applications. However, how to analyze their security and vulnerability characteristics has never been very clear, and their usage has been limited to mainly experimental tests. Are there tools available for automated examination of such parameters one may be interested in understanding for an encryption library? Are there bodies of people who are interested in being introduced to new encryption concepts for the purpose of executing their own personal analysis on such a process? I'm not sure where to look.

The first encryption algorithm is a mono-alphabetic simple substitution cipher. It requires two keys to operate and is designed to frustrate frequency analysis. The longer of the keys forms a table by which plain-text has a normal substitution cipher applied. Each encoded byte is then split into four values of two bits each. The second, shorter key is then used to allow a random selection from four groups of sixty-four unique bytes each. Each two bit value from the encoded byte is used to select which group of sixty-four bytes to use. Encoding has two disadvantages: the output is four times larger, and repeated data encoding may allow some frequency analysis.

The second encryption algorithm is a stream cipher like the first but internally operates on blocks of data. It utilizes two keys to operate: the first is a two-dimensional array that describes how to construct a (virtual) multidimensional grid, and the second is an initialization vector for the encoding/decoding engine. It attempts to overcome frequency analysis by encoding bytes with a window of preceding bytes (initialized from the second key). A byte with its preceding window of bytes form a multidimensional index into the aforementioned grid. Unfortunately, encoding duplicate blocks of data longer than the window size starts yielding equivalent data.
To answer your question "After implementing a novel encryption algorithm, how would one go about analyzing its security", well, the easy answer is "no, it's not secure".  The reason I can confidently give that answer is that you're a newbee, and newbee ciphers are never secure (unless they are massively overcomplicated; it doesn't sound like that's the case).  A newbee is about as likely to create a secure cipher as a blind man would be to paint a good piece of art; neither has any reference as to what works and what doesn't.

However, I assume you are looking for a more detailed answer than that.  Well, that gets tough for a newbee.  There are no automated tools that can validate an algorithm as "secure" (as secure means that no one can come up with a creative method to attack it, and automated tooling has difficulties with "creative").

So, you would need to have a human look at the cipher.  You could try to get an expert cryptographer to look at it, however (and you might find this shocking) there are no groups of expert cryptographers that are eager to attack ciphers from newbees.  And, even if you do get someone to look at it, you'll run into the next difficulty - they'll point out exactly how to break it; you'll tweak the cipher to stop that exact attack, and you'll have no idea whether tweaked cipher is any stronger than the original (except for that exact attack); indeed, the tweaked cipher could easily end up being weaker.

The alternative is to invest the time to become an expert yourself; the way to do that is to break ciphers yourself.  Yes, that's quite a commitment (becoming an expert in any subject is pretty much by definition hard work); but if you are serious about designing ciphers, that's what you have to do.  You might start with Stanford's course (note: I haven't gone through it myself); Schneier has an intro-to-cryptanalysis course here; or you might want to start by attacking your own ciphers.

The last isn't as silly as it sounds; here's a few suggestions:


Can you attack a 'reduced strength' version (say, with a reduced 'byte size')?
Suppose that the attacker can encrypt messages of his choosing (which is actually a standard cryptographic assumption)?  How can he use that?  For example, for your first method, suppose he asks for the encryption of thousands of repetitions of the same character?  What can he deduce from the ciphertext?
Once you can figure out how to break it with chosen plaintext, how can he attack it if he knows some of the plaintext (but obviously not all)?  How can he attack it if he doesn't know any of the plaintext, but he does know that it is, say, English-ASCII?


To give you a target, I suspect that against your first method, I could decrypt the encryption of perhaps a 10k English-ASCII message, or a 200 byte English-UCS-2 message.  And, no, I won't tell you how; that's for you to discover (hint: why do I need so much less text with UCS-2?)