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

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

I *WAS* [past tense] working on the proofs until I realize the design would
be horribly slow.

Tom St Denis wrote:

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

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

I *WAS* [past tense] working on the proofs until I realize the design
would
be horribly slow.

Sorry that I misread. But I expressed my wish to see
rigorous, clear and systematically presented proofs,
i.e. clearly showing the rigor of your 'reduction'
in the sense of logic. I have yet to wait for these,
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:

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

I *WAS* [past tense] working on the proofs until I realize the design
would
be horribly slow.

Sorry that I misread. But I expressed my wish to see
rigorous, clear and systematically presented proofs,
i.e. clearly showing the rigor of your 'reduction'
in the sense of logic. I have yet to wait for these,
if I don't err.

Because I haven't formed a complete proof yet? There is normally a leap
from argument to proof.

My argument is that with decorrelated functions on indecies the attacker
will not only not know the input XOR mask nor will they know the difference
between any pairing [e.g. can't easily establish what plaintext differences
were]. Also since each counter is unique [my F2 is a PRP not PRF] identical
output blocks means the plaintext xor'ed against an unknown equals another
plaintext [xor'ed against an unknown].

This is all well and good but none of it is a proof of what I was trying to
establish.

However, being finite in lifespan and working within a 16 hour day I've
decided to move onto more productive work. That is my upcoming libtompoly.
Let's not forget I still have full-time school coming up, a book to edit and
now four libraries to support.... all of which I do for free [except the
school thing, that costs me money...]

So like three posts ago I retracted my design for obvious reasons [it's
harder than it looks, gonna be slow, don't have the time to redesign it].
However if you insist...

I, Thomas James St Denis, the second son of Katie and Vern St Denis, of the
clan St Denis, do hereby and unequivocably state that I have failed in
designing an Enc+Auth mode, that I retract the design from public
consideration and that I'm a failure at life in general. Leaving no room
for error, Mok-Kong Shen is now my ruling master and I will obey him
willfully and dutifully for as long as I shall live. I swear this to be
true for all to bear witness.

Happy?

Very unhappy and disappointed. You said that you had
proofs (if I interpret you words correctly) on the
(original) scheme but it's slow. That slowness doesn't
matter much yet, I suppose. If the proofs are good,
maybe somebody or you yourself could modifiy the scheme
to be of higher efficiency yet retaining the rigor
of security proof. That would be a very nice thing.
If you resign and just discard your stuff, that's a
pity in my honest opinion.

[snip]

This is the last time I want to reply about this. Give it up. If you want
to make proofs about my mac idea by all means go ahead. I have no plans to
continue it right now [I've explained why].

Tom St Denis wrote:

[snip]

This is the last time I want to reply about this. Give it up. If you
want
to make proofs about my mac idea by all means go ahead. I have no plans
to
continue it right now [I've explained why].

Don't misunderstand me. I do think that a scheme like
that of yours, even without rigorous proofs, may be
practically useful and anyway better variants/modifications
of it couldn't be excluded. I personally use to think
that something intuitively clear could be o.k. for the
practice, in view of the fact that much of an 'entire'
security system, of which the proper crypto material is
only a part, depends on more or less subjective
considerations. (I know that some would never agree with
me in this point.)

[snip]
The point of crypto research though is not to come up with as many cool
designs as possible. I wouldn't suggest anyone to use tommac unless I could
prove something about it. You might as well us CTR+OMAC which both have
proofs [or reductions] related to their intended goals.