Re: Encyption of two 256-blocks

"Maaartin" <grajcar1@xxxxxxxxx> wrote in message news:2a46de55-500b-45f6-86f6-6ca9955343c9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Sure... so you encrypts each piece of data 4 times and suggest that
doing it twice should do.
I rewrite it like
Z = X0 | X1;
for (int i=0; true; ++i) {
Z = CBC_encrypt(Z, K, 0);
if (i==4) break;
Z = mix(Z);
}
Y0 | Y1 = Z;

Looks good.


Maybe a final mixing step could be useful (in case the attacker knows
Y0).
Maybe an initiator mixing step could be useful as well (in case the
attacker knows the set S).

The first and last mixes are cryptographically irrelevant, an attacker that knows the inputs but not the key can recreate the first, and anyone with knowledge of Y0 and Y1 can undo the last.


Do you thing some more expensive mixing could be better?

Not really. I chose the mix type I did because it is trivially proven that the information from all bits is scattered across all blocks, forming an AONT for the specific size, provided the cipher is secure.

I think about using one or two rounds of salsa20.

The simplest idea I habe is the following:
Z = CBC_encrypt(Z, K, 0);
Z = CBC_encrypt_backward(Z, K, 0);
without any additional mixing, where CBC_encrypt_backward simply takes
the block in reverse order.
But I'm not comfortable with it somehow.

It has flaws, the blocks are not fully mixed, at least not to the degree that you seem to desire. Block[0] is fully diffused into Block[1], but only half the data from Block[0] gets to Block[2], and 1/4 gets to Block[3]. It would be secure, but doesn't have the warm fuzzies.


But is there no "provably secure" way how to do it?

The way I proposed is provably an All-Or-Nothing-Transform as long as the cipher includes a complete Avalanche Effect.


I also note a missing requirement, but I'll keep quite about it, all the
reasonable suggestions will meet the requirement anyway.

Which one?
If you mean, "there should be no way to find out K", than it's clear.
Or do you mean something else?

You make no requirement that K, X0, and X1 can be used to compute Y0 and Y1 in a dependable way. All useful methods of course have this feature, but you'd be surprised how often it is omitted.


*** TO biject:

I notice many errors. But I usually don't care enough
to show them to you.

I see no single error there (the typo does not matter at all).
But I can't tell if it's strong enough and if it's not slower than
necessary.
Can you?

I wouldn't trust Biject to tell you anything of value. You can feel free to read his history, but to spoil the ending I'll just discuss his latest proposal. He is attempting to use a bitwise inverse Burrows-Wheeler Transform (which he somehow thinks is "special") as an AONT, it fails completely at that and trivially. The Burrows-Wheeler Transform has known biases, in fact it is useful because the biases it introduces make life easier in compression. As such the proposal is a complete waste of effort to understand, and even more to implement.


*** TO David Wagner:

I see my last requirement was confusing.
Actually, all values of X0 and X1 are possible, but the actually used
values get recorded in the set S.

You could build a 512-bit block cipher, then compute
Y0||Y1 = Encrypt(K, X0||X1)
where || denotes concatenation.
....
The best defense I can come up with is to use some kind of strengthening
to ensure that encryption takes 1 second (say), so that trying all
millions of possibilities for X0 will take millions of seconds.

No, the normal operation must be fast.
I have to keep S as secret as possible, instead.
Without knowing S there are 2**256 possibilities for each X, so this
is no problem.


There are many possibilities. For example, the original design for Rijndael allows for variable sized blocks, a 512-bit block with an absurd number of rounds should be secure, but it is unanalyzed. To put you at ease about it, a version of Rijndael with fixed parameter selections is now called AES.

And of course there is always HPC, and countless others. The only reason I would not recommend using a 512-bit cipher is because none have withstood intense analysis, the closest would be HPC which was found to have slight flaws, these flaws almost certainly won't be a problem in your environment, but even the slightest flaw tends to send cryptanalysts running elsewhere.

I still think any complete mixing strategy combined with a strong cipher is best, I chose mine for simplicity, but method that splits each block from the previous round equally among the blocks for the current round is equally good.
Joe

.

Relevant Pages

  • A secure hand cipher?
    ... I have been looking for a way to make a secure hand cipher similar to the ... The "encryption device" is a standard set of scrabble tiles with one ... Text1: From Sherlock Holms ...
    (sci.crypt)
  • Re: QC-proof cipher?
    ... to conventional computation techniques, let alone quantum computing. ... one "secure" symmetric cipher too, ... One thing I wonder is people always say this about OTP but what ... is the difference between OTP and a NULL cipher. ...
    (sci.crypt)
  • Re: triple algorithms
    ... matching of algorithms I would advise you don't do this. ... AES is secure insofar as nobody has yet found a viable attack for it. ... creating a new cipher out of a collection of others. ... security depends only on the single assumption that factoring is hard. ...
    (sci.crypt)
  • Re: Which paper and pencil cipher to use ?
    ... >>> Can someone please recommend a reasonably secure paper and pencil ... >>> The cipher is to be used in an area where electronic methods are ... > practicality, and notes on its practical use from "Between Silk and ... > unbreakable if the running key texts were taken from the space of all ...
    (sci.crypt)
  • Re: convert stream ciphers into block ciphers
    ... For instance, secure ... like a four-round Feistel construction required, to make a stream cipher ... A four-round Feistel construction involves using the stream cipher four ...
    (sci.crypt)