Re: [Cfrg] Crystalline Cipher

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

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" <[e-mail]>
Date: 21.05.2015 02:11:20
To: "Nico Williams" <[e-mail]>
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 <[e-mail]>
> Date: 21.05.2015 01:55:00
> To: Mark McCarron <[e-mail]>
> 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
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>