Re: [Cfrg] Crystalline Cipher

[Ryan Daurne <[e-mail]>]

Hi Mark,

Let us compare: 
https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil 
and http://www.interhack.net/people/cmcurtin/snake-oil-faq.html with 
your statements:

FAQ: Beware of any vendor who claims to have invented a ``new type of 
cryptography'' or a ``revolutionary breakthrough.''
Mark: Crystalline adopts a unique (as far as I know) approach to encryption.

Schneier: Warning Sign #4: Extreme cluelessness.
Mark: the cipher appears to be information-theoretically secure
Mark: the fud that has been posted to this group in regards to what is, 
or is not, a break in a cipher.

Schneier: Warning Sign #5: Ridiculous key lengths.
Mark: The recommended minimum key/salt length is 16KB, providing an 
effective key strength of 131072 bits. The key/salt size is arbitrary 
and can be extended to Gigabytes or a continuous random stream if necessary.
Mark: In general, security should improve as the key size grows.

Schneier: Warning Sign #6: One-time pads.
Mark: In short, the final ciphertext contains no mathematical 
relationships and is impractical to attack by brute-force. This is 
effectively the same as a one-time pad.

Schneier: Warning Sign #7: Unsubstantiated claims.
Mark: When you examine the byte stream, it is chaotic and the 
salt/key/plaintext are mathematically unrecoverable.

FAQ: Be wary of anything that claims that competing algorithms or 
products are insecure without providing evidence for these claims.
Mark: I would like to understand why the list has become dedicated to 
the likes of AES and Eliptic curve cryptography. Coincidently, the same 
techniques and ciphers being pushed by the NSA. Many people, including 
myself, don't trust these techniques and feel that there is a certain 
dollar amount in hardware before weaknesses emerge.

In regards to relevance to this list, I hope that providing 
entertainment to readers to improve morale will suffice.

Regards,

Ryan Daurne

On 21/05/2015 20:34, Mark McCarron wrote:
> Hi Mike,
>
> The goal is to understand where the bodies are buried in the cipher 
> and of what practical consequence those flaws are.  I'm a 
> traditionalist when it comes to ciphers, their function is to hide a 
> message/file and ensure it can only be recovered using the key.  I 
> understand that from the perspective of logic, I must remove the 
> ability of an attacker to relate information to ensure a cipher cannot 
> be broken.  I must present an attacker with a ciphertext from which he 
> can compute nothing of value.
>
> Let's look at the information you requested.
>
> 1. What is your cipher supposed to do?
> Rearrange the contents of a file at the binary and byte level in such 
> a manner that it can only be reversed by those possessing the key.
>
> 2. How should I use it?
> In its simplist form, supply the plaintext, key, salt and IV and 
> execute the program.
>
> 3. What does it mean for it to be secure or broken?
> To be secure, there should be no means for an attacker to 
> computationally (including quantum) retrieve the plaintext, key, salt 
> or IV other than brute force.  Exceptions can be made in certain 
> 'test' scenarios such as a file filled with 0x00, as long as this can 
> be corrected by applying compression.  To be broken, partial 
> (substantially useful) or complete recovery of the plaintext, key, 
> salt and/or IV given only a randomly selected ciphertext.
>
> How big of a key should I use?
> A key that is beyond any realm of possibilty of ever being able to 
> brute force.  A key that is impractical to memorise. At a minimum, 
> 16KB with no upper limit.
>
> What does the salt do, and how big does it need to be?
> It increases the solution space and reduces attack surface of the 
> cipher.  It also serves to mask the key.  Conceptually, it can also be 
> thought of as a split key.  Crystalline, in its final form, will allow 
> unlimited keys and unlimited salts to be added to any encryption process.
>
> What does the IV do, and how do I need to choose it?
> This value is user supplied and can be selected any in manner a user 
> wishes.  Randomly would be best.  It increases the solution space and 
> reduces the attack surface of the cipher.  In the Beta 3 code (not 
> released yet, but in CodePlex), it computes values to be selected from 
> the key and salt, which are then used to compute how many iterations 
> (rounds) the cipher will perform.  Presently, this will be a value of 
> between 10 and 27 iterations (rounds) inclusive.  A further usage (yet 
> to be implemented for Beta 3) is the randomisation of the starting 
> point in the circular buffer for the plaintext, key and salt in each 
> round.  This will vastly increase the solution space and again reduce 
> the attack surface.
>
> How many messages can I encrypt with the same key, salt and IV?
> This is a complex question to answer.  As the cipher moves bits and 
> bytes, the patterns that emerge in the ciphertext are a product of 
> random noise and the bits are a product of the plaintext coupled with 
> an XOR process.  This is further complicated by the fact that the 
> process runs in a manner which causes those bit/byte swaps to 
> overlap.  Thus, disorder in the final output is highly effected by 
> initial starting conditions.  This means, in general, there is good 
> resistance against repetitive patterns even in substantially similar 
> plaintexts using the same salt, key and IV that could be used in a 
> practical break.  Whilst best practice would dictate unique keys, 
> salts and IVs for each encryption, the cipher is forgiving of mistakes 
> providing a window of safety for the user.  The absolute limit, is an 
> unknown quantity at this point but what is known is that confidence in 
> the absolute security of the ciphertexts would degrade with time if 
> keys, salts and IVs are reused.
>
> In large files, the situation is quite different.  As the encryption 
> process runs as an overlapping chain, repetition will not occur, 
> although a skewed fractal-like pattern may emerge as in the case of a 
> file filled with 0x00.  This will not, however, reveal the key, salt, 
> plaintext or IV as there are no absolute reference points from which 
> to begin analysis.  This is something that will change in the Beta 3 
> release, as it is a product of resetting the circular buffers to index 
> zero on each iteration (round).  In Beta 3, this will be random and 
> the order will vanish.
>
> Regards,
>
> Mark McCarron