Re: [Cfrg] Crystalline Cipher

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:mark.mccarron@eclipso.eu]
Sent: Wednesday, May 20, 2015 08:11 PM
To: Nico Williams <nico@cryptonector.com>
Cc: cfrg@irtf.org <cfrg@irtf.org>
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 

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

--- original message ---
From: Nico Williams <nico@cryptonector.com>
Date: 21.05.2015 01:55:00
To: Mark McCarron <mark.mccarron@eclipso.eu>
Subject: Re: [Cfrg] Crystalline Cipher

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

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg