Tom St Denis wrote:

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

Why is that? Why couldn't the 4 words in an 128-bit
block be operated on separately? Analogy, S-boxes are
normally even smaller, e.g. 8 bits only.)

First off, the entire block has to be pair-wise decorrelated or you
cannot
reduce the security to F1. That is anything you can learn about the
plaintext without inverting F1 shows the design cannot be reduced to F1
in
terms of security.

The 4 words of P[i] and C[i] that get mixed into Z
and Z is xored with P[i+1] and passed as a whole
through the encryption algorithm (that has the effect
of mixing the 4 words contributed by Z in a sense
thoroughly). I don't think there is anything critical
practically, except when one is highly theory-oriented.
(But in that case, even the encryption algorithms
themselves don't have rigorous proofs, if I don't err.)

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

Tom St Denis wrote:

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

Why is that? Why couldn't the 4 words in an 128-bit
block be operated on separately? Analogy, S-boxes are
normally even smaller, e.g. 8 bits only.)

First off, the entire block has to be pair-wise decorrelated or you
cannot
reduce the security to F1. That is anything you can learn about the
plaintext without inverting F1 shows the design cannot be reduced to F1
in
terms of security.

The 4 words of P[i] and C[i] that get mixed into Z
and Z is xored with P[i+1] and passed as a whole
through the encryption algorithm (that has the effect
of mixing the 4 words contributed by Z in a sense
thoroughly). I don't think there is anything critical
practically, except when one is highly theory-oriented.
(But in that case, even the encryption algorithms
themselves don't have rigorous proofs, if I don't err.)

You need the proof to reduce it. So relying on the cipher to give you proof
is not valid unless you can argue it otherwise [to be honest I don't know if
your design is reducible]. See I learned something this winter. It's
called a reduction. [Thanks Rogaway!]

For example, in OCB he never proves that OCB is secure. He proves that
under certain instances you reduce OCB [IIRC] to the security of the cipher.
That is if you break OCB you break the cipher [and conversely if you break
the cipher you break that instance of OCB].

This has been used in many other algorithms. Rabin reduces to factoring.
Various parts of DH reduce to DHDP or DLP, etc. RSA almost reduces to
factoring [but not quite], HMAC reduces to the hash used, CTR to the cipher
used, etc...

In my case I was trying to reduce the security to that of F1 [e.g. AES or
whatever]. However, my design needs an overhaul to be practical [and reduce
nicely] which is why i'm scrapping it for now. Lesson learned though so all
is well.

I must admit that I don't understand your reasoning.
Maybe that's too high for my poor knowledge. I don't
think that it is of value for us to continue the debate,
excepting taking the opportunity to remark that my scheme
is fast and it works with one single encryption algorithm.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

I must admit that I don't understand your reasoning.
Maybe that's too high for my poor knowledge. I don't
think that it is of value for us to continue the debate,
excepting taking the opportunity to remark that my scheme
is fast and it works with one single encryption algorithm.

I'm trying to design something I can prove something about. You're just
throwing random shit together. What are you even trying to obtain? What
are the goals of your design? Can you prove them?

Your sarcasm notwithstanding, if you aren't going to support your proposals
without at least a promise to try and prove something about it you might as
well not bother. For example, one of the reasons OMAC was chosen by NIST is
that the security was proven to be boundable.

When you stop thinking of science as a form of alchemy and starting thinking
of it as logical principles then we can talk rationally about things.

Just a general remark (independent of the present stuff):
If one relies on something that one doesn't have
(rigorous) proof, then a reduction to that something
is of not much value in really serious terms in my view.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

Just a general remark (independent of the present stuff):
If one relies on something that one doesn't have
(rigorous) proof, then a reduction to that something
is of not much value in really serious terms in my view.

So then by your logic don't reduce to anything at all and let the fish sort
it out?

We rely on quite a few non-proven problems all the time.

Assumption: AES is a secure block cipher.
Assumption: Factoring is hard.
Assumption: SHA-1 is a secure cryptographic one-way hash.
Assumption: RSA effectively reduces to Factoring.
[etc...]

If we couldn't rely on assumptions like that things like SSL, GPG, etc.
wouldn't exist.

The trick though in real science is to reduce things. This even happens in
other fields not even related to crypto. The KL transform is the most
energy efficient transform for coding. If I can reduce some "faster"
transform to the KL [e.g. if my transform has bad gain so does the KL] then
I will be famous.

So when designing a mode of operation you want to reduce the security to
something you're willing to accept. E.g. I'm willing to accept AES is a
secure block cipher. I'm not willing to assume some random transform you
invent is a good PRP.

In that case I don't think relying on e.g. AES (something
I am willing to accept) to mix (indirectly) my 4 words
of Z (and thus I don't need to operate on 128 bits
en bloc in operating on it) is anything wrong either
in a logical sense.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

In that case I don't think relying on e.g. AES (something
I am willing to accept) to mix (indirectly) my 4 words
of Z (and thus I don't need to operate on 128 bits
en bloc in operating on it) is anything wrong either
in a logical sense.

That's totally acceptable. Now prove that your protocol reduces to the
security of AES.

Tom St Denis wrote:

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

In that case I don't think relying on e.g. AES (something
I am willing to accept) to mix (indirectly) my 4 words
of Z (and thus I don't need to operate on 128 bits
en bloc in operating on it) is anything wrong either
in a logical sense.

That's totally acceptable. Now prove that your protocol reduces to the
security of AES.

To speak frankly, I don't clearly see the rigor of
your reduction. If I can know more details showing
the rigorosity of each step, perhaps I could have
some 'hope' of doing that too.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

To speak frankly, I don't clearly see the rigor of
your reduction. If I can know more details showing
the rigorosity of each step, perhaps I could have
some 'hope' of doing that too.

I don't get what you are trying to say here. Are you saying reductions are
not worth anything? Or what?

Tom St Denis wrote:

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

To speak frankly, I don't clearly see the rigor of
your reduction. If I can know more details showing
the rigorosity of each step, perhaps I could have
some 'hope' of doing that too.

I don't get what you are trying to say here. Are you saying reductions
are
not worth anything? Or what?

I meant I want to see what you term 'reduction' of
your scheme in a clearer systematically presented
way, such that the rigor of deduction is evident.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:


Tom St Denis wrote:

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

To speak frankly, I don't clearly see the rigor of
your reduction. If I can know more details showing
the rigorosity of each step, perhaps I could have
some 'hope' of doing that too.

I don't get what you are trying to say here. Are you saying reductions
are
not worth anything? Or what?

I meant I want to see what you term 'reduction' of
your scheme in a clearer systematically presented
way, such that the rigor of deduction is evident.

There are two reductions required.

1. Is the privacy maintained?
2. Is the authenticity maintained.

I was in the middle of proving that if F2() is pair-wise decorrelated then
the encryption is as secure as the cipher under a known plaintext attack. I
didn't finish the proof obviously because I retracted the design. I was
also trying to prove #2 but again retracted the design so it's moot.

The point though is I had the intention to [and I did] try and prove
something about my proposed design.

And proofs are normally not trivial. Read Rogaway papers for instance....

Thank you for the clarification. I am looking forward
with great interest to soon see your proofs.

"Mok-Kong Shen" <mok-kong.shen@t-online.de> wrote:

Thank you for the clarification. I am looking forward
with great interest to soon see your proofs.

Um? What part of retracted don't you understand?

My design was a neat idea but turned out to be a flop. It happens. Why
would I spend more time on it unless I changed the design itself and thus
have to restart the analysis?

Also why are you changing the subject. You're the one proposing to use
latin squares. Either start your argument and eventual proof or retract
your design.

Didn't you say that you are yet working on your proofs?
I am waiting for these. I was saying no more, nor less.