[Cfrg] Crystalline Cipher

"Mark McCarron" <mark.mccarron@eclipso.eu> Wed, 20 May 2015 19:28 UTC

Return-Path: <mark.mccarron@eclipso.eu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E98081A8BC0 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 12:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RV4DY-Ev7T_c for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 12:28:29 -0700 (PDT)
Received: from mail.eclipso.de (mail.eclipso.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A71B1A8BC4 for <cfrg@irtf.org>; Wed, 20 May 2015 12:28:28 -0700 (PDT)
Received: from mail.eclipso.de (www1.eclipso.de []) by mail.eclipso.de with ESMTP id 306F03D0 for <cfrg@irtf.org>; Wed, 20 May 2015 21:28:26 +0200 (CEST)
Date: Wed, 20 May 2015 21:28:25 +0200
MIME-Version: 1.0
Message-ID: <78c28854a0cbb9ab7930141285059c6c@mail.eclipso.de>
X-Mailer: eclipso.eu/7.3.0
From: Mark McCarron <mark.mccarron@eclipso.eu>
To: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/VXLC6cj2KwecsWRhp0yJXLF9jEw>
Subject: [Cfrg] Crystalline Cipher
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark McCarron <mark.mccarron@eclipso.eu>
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 19:28:32 -0000

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: 
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: 
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) 
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. 
Mark McCarron