Re: [Cfrg] Crystalline Cipher

["Mark McCarron" <[e-mail]>]

Hi Ryan,

Could you repeat this post?  Only this time, include a practical break in the cipher.

I will add something to Schneier's indicators:

-Beware individuals who post to mailing lists on matters of security weaknesses in new crypto software without supplying comprehensive data and examples to support their claims.  They obviously have a reason to be posting and that would imply an agenda that has not been disclosed to members of the mailing list.


Regards,

Mark McCarron
--- Ursprüngliche Nachricht ---
Von: Ryan Daurne <[e-mail]>
Datum: 21.05.2015 22:50:44
An: [e-mail]
Betreff: Re: [Cfrg] Crystalline Cipher

> 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
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>