Subject: [Cfrg] Crystalline Cipher

From: "Mark McCarron" <[email-masked]>
Date: Wed, 20 May 2015 21:28:25 +0200

Hi everyone,
 
Sorry for submitting this again, but I just noticed that the HTML version I posted earlier was scrubbed by the mailman software and no one could read it unless they went to the archive.

I have recently released a symmetric cipher called Crystalline and I am seeking individuals/groups to analyse algorithm.  On paper, the cipher appears to be information-theoretically secure but this requires independent validation.  Crystalline has been published at CodePlex under the MIT license at the following URL: 
 
http://crystalline.codeplex.com/ 
 
The reference implementation is in C# and I am presently adding minor changes.  The software has been up for about a week and, so far, has survived against various crackers and I thought it was time to present it to a much deeper series of tests by more knowledgeable people.  I have put together an RStudio project that has functions to analyse the cipher (also released under MIT license) that I hope everyone will find useful.  I am trying to keep this project agnostic to the cipher being analysed and I would be happy to include any R code that anyone develops. 
 
The RStudio project can be downloaded here: 
http://s000.tinyupload.com/index.php?file_id=3D37851913919266496129 
 
Crystalline adopts a unique (as far as I know) approach to encryption.  Rather than apply complex formulas to plaintext, Crystalline moves the location of bits and bytes based upon values from a TRNG (such as atmospheric noise).  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. 
 
In each round, Crystalline first swaps every bit in the file based upon values drawn from the key and salt. Before a bit is swapped, it is XOR'ed with the bit value 1. Then Crystalline erases that history by swapping every byte in the file, based upon values, drawn from the key and salt. 

Steps in a round: 

Part A: 

1. Load the plaintext, key and salt files into memory (circular buffer for each). 
2. Calculate the location of the bits to switch based on the formula 'key*salt' (where both the key and salt are represented as integer values of a byte in the range 0-255) 
3. Select the current bit index in the plaintext and XOR it with the value 1 
4. Swap the bit with the bit identified in step 2 whilst alternating the direction of that swap
5. Increment the index in the plaintext, key and salt (looping around the buffer necessary) 
6. Repeat steps 2-5 inclusive until EOF (plaintext) 
 
Part B: 

1. Set indexes of the plaintext, key and salt to 0 
2. Calculate the location of the bytes to switch based on the formula 'key*salt' (where both the key and salt are represented as integer values of a byte in the range 0-255) 
3. Swap the byte with the byte identified in step 2 whilst alternating the direction of that swap
4. Increment the index in the plaintex, key and salt (looping around the buffer necessary) 
5. Repeats steps 2-4 inclusive until EOF (plaintext) 
 
http://crystalline.codeplex.com/documentation 
 
It is recommended that the plaintext be compressed first, but Crystalline does not specify which compression algorithm should be used. 
 
Over the last week myself and numerous other people have been both attacking the cipher and analysing its output.  The main place for this discussion has been here: 
 
http://forums.devshed.com/security-cryptography-17/crystalline-cipher-testers-required-969138.html 
 
We have been particularly focused on examining FFT outputs of the ciphertext and the RStudio code allows us to produce some nice images of the FFTs as grey scaled height maps to spot patterns.  The following link is an example of such an image drawn from the encryption of a 13.5MB file using Crystalline (quite a large image): 
 
http://i.imgur.com/kQxmf5z.jpg 
 
There is also a pseudo-colorised version of this image here showing the distribution of values in a linear gradient (Red = 0, Orange = 128, Green = 255)
 
https://static.dyp.im/C0PYsjmj6t/755c391c9347eaf1a563abf4bf0f045a.png 
 
I hope everyone will download a copy and give it a test.  If anyone has questions, comments, suggestions or notices any errors then feel free to post to the group and I will respond as best I can. 
 
Regards,
 
Mark McCarron

---

From: Michael Hamburg <[email-masked]>
Date: Wed, 20 May 2015 14:29:15 -0700

Hi Mark,

I read the thing you posted earlier, and I didn’t go to the archive.

That said, CFRG really isn’t the right forum for new symmetric ciphers, or even new modes for existing symmetric ciphers.  We want crypto that’s proven more than “nobody hacked me for a week”, and that proving needs to happen elsewhere.

You might have better reception elsewhere, but I somewhat doubt it.  Your use of phrases like “information-theoretically secure”, “key strength of 131072 bits” and “unique … approach to encryption”, not to mention your key-dependent indexing, suggest that you don’t know what’s considered valuable in a cipher.  Nobody will want to study your design if you can’t properly explain what’s good about it.

If you want to discuss this more, please respond to me off-list, because I don’t think the rest of the crowd will be interested.

— Mike

> On May 20, 2015, at 12:28 PM, Mark McCarron <[email-masked]> wrote:
> 
> Hi everyone,
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 00:59:20 +0200

Hi Mike,

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.  It almost sounds like you have had your soul crushed by bureaucracy over the years and have lost all passion for this field.  I hope that's not true.  

Your reply seems somewhat at odds with the clear message provided on the home page of the CFRG:

"The CFRG serves as a bridge between theory and practice, bringing new cryptographic techniques to the Internet community.."
"...and to offer guidance on the use of emerging mechanisms and new uses of existing mechanisms..."

Crystalline is new and emerging, I'm sure a lot of people will be interested in toying around with it.  If anything, I'm sure it beats Suduko for an afternoon.  The cipher is quite strong and, to be honest, it doesn't take a whole lot to prove that.  Its not like the algorithm is convoluted in anyway.

A valuable cipher is a rather subjective thing.  For some, it will be speed, for others it will be practical key exchanges.  To me, its just about something I did, that no one else can undo.  Many would see that as being extremely valuable as well.

So, why not play about with the code?  Try to break it, find its weaknesses, its only a matter of time before it is in wide-spread usage and I'm sure being an expert on proper implementations is something that will always come in useful.

If, for some reason, you would prefer not to then let others decide for themselves and not derail conversations.  I respect your right to have your opinions and to express them, but I'm not here to debate the terminology I use.  I'm here to do some real work on the cipher and cryptanalysis.

Regards,

Mark McCarron

--- original message ---
From: Michael Hamburg <[email-masked]>
Date: 20.05.2015 23:29:15
To: Mark McCarron <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

> That said, CFRG really isn’t the right forum for new symmetric ciphers, or
> even new modes for existing symmetric ciphers.  We want crypto that’s proven
> more than “nobody hacked me for a week”, and that proving needs to happen
> elsewhere.
> 
> You might have better reception elsewhere, but I somewhat doubt it.  Your
> use of phrases like “information-theoretically secure”, “key strength of
> 131072 bits” and “unique … approach to encryption”, not to mention your key-dependent
> indexing, suggest that you don’t know what’s considered valuable in a cipher.
>  Nobody will want to study your design if you can’t properly explain what’s
> good about it.
> 
> If you want to discuss this more, please respond to me off-list, because
> I don’t think the rest of the crowd will be interested.
> 
> — Mike
> 
> > Sorry for submitting this again, but I just noticed that the HTML version
> I posted earlier was scrubbed by the mailman software and no one could read
> it unless they went to the archive.
> > 
> > I have recently released a symmetric cipher called Crystalline and I
> am seeking individuals/groups to analyse algorithm.  On paper, the cipher
> appears to be information-theoretically secure but this requires independent
> validation.  Crystalline has been published at CodePlex under the MIT license
> at the following URL: 
> > 
> > The reference implementation is in C# and I am presently adding minor
> changes.  The software has been up for about a week and, so far, has survived
> against various crackers and I thought it was time to present it to a much
> deeper series of tests by more knowledgeable people.  I have put together
> an RStudio project that has functions to analyse the cipher (also released
> under MIT license) that I hope everyone will find useful.  I am trying to
> keep this project agnostic to the cipher being analysed and I would be happy
> to include any R code that anyone develops. 
> > 
> > Crystalline adopts a unique (as far as I know) approach to encryption.
>  Rather than apply complex formulas to plaintext, Crystalline moves the location
> of bits and bytes based upon values from a TRNG (such as atmospheric noise).
>  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. 
> > 
> > In each round, Crystalline first swaps every bit in the file based upon
> values drawn from the key and salt. Before a bit is swapped, it is XOR'ed
> with the bit value 1. Then Crystalline erases that history by swapping every
> byte in the file, based upon values, drawn from the key and salt. 
> > 
> > Steps in a round: 
> > 
> > Part A: 
> > 
> > 2. Calculate the location of the bits to switch based on the formula
> 'key*salt' (where both the key and salt are represented as integer values
> of a byte in the range 0-255) 
> > 2. Calculate the location of the bytes to switch based on the formula
> 'key*salt' (where both the key and salt are represented as integer values
> of a byte in the range 0-255) 
> > It is recommended that the plaintext be compressed first, but Crystalline
> does not specify which compression algorithm should be used. 
> > 
> > Over the last week myself and numerous other people have been both attacking
> the cipher and analysing its output.  The main place for this discussion
> has been here: 
> > 
> > We have been particularly focused on examining FFT outputs of the ciphertext
> and the RStudio code allows us to produce some nice images of the FFTs as
> grey scaled height maps to spot patterns.  The following link is an example
> of such an image drawn from the encryption of a 13.5MB file using Crystalline
> (quite a large image): 
> > 
> > There is also a pseudo-colorised version of this image here showing
> the distribution of values in a linear gradient (Red = 0, Orange = 128, Green
> = 255)
> > 
> > I hope everyone will download a copy and give it a test.  If anyone
> has questions, comments, suggestions or notices any errors then feel free
> to post to the group and I will respond as best I can. 
> > 
> > Regards,
> > 
> > Mark McCarron
> > 
> >

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 May 2015 23:06:01 +0000

The web-page you posted says it is "designed to be as secure as a one-time pad."

This statement cannot possibly be true, and therefore everything else you say about it is now treated with great skepticism.  Pointing to a website as a recommended source of random bytes adds to the lack of credibility.

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 01:22:44 +0200

Hi Rich,

The cipher uses random noise to move bits/bytes whilst XORing the values.  This results in a chain-like encryption process that overlaps with itself as it moves through the file.  This approach is repeated across the plaintext between 10 and 27 times.  Each repetition (round), completely erases the history of the previous round of movements.  By the end of the process the information left in the ciphertext is from the last round of movements, which is based upon random values drawn from a TRNG.

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.

The claims are not drawn from thin air, they are accurate statements of the process.  Please download a copy, step through the algorithm and tell me if you come to a different conclusion.  I would be extremely interested in any data that suggests otherwise.

Regards,

Mark McCarron

--- original message ---
From: "Salz, Rich" <[email-masked]>
Date: 21.05.2015 01:06:01
To: Mark McCarron <[email-masked]>
Subject: RE: [Cfrg] Crystalline Cipher

> This statement cannot possibly be true, and therefore everything else you
> say about it is now treated with great skepticism.  Pointing to a website
> as a recommended source of random bytes adds to the lack of credibility.
> 
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 May 2015 18:55:00 -0500

On Thu, May 21, 2015 at 01:22:44AM +0200, Mark McCarron wrote:
> The cipher uses random noise to move bits/bytes whilst XORing the
> [...]

If they are random then you have to send them (and they won't compress).

So now you have two problems: how to encrypt data, and how to encrypt
the one-time pad (so you can send it, so the recipient can use it to
decrypt the plaintext).

Not to mention the lack of integrity protection.

> The claims are not drawn from thin air, they are accurate statements
> of the process.  [...]

Your claims show lack of experience.

One-time pads are perfect if never reused and if you hand-wave away the
problem of how to securely distribute the pads in the first place.

But it's difficult to ensure that pads are never reused.

And it's difficult to securely exchange/distribute one-time pads.

In short, one-time pads are not practical.

(Stream ciphers generate a pad for XORing, but by using small keys to
generate the pad, their key management problems are reduced to the same
sort of problem as for block ciphers.)

Nico
--

---

From: Paul Lambert <[email-masked]>
Date: Wed, 20 May 2015 23:57:35 +0000

See Schneier on the topic ...
	https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign

Paul

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 02:11:20 +0200

Hi Nico,

Key distribution is an issue with symmetric ciphers in general, not just Crystalline.  I feel this is outside the scope of the discussion and does not pertain to the strength of the cipher itself or its methodologies.  I will say one thing though, Crystalline does not make use of one-time pads that are the length of the plaintext.  They can be much smaller, the reference implementation is using 16KB files but they can be any size you want.  Reuse is not really an issue because the ciphertext lacks any references from which to make comparisons.  That is, reusing the same key/salt in a different plaintext will not generate the same ciphertext or similar detectable patterns in the output.

Try it.  I have an RStudio project linked at CodePlex which has functions that can project the byte stream to an image.  Below I have linked images of just such a scenario.  These two files have been encrypted with the same salt/key.  Crystalline does not share the same weakness as a one-time pad:

File A 

Byte Position - Grey scale version
http://i.imgur.com/EH99nr8.jpg

Byte Position - Colourised version
http://i.imgur.com/3DLWNTc.jpg

File B

Byte Position - Grey scale version
http://i.imgur.com/MWmMc0J.png

Byte Position - Colourised Version
http://i.imgur.com/SQWkbfW.png

Regards,

Mark McCarron

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 02:32:55 +0200

I think I need to add a little to this to make the statement more accurate.  Because Crystalline operates in a chain, the ciphertext is highly sensitive to initial starting conditions.  If plaintexts are substantially similar, then it is recommended to randomly set the iv value (Beta 3 functionality) and track values to ensure different output.  In practice, this means that keys/salts can be reused as long as the implementation is correct.  If the plaintexts are substantially different, as in the case of the previous examples (a zeroed file and an mp4 file), then you have wider margin of safety.

I should also point out that this may not be the final iteration of the algorithm.  I am considering making the starting points of the circular buffers random, rather than reset to zero on each round, just to make life a little more difficult.  These settings would be drawn from the IV, which selects values from the salt/key.  This will make key/salt reuse much safer, so I think it will happen.

Regards,

Mark McCarron

--- original message ---
From: "Mark McCarron" <[email-masked]>
Date: 21.05.2015 02:11:20
To: "Nico Williams" <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

> Hi Nico,
> 
> Key distribution is an issue with symmetric ciphers in general, not just
> Crystalline.  I feel this is outside the scope of the discussion and does
> not pertain to the strength of the cipher itself or its methodologies.  I
> will say one thing though, Crystalline does not make use of one-time pads
> that are the length of the plaintext.  They can be much smaller, the reference
> implementation is using 16KB files but they can be any size you want.  Reuse
> is not really an issue because the ciphertext lacks any references from which
> to make comparisons.  That is, reusing the same key/salt in a different plaintext
> will not generate the same ciphertext or similar detectable patterns in the
> output.
> 
> Try it.  I have an RStudio project linked at CodePlex which has functions
> that can project the byte stream to an image.  Below I have linked images
> of just such a scenario.  These two files have been encrypted with the same
> salt/key.  Crystalline does not share the same weakness as a one-time pad:
> 
> 
> 
> File A 
>

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 20 May 2015 17:34:45 -0700

On Wed, May 20, 2015 at 3:59 PM, Mark McCarron <[email-masked]>
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

Likewise, there are severe failures on Chi Squared tests:

http://www.freecx.co.uk/cryptanalysis/Crystalline/

Specifically:

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_(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_(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_(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

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 21 May 2015 01:00:09 +0000

Did you study how security of your design varies with the key size?

Also, some of us haven't heard of RStudio, and don't care to program in C#.

----- Original Message -----
From: Mark McCarron [mailto:[email-masked]]
Sent: Wednesday, May 20, 2015 08:11 PM
To: Nico Williams <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

Hi Nico,

File A 

File B

Regards,

Mark McCarron

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 08:36:32 +0200

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:

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 <[email-masked]>
Datum: 21.05.2015 02:34:45
An: Mark McCarron <[email-masked]>
Betreff: Re: [Cfrg] Crystalline Cipher

On Wed, May 20, 2015 at 3:59 PM, Mark McCarron <[email-masked]> 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:

Specifically:

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:

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

---

From: Mike Hamburg <[email-masked]>
Date: Wed, 20 May 2015 23:43:33 -0700

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:
>
>     *Von:* Tony Arcieri <[email-masked]>
>     *Datum:* 21.05.2015 02:34:45
>     *An:* Mark McCarron <[email-masked]>
>     *Betreff:* Re: [Cfrg] Crystalline Cipher
>
>     On Wed, May 20, 2015 at 3:59 PM, Mark McCarron
>     <[email-masked] <mailto:[email-masked]>> 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.
>     <http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%281%29_10MB.txt>
>
>     <http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%282%29_10MB.txt>
>
>     <http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%284%29_10MB.txt>
>
>     <http://www.freecx.co.uk/cryptanalysis/Crystalline/bias-result_%288%29_10MB.txt>
>
>     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.
>     There are many more requirements for a secure cipher, but your
>     cipher fails to meet the baseline requirements.
>     -- 
>     Tony Arcieri
>
>
> ---

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 08:45:08 +0200

Hi Uri,

I am still in the analysis stage and I haven't, as yet, determined absolute values for key size.  In general, security should improve as the key size grows.

RStudio is an IDE for the R language, a statistical computing language.  It is similar to Mathematica or Matlab, but open-source and free.

http://en.wikipedia.org/wiki/R_%28programming_language%29

It can be downloaded here:
http://www.rstudio.com/

If you have used Matlab or Mathematica, it won't take long to learn the semantics.  It is quite useful in cryptanalysis and can be run in a distributed computing environment.

Regards,

Mark McCarron

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 08:51:45 +0200

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 <[email-masked]>
Datum: 21.05.2015 08:43:33
An: Mark McCarron <[email-masked]>, Tony Arcieri <[email-masked]>
Betreff: Re: [Cfrg] Crystalline Cipher

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

Hi Tony,

Regards,

Mark McCarron

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

Hi Mark,

Specifically:

--

Tony Arcieri

---

---

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 21 May 2015 07:54:47 -0700

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
>
>     *Von:* Mike Hamburg <[email-masked]>
>     *Datum:* 21.05.2015 08:43:33
>     *An:* Mark McCarron <[email-masked]>, Tony Arcieri
>     <[email-masked]>
>     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
>
>         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:
>
>         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
>
>             <[email-masked]
>             <mailto:[email-masked]>> 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,
>             obviously broken. It appears to be an implementation of a
>             Knuth Shuffle with a few added bells and whistles.
>             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.
>             There are many more requirements for a secure cipher, but
>             your cipher fails to meet the baseline requirements.
>             -- 
>             Tony Arcieri
>
>
>         ---

---

From: "Paterson, Kenny" <[email-masked]>
Date: Thu, 21 May 2015 15:03:03 +0000

Please do desist.

Mark: I can expand on the reasons why offline if you wish.

Regards,

Kenny (for the chairs)

Sent from my iPhone

On 21 May 2015, at 15:55, Mike Hamburg <[email-masked]<mailto:[email-masked]>> wrote:

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

Regards,

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

-- Mike

Regards,

Mark McCarron

--- Urspr?ngliche Nachricht ---
Von: Tony Arcieri <[email-masked]><mailto:[email-masked]>
Datum: 21.05.2015 02:34:45
An: Mark McCarron <[email-masked]><mailto:[email-masked]>
Betreff: Re: [Cfrg] Crystalline Cipher

On Wed, May 20, 2015 at 3:59 PM, Mark McCarron <[email-masked]<mailto:[email-masked]>> 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,

Specifically:

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

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

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

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

--
Tony Arcieri

---

---

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
http://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
http://www.irtf.org/mailman/listinfo/cfrg

---

From: William Whyte <[email-masked]>
Date: Thu, 21 May 2015 11:09:24 -0400

Hi Mark,

There are a lot of proposed ciphers out there, and if you want someone to
spend time analyzing it, you need to give a reason for why it’s worth their
time. Existing widely-used ciphers and modes of operation have the
properties that (a) they use the minimum number of key bits necessary to
give the desired level of security and (b) they leak as little information
as possible, including leaking whether or not there are repeating patterns
within the ciphertext. Your cipher allows someone to distinguish the
encryption of plaintext with a repeating pattern from the encryption of a
plaintext without a repeating pattern. In the terms this group uses, that
counts as broken, because there are other well-studied ciphers that don’t
reveal that information. If you can come to the group with a cipher that
uses a 128-bit key, doesn’t leak information, and has performance (memory
consumption / processing time) better than AES, you may find people are
willing to spend time on it. If your cipher doesn’t meet those conditions,
there’s no particular reason for people to take it seriously.

Cheers,

William

*From:* Cfrg [mailto:[email-masked]] *On Behalf Of *Mark McCarron
*Sent:* Thursday, May 21, 2015 2:52 AM
*To:* [email-masked]
*Subject:* Re: [Cfrg] Crystalline Cipher

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 <[email-masked]>
*Datum:* 21.05.2015 08:43:33
*An:* Mark McCarron <[email-masked]>, Tony Arcieri <
[email-masked]>
*Betreff:* Re: [Cfrg] Crystalline Cipher

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

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:

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 <[email-masked]> <[email-masked]>
*Datum:* 21.05.2015 02:34:45
*An:* Mark McCarron <[email-masked]> <[email-masked]>
*Betreff:* Re: [Cfrg] Crystalline Cipher

Hi Mark,

Specifically:

-- 

Tony Arcieri

---

---

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 18:24:59 +0200

William,

This is some serious fud.  A break is not the lack of plausible deniability, or stealth (both of which are red flags in the context of data anyway).  A break is being able to retrieve the plaintext given only the ciphertext.  You, nor anyone else on this list, has offered a single shred of data to indicate that a break is possible.  Of course you can add the whistles and bells you are describing, but they are not required for a functional cipher.  For a lot of people, things like memory consumption, processing time and stealth are not what they are interested in.  Many just want something they know to be secure and would stop even the NSA in their tracks.

Regards,

Mark McCarron

> --- original message ---
> From: William Whyte 
> Date: 21.05.2015 17:09:24
> To: Mark McCarron , [email-masked]
> There are a lot of proposed ciphers out there, and if you want someone to spend time analyzing it, you need to give a reason for why it&rsquo;s worth their time. Existing widely-used ciphers and modes of operation have the properties that (a) they use the minimum number of key bits necessary to give the desired level of security and (b) they leak as little information as possible, including leaking whether or not there are repeating patterns within the ciphertext. Your cipher allows someone to distinguish the encryption of plaintext with a repeating pattern from the encryption of a plaintext without a repeating pattern. In the terms this group uses, that counts as broken, because there are other well-studied ciphers that don&rsquo;t reveal that information. If you can come to the group with a cipher that uses a 128-bit key, doesn&rsquo;t leak information, and has performance (memory consumption / processing time) better than AES, you may find people are willing to spend time on it. If your cipher doesn&rsquo;t meet those conditions, there&rsquo;s no particular reason for people to take it seriously.
>  
> Cheers,
>  
> William
>  
> From: Cfrg [mailto:[email-masked]] On Behalf Of Mark McCarron
> Sent: Thursday, May 21, 2015 2:52 AM
> To: [email-masked]
> --- Urspruengliche Nachricht ---
> Von: Mike Hamburg [email-masked]>
> An: Mark McCarron [email-masked]>, Tony Arcieri [email-masked]>
> > --- Urspruengliche Nachricht ---
> > Von: Tony Arcieri 
> > An: Mark McCarron 
> > On Wed, May 20, 2015 at 3:59 PM, Mark McCarron [email-masked]> wrote:

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 18:37:08 +0200

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 <[email-masked]>
Date: 21.05.2015 16:54:47
To: Mark McCarron <[email-masked]>, [email-masked]
Subject: Re: [Cfrg] Crystalline Cipher

-- Mike

Mike,

Regards,

Mark McCarron

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

-- Mike

Hi Tony,

Regards,

Mark McCarron

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

Hi Mark,

Specifically:

--

Tony Arcieri

---

---

---

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 18:56:17 +0200

Kenny,

Posting an official position of the chairs on-list would probably be more appropriate.  I think a full and clear explantion of why the CFRG is not living living up to its stated remit is important.  Further, I would like to gain an insight as to your personal opinion in regards to some of the fud that has been posted to this group in regards to what is, or is not, a break in a cipher.

I'm not claiming that anyone is suppressing anything, as we both know it doesn't take a genius to make an unbreakable cipher.  It does, however, take some skill to develop one that is practical.  But 'practical' means different things to different people and 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.

Regards,

Mark McCarron

--- original message ---
From: "Paterson, Kenny" <[email-masked]>
Date: 21.05.2015 17:03:03
To: Mike Hamburg <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

Please do desist.

Regards,

Kenny (for the chairs)

Sent from my iPhone

On 21 May 2015, at 15:55, Mike Hamburg <[email-masked]> wrote:

-- Mike

Mike,

Regards,

Mark McCarron

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

-- Mike

Hi Tony,

Regards,

Mark McCarron

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

Hi Mark,

Specifically:

--

Tony Arcieri

---

---

---

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 21:34:54 +0200

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 <[email-masked]>
Datum: 21.05.2015 19:41:32
An: Mark McCarron <[email-masked]>
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 <[email-masked]> wrote:

Mike,

Regards,

Mark McCarron

--- original message ---

-- Mike

Mike,

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---

-- Mike

Hi Tony,

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---

Hi Mark,

Specifically:

--

Tony Arcieri

---

---

---
Free, fast and secure email: https://www.eclipso.eu _______________________________________________
Cfrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

---

From: Ryan Daurne <[email-masked]>
Date: Thu, 21 May 2015 21:50:44 +0100

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.
>
> 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?
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 23:02:18 +0200

Paul,

Actually, I think you are doing a lot of damage to Marvell.  As the Director of Engineering, I would expect you to to be polite, courtious and professional at all times, especially when communicating from a corporate address.  Instead, you come across as rude, childish, abusive, unprofessional and somewhat lacking when it comes to the area of cryptography.  That's a rather disturbing picture to have of someone responsible for security in wireless products and certainly not a picture that I would want to share with my client base.

As to your comments in regards to Crystalline, I am afraid you cannot make such a determination without in-depth study.  As Mike clearly stated, he probably could not break the cipher given only the ciphertext and that it would takes weeks-to-months to analyse properly.  Even though you have not performed such an analysis, nor have any data to support your claims, you are confident enough to proclaim that it is a bad cipher.  Apparently, more than your wireless devices are receiving information out of thin air.

In regards to reputation and standing in a community, so far I have not seen any responses that indicate a level of knowledge beyond the ability to repeat terminology and formulas developed by third parties.  As someone who writes ciphers and performs cryptanalysis, I have observed individuals communicating with me on this mailing list that demonstrate a distinct lack of knowledge in the basic underpinning theory of cryptography.  Its so bad, they cannot tell the difference between snake-oil and a strong cipher.  So, I am rather relaxed about standing out from the crowd on this one.

Anyway, thanks for the friendly advice.

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---
Von: Paul Lambert <[email-masked]>
Datum: 21.05.2015 22:06:05
An: Mark McCarron <[email-masked]>
Betreff: Re: [Cfrg] Crystalline Cipher

Mike asked that you communicate with him off the list …  you are cluttering the in boxes of many people  with a topic they now will only laugh about.  Please stop sending to CFRG on this topic.

Your proposal and analysis lacks any merit –> a D-  or F if this cipher were a college home work assignment.  Please listen to the opinions you’ve gotten and back off.  You are doing irreparable damage to your reputation and greatly diminishing your standing in this community by disregarding the advice of the mailing list chair.

Paul

Hi Mike,

2. How should I use it?

Regards,

Mark McCarron

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

Hi Mark,

— Mike

Mike,

Regards,

Mark McCarron

--- original message ---

-- Mike

Mike,

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---

-- Mike

Hi Tony,

Regards,

Mark McCarron

--- Ursprüngliche Nachricht ---

Hi Mark,

Specifically:

--

Tony Arcieri

---

---

_______________________________________________
Cfrg mailing list
[email-masked]://www.irtf.org/mailman/listinfo/cfrg

---

---

---

---

From: "Mark McCarron" <[email-masked]>
Date: Thu, 21 May 2015 23:09:09 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 May 2015 22:14:42 +0100

Hi Kenny,

> Mark: I can expand on the reasons why offline if you wish.

Just to say I agree with your (chairs') call on this. I don't
think this is the place to develop or defend new ciphers.

There are lots of argument-winning reasons for that, but one
of those is that we all only have so many cycles to spend so
spending those bridging between Internet engineering and
academic cryptography that's already accepted by that
community is by far a better way to spend time in CFRG.

Cheers,
S.

---

From: Michael Hamburg <[email-masked]>
Date: Thu, 21 May 2015 14:16:10 -0700

> On May 21, 2015, at 2:02 PM, Mark McCarron <[email-masked]> wrote:

> As to your comments in regards to Crystalline, I am afraid you cannot make such a determination without in-depth study.  As Mike clearly stated, he probably could not break the cipher given only th…

Please be careful in how you paraphrase me.  This is not what I stated.  If you wish to argue about what I wrote to you off-list, please argue with me off-list.

— Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 May 2015 15:35:51 +0000

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

Mark,

It doesn't work that way.  You don't show up at a meeting, where people are working on a particular agenda, thrown down a pamphlet filled with what many of the people in the meeting treat as "bozo warning signs" and expect people to help you prove that your work is valid.

How about you show some mathematical analysis?

---

From: "Mark McCarron" <[email-masked]>
Date: Fri, 22 May 2015 22:02:08 +0200

Rich,

I will do that.  Firstly, I want to publish the Beta 3 release of Crystalline.  That will happen sometime this weekend.  Beta 3 will introduce a breaking change as I remove the constant elements that are present in the algorithm.  I will also incorporate the RStudio toolkit as well as utility functions to generate test plaintexts, keys and salt.  I will use .NET RNGCryptoServiceProvider for these.

To understand the principles behind Crystalline, I would recommend brushing up on Lorenz and Enigma.  Specifically, not just how they were broken, but explore the fundamental reason why, from an information theory perspective, a break can occur in the first place. 

I will give everyone a clue, its has something to do with the following factors: detecting information, relating detected information and possessing enough information to begin computation.  

I will give bonus points to anyone who can answer these set of questions: in computational/mathematical theory.  

1.  Given any algebraic formula, what must be induced before computation can begin or an equation solved?  
2.  Why?
3.  What is the relationship to physics?

Possessing all the above information will leave you in a good position to understand not only what Crystalline is doing and why it is doing it, but also understand if it is achieving that.

I will be back after the release.

Regards,

Mark McCarron

--- original message ---
From: "Salz, Rich" <[email-masked]>
Date: 22.05.2015 17:35:51
To: Mark McCarron <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Cfrg] Crystalline Cipher

> > Could you repeat this post?  Only this time, include a practical break
> in the
> > cipher.
> 
> Mark,
> 
> It doesn't work that way.  You don't show up at a meeting, where people are
> working on a particular agenda, thrown down a pamphlet filled with what many
> of the people in the meeting treat as "bozo warning signs" and
> expect people to help you prove that your work is valid.
>

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 22 May 2015 15:32:36 -0700

On Fri, May 22, 2015 at 1:02 PM, Mark McCarron <[email-masked]>
wrote:

> To understand the principles behind Crystalline, I would recommend
> brushing up on Lorenz and Enigma.

Hi Mark,

I'm quite familiar with Lorenz and Enigma, both of which are considered
extremely broken today.

Enigma contained a bias because it never mapped a letter to itself. Any
such bias is sufficient to break a cipher.

Your cipher is full of similar biases:

http://www.freecx.co.uk/cryptanalysis/Crystalline/Crystaline_3D.jpg

If it were a good cipher, it'd appear flatter:

http://www.freecx.co.uk/cryptanalysis/Crystalline/RC4_3D.jpg

Note that RC4 is not a good cipher. You may not know it, but Kenny was part
of a team that found such biases in RC4.

Your cipher has biases. Therefore it's broken. Period. I know you disagree,
but you're wrong. Period. Your cipher is broken. End of story.

By modern standards, your cipher should be indistinguishable from random
data even in the presence of a chosen ciphertext attack, something I'm
fairly certain you're not even familiar with:

https://en.wikipedia.org/wiki/Ciphertext_indistinguishability

Your cipher is obviously distinguishable from random data, simply by
looking at an image of the ciphertext:

If you have a genuine interest in cryptography, I hope you take these
things to heart, study them, and improve your knowledge of cryptography.

---

From: "Mark McCarron" <[email-masked]>
Date: Sat, 23 May 2015 03:56:53 +0200

Hi Tony,

This is a bit of moot point as I am introducing changes that will correct this.  But, I will address this issue as there is a fundemental difference between RC4 and Crystalline.  This difference means that a bias in the output, does not lead to a break in the cipher.  Let me explain this.

I would think of the break in Enigma in slightly different terms.  The fact that a key never encoded itself, provided a point of reference from which to begin a process of elimination that reduced the number of permutations to a level that could be feasibily be computed in a short period of time.

In RC4, as far as I am aware, the break was of a different nature.  A small, but detectable bias, effectively modulated data that could be recovered statistically.

In Crystalline, the bias that is observed in each output is generally unique.  Operator error can cause issues, but that is true with all ciphers.  The ciphertext is a product of the XOR, the original plaintext and random input.  As the cipher passes through the file serially, it swaps the bit from the current index (whilst XORing it with true) with a randomly selected bit between 0 and 65535 locations away, alternating the direction with each increment.  It repeats this for every bit in the file.  It then passes through the file serially again performing a similar swap of the bytes only without an XOR.  This process is defined as a round and at minimum 10 rounds are applied.  The effect of this the bits of any given byte from the original plaintext can be anywhere in the file and can be any state (1 or 0).

It is like throwing a hand grenade at the data.  There is no mathematical relationship between the location of the bits, so no formula, however complex, can be applied to recover the data.  The only practical approach is to seek patterns that can identify the key.  The issue is that the patterns of the final cipher text, do not map up in any way to the original key, they map to the previous layer and the layer before that and so forth.  In certain plaintexts such as a file filled with 0x00 you can observe some patterns when presented in images, but this as an echo of a signal that has degraded beyond the point of recovery.

So, the cipher is much more complex than a cursory examination would suggest and issues that are big things in modern ciphers, are not serious issues for a cipher such as Crystalline. The principles are different, thus the attack vectors are different.  It probably has more in common with analogue signal recovery than it does with traditional cipher breaking.

As for being indistinguishable from noise, this is one way of achieving security, it is by no means the only method.  Simply making information unrecoverable (which is defined as information loss in the context of Crystalline) will achieve the same effect.  It is similar to a 'minimum detectable signal' in radio engineering.  I hope you can see that both techniques are doing the same thing, only they do it in different ways.  So, bias is not the enemy of Cryptography (at least not Crystalline), the enemy is points of reference (as in the Enigma break) which can be related to other information to enable feasible computation.

It somewhat surprises me that this knowledge appears to have been lost at some point in the Cryptographic community.  Perhaps it is a product of the move to digital technologies.

Regards,

Mark McCarron

--- original message ---
From: Tony Arcieri <[email-masked]>
Date: 23.05.2015 00:32:36
To: Mark McCarron <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

On Fri, May 22, 2015 at 1:02 PM, Mark McCarron <[email-masked]> wrote:

To understand the principles behind Crystalline, I would recommend brushing up on Lorenz and Enigma.

Hi Mark,

I'm quite familiar with Lorenz and Enigma, both of which are considered extremely broken today.

Enigma contained a bias because it never mapped a letter to itself. Any such bias is sufficient to break a cipher.

Note that RC4 is not a good cipher. You may not know it, but Kenny was part of a team that found such biases in RC4.

Your cipher has biases. Therefore it's broken. Period. I know you disagree, but you're wrong. Period. Your cipher is broken. End of story.

By modern standards, your cipher should be indistinguishable from random data even in the presence of a chosen ciphertext attack, something I'm fairly certain you're not even familiar with:

Your cipher is obviously distinguishable from random data, simply by looking at an image of the ciphertext:

If you have a genuine interest in cryptography, I hope you take these things to heart, study them, and improve your knowledge of cryptography.

---

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 22 May 2015 19:12:43 -0700

On Friday, May 22, 2015, Mark McCarron <[email-masked]> wrote:

> This difference means that a bias in the output, does not lead to a break
> in the cipher.

This is basically the cryptographic equivalent of claiming up is down,
black is white, true is false, etc.

The very act of making such a claim demonstrates only that you're a
clueless crackpot and you don't know what you're talking about.

Many, many, many people have have tried to explain this to you over and
over and over. At this point there are only two possible conclusions in my
mind:

1) You are intentionally trolling people to provoke a response
2) You are suffering from a mental illness

In either case, I have come to the conclusion that you are beyond hope and
the best thing I can do is ignore you.

-- 
Tony Arcieri

---

From: "Mark McCarron" <[email-masked]>
Date: Sat, 23 May 2015 04:24:06 +0200

Tony,

Just because you can detect a bias does not mean that you can turn that into data such as key/plaintext.  A key, plaintext, etc., is just another type of modulated signal and it can degrade to the point of being unrecoverable and still present a bias.  I detect biases all the time in signals on my radio gear, it does not mean I can recover the modulated data.  That would only be the case if I can fill in the blanks using mathematical relationships, which is not a valid approach with Crystalline.

The real problem Tony, is that you only understand a certain portion of cryptography, but profess to know it all.

Regards,

Mark McCarron

--- original message ---
From: Tony Arcieri <[email-masked]>
Date: 23.05.2015 04:12:43
To: Mark McCarron <[email-masked]>
Subject: Re: [Cfrg] Crystalline Cipher

This difference means that a bias in the output, does not lead to a break in the cipher.

This is basically the cryptographic equivalent of claiming up is down, black is white, true is false, etc.

The very act of making such a claim demonstrates only that you're a clueless crackpot and you don't know what you're talking about.

Many, many, many people have have tried to explain this to you over and over and over. At this point there are only two possible conclusions in my mind:

In either case, I have come to the conclusion that you are beyond hope and the best thing I can do is ignore you.

--
Tony Arcieri

---