Re: [Cfrg] Crystalline Cipher

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

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

--- Ursprüngliche Nachricht ---
Von: Michael Hamburg <[e-mail]>
Datum: 21.05.2015 19:41:32
An: Mark McCarron <[e-mail]>
Betreff: Re: [Cfrg] Crystalline Cipher

Hi Mark,

 

Is your goal in this to prove that you’re right?  Or is your goal to become right?

 

If you want to learn from me or from this list, I’m willing to discuss your cipher point by point.  But if all you care about is proving that your cipher is already good, then you’ll ignore me and there’s nothing to be gained for anyone.

 

What I will not do is write a ciphertext-only attack against Crystalline.  I honestly don’t know if I could do this on your terms (eg, completely recovering an unknown compressed file with a key used only once).  But even if I could, this sort of attack is a monster and a half to write against any cipher, almost no matter how terrible.  It usually takes weeks or months, and it’s usually not very interesting.  I won’t do it for free, and I won’t do it if paid because I’m already paid to do more interesting and productive things.  Only NSA and their counterparts do this regularly, because it’s only worth doing if you actually want to spy on someone.

 

If you want to start a productive dialog, let’s start from the beginning.  What is your cipher supposed to do?  How should I use it?  What does it mean for it to be secure or broken?  How big of a key should I use?  What does the salt do, and how big does it need to be?  What does the IV do, and how do I need to choose it?  How many messages can I encrypt with the same key, salt and IV?  How big should they be?

 

If I don’t know what your code is supposed to do, I cannot evaluate how well it does that.

 

— Mike

 

 

On May 21, 2015, at 9:37 AM, Mark McCarron <[e-mail]> wrote:

Mike,

There are people on the list evaluating the cipher.  I also fail to understand your obsession with silencing discussion of Crystalline.  As I said earlier, if you do not wish to take part, then don't.  No one is forcing you to reply, or even read anything in this series of emails.  You keep talking in general terms like 'we cryptographers want to build things on our ciphers', who exactly is 'we' and who appointed you a spokesman?  

I have watched as you ignored discussion of the specific mechanisms of Crystalline, and how you focus on shifting the discussion to irrelevent matters.  Mostly flame bait if I am being honest.  Its more political than scientific, certainly not the actions of a genuine researcher.  Given the NSA's role on this list, its not too much of a stretch of the imagination to suggest that this is your function here.  But I may be wrong, who knows?  When it comes down to it, I don't even care.

Unless you have something to genuinely add to the discussion, this will be the last time I address you directly.

Regards,

Mark McCarron  

--- original message ---
From: Mike Hamburg <[e-mail]>
Date: 21.05.2015 16:54:47
To: Mark McCarron <[e-mail]>, [e-mail]
Subject: Re: [Cfrg] Crystalline Cipher

I agree that this was a waste of time.  I'm not learning anything from this discussion, and apparently neither are you.  I don't think anyone else on this list is learning anything either.  So maybe it's best to just end things here.

-- Mike

On 05/20/2015 11:51 PM, Mark McCarron wrote:

Mike,

I see a lot of talking and not a lot of doing.  If you think this can be used to recover the plaintext, then I am sure you can provide a worked example.  But I can tell you now that you are wasting your time.

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---
Von: Mike Hamburg <[e-mail]>
Datum: 21.05.2015 08:43:33
An: Mark McCarron <[e-mail]>, Tony Arcieri <[e-mail]>
Betreff: Re: [Cfrg] Crystalline Cipher

But you see Mark, he did break it.

This is why I wrote to you (off-list) about why cryptographers don't like this sort of interaction, and why I tried to brush you off originally.  We'll spend some effort and break your code, but you won't agree that it's broken and nobody will be happy.  It's just a waste of time all around.

We cryptographers want to build things on our ciphers, not just use them to send compressed files around.  To do that with confidence, the ciphers must be a firm foundation, not something that itself needs to be protected by compression or whatever your next excuse will be.  If you need to protect the cipher in this way, it is already broken.

-- Mike

On 5/20/2015 11:36 PM, Mark McCarron wrote:

Hi Tony,

I have examined this issue in depth.  The repeated pattern that you pointed out does not lead to a break in the cipher.  That image is drawn from a file filled with 0x00 which is a junk test in the context of Crystalline.  Due to the way in which Crystalline encrypts, such patterns are unobservable in files that contain data.  Further, that pattern is the result of using a limited set of colours to represent the entire range of values.  When you examine the byte stream, it is chaotic and the salt/key/plaintext are mathematically unrecoverable.  Basically, what you are seeing is a bias introduced by long runs of the same initial value.  It is easily resolved through the use of compression as can be seen in this image:

http://i.imgur.com/3DLWNTc.jpg" rel="nofollow">http://i.imgur.com/3DLWNTc.jpg

So, its a bit of a red herring in any practical sense.  Try to use it to break the cipher, it doesn't work.

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---
Von: Tony Arcieri <[e-mail]>
Datum: 21.05.2015 02:34:45
An: Mark McCarron <[e-mail]>
Betreff: Re: [Cfrg] Crystalline Cipher

On Wed, May 20, 2015 at 3:59 PM, Mark McCarron <[e-mail]> wrote:

I'm somewhat disappointed in your reply, as I presumed that someone with a stated interest in ciphers would be eager to investigate anything new to pop up that didn't have obvious holes in it.

 

Hi Mark,

 

I did investigate your scheme, and I'm afraid to say it's obviously broken. It appears to be an implementation of a Knuth Shuffle with a few added bells and whistles.

 

This image, which I believe you produced, shows repeated patterns in the ciphertext:

 

https://i.imgur.com/MWmMc0J.png" target="_blank" rel="nofollow">https://i.imgur.com/MWmMc0J.png

 

Likewise, there are severe failures on Chi Squared tests:

 

http://www.freecx.co.uk/cryptanalysis/Crystalline/" rel="nofollow">http://www.freecx.co.uk/cryptanalysis/Crystalline/

 

Specifically:

 

http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%281%29_10MB.txt" rel="nofollow">http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_(1)_10MB.txt

Overall Chi Squared value is 7474.808 (threshold 18.4753)
Overall likely non-uniform (>99%)

http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%282%29_10MB.txt" rel="nofollow">http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_(2)_10MB.txt

Overall Chi Squared value is 13485.34 (threshold 30.5779)
Overall likely non-uniform (>99%)

http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%284%29_10MB.txt" rel="nofollow">http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_(4)_10MB.txt

Overall Chi Squared value is 20607.94 (threshold 52.1914)
Overall likely non-uniform (>99%)

http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%288%29_10MB.txt" rel="nofollow">http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_(8)_10MB.txt

Overall Chi Squared value is 45699.52 (threshold 91.81917)
Overall likely non-uniform (>99%)

I think the biggest problem though is all of this has already been pointed out to you repeatedly in other forums and you completely refuse to acknowledge that your cipher fails to meet the absolute most minimum criteria for a secure cipher.

 

If your cipher were secure, this image would not contain obvious repeating patterns:

 

https://i.imgur.com/MWmMc0J.png" target="_blank" rel="nofollow">https://i.imgur.com/MWmMc0J.png

 

If your cipher were secure, it would pass all randomness tests.

 

There are many more requirements for a secure cipher, but your cipher fails to meet the baseline requirements.

 

-- 

Tony Arcieri

---
Free, fast and secure email: https://www.eclipso.eu

---
Free, fast and secure email: https://www.eclipso.eu 

_______________________________________________
Cfrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg" rel="nofollow">http://www.irtf.org/mailman/listinfo/cfrg

---
Free, fast and secure email: https://www.eclipso.eu _______________________________________________
Cfrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg" rel="nofollow">http://www.irtf.org/mailman/listinfo/cfrg

---
Free, fast and secure email: https://www.eclipso.eu" rel="nofollow">https://www.eclipso.eu