Funding to Attend SAM 06, LV, US

[ashish.s...@gmail.com]

Hi,

My paper has been invited to SAM 06.

The paper titled "FastFlex : A New Fast and Flexible Cryptographic
Function" deals with the design of a new cryptographic primitive which
is then used to construct a Stream Cipher (192-bit) and a Hash Function
(256-bit), both faster than AES in Counter mode and AES Hash by a
factor of at least two. It also has a smaller memory footprint as
compared t0 AES (One-Fourth or better).
The paper can be accessed at
http://fastflex.sourceforge.net/files/FastFlex-SAM.pdf

I have however not been able to raise adequate funding for attending
the seminar. I am a full time student and attending the conference
elsewise, is out of question.

I am looking for potential Sponsors which may be intersted in partly
sponsoring the research (And the conference visit maybe).

Any links and/or references for the same would be very helpful indeed.

Thanking you in anticipation.

Ashish Sharma
Army Institute of Technology, Pune, India

[tomst...@gmail.com]

ashish.s...@gmail.com wrote:
> Hi,
>
> My paper has been invited to SAM 06.
>
> The paper titled "FastFlex : A New Fast and Flexible Cryptographic
> Function" deals with the design of a new cryptographic primitive which
> is then used to construct a Stream Cipher (192-bit) and a Hash Function
> (256-bit), both faster than AES in Counter mode and AES Hash by a
> factor of at least two. It also has a smaller memory footprint as
> compared t0 AES (One-Fourth or better).
> The paper can be accessed at
> http://fastflex.sourceforge.net/files/FastFlex-SAM.pdf

No offense, but "where's the beef?" You're presenting a new design
which has no provable qualities, is totally heuristic and depends on
obscurity for safety.

Why should I use this new design over, say, a well thought out
carefully designed wide trail design? Where I can model the diffusion
and branch exactly and apply non-linear elements of higher degree (than
just the add/xor chain you have).

Being "faster" isn't always better because when it really boils down to
it, AES is fast enough for most problems AND inherits a lot of nice
properties.

Tom

[ashish.s...@gmail.com]

tomstde...@gmail.com wrote:

> No offense, but "where's the beef?" You're presenting a new design
> which has no provable qualities, is totally heuristic and depends on
> obscurity for safety.
>
> Why should I use this new design over, say, a well thought out
> carefully designed wide trail design? Where I can model the diffusion
> and branch exactly and apply non-linear elements of higher degree (than
> just the add/xor chain you have).
>
> Being "faster" isn't always better because when it really boils down to
> it, AES is fast enough for most problems AND inherits a lot of nice
> properties.
>
> Tom

"No Offense"...None Taken. The whole idea was to come up with an easy
to analyze structure (and easy to memorize!) quite different to the
Wide Trail Design Strategy. The idea here was to use active bits to
offer excellent diffussion and branch properties. Yes they may be
harder to model, and I concede that.
And there is an intentionally weakened version for study, which uses
the same S-box and the same ADD-ROTATE-XOR structure (but works on
8-bit words and has a smaller key size). This should lend some insight
into the properties of the proposed structure.
Also it will be possible to implement the same for 64-bit words instead
of 32-bit words with little change and decrease in performance (This
would double the speed, state and key size!) Again, this is just a
research proposal/report. Thats all there is to it. The only plan is to
study a new structure and learn from it. It in no way intends to
replace AES in Counter mode or AES Hash or any other cipher in any way.
Thanks again.

[ashish.s...@gmail.com]

And Yes, the design is not some random assortment of x86 instructions
:),
there has been some thought put into it :)

[tomst...@gmail.com]

ashish.s...@gmail.com wrote:
> "No Offense"...None Taken. The whole idea was to come up with an easy
> to analyze structure (and easy to memorize!) quite different to the
> Wide Trail Design Strategy. The idea here was to use active bits to
> offer excellent diffussion and branch properties. Yes they may be
> harder to model, and I concede that.

RC5 is extremely simple to memorize yet its not ideal for studying [or
designing] something according to higher principles [e.g.apply lessons
learned long ago]

> And there is an intentionally weakened version for study, which uses
> the same S-box and the same ADD-ROTATE-XOR structure (but works on
> 8-bit words and has a smaller key size). This should lend some insight
> into the properties of the proposed structure.

Unfortunately that isn't always the case and not only that but that's
the point of a paper of this sort. To present new results. Anyone can
cram three ideas together and call it a new design, what makes it
interesting are the results you can present. E.g. provable qualities.

My point mostly is that it's on you as the submitter to prove these
qualities. Not us the reader to assume them as true [or even what the
specific qualities are].

Tom

[con...@matmail.com]

ashish.s...@gmail.com wrote:
> Hi,
>
> My paper has been invited to SAM 06.
>
> The paper titled "FastFlex : A New Fast and Flexible Cryptographic
> Function" deals with the design of a new cryptographic primitive which
> is then used to construct a Stream Cipher (192-bit) and a Hash Function
> (256-bit), both faster than AES in Counter mode and AES Hash by a
> factor of at least two. It also has a smaller memory footprint as
> compared t0 AES (One-Fourth or better).
> The paper can be accessed at
> http://fastflex.sourceforge.net/files/FastFlex-SAM.pdf
>

Can you provide a C implementation of the hash function?

Scott

[Phil Carmody]

ashish.s...@gmail.com writes:
> Hi,
>
> My paper has been invited to SAM 06.
>
> The paper titled "FastFlex : A New Fast and Flexible Cryptographic
> Function" deals with the design of a new cryptographic primitive which
> is then used to construct a Stream Cipher (192-bit) and a Hash Function
> (256-bit), both faster than AES in Counter mode and AES Hash by a
> factor of at least two. It also has a smaller memory footprint as
> compared t0 AES (One-Fourth or better).
> The paper can be accessed at
> http://fastflex.sourceforge.net/files/FastFlex-SAM.pdf

How does its speed compare to Salsa, upon which it is based?

Do any of the crypto-librarians out there known if there are
there well-trusted primitives that use integer multiplication
in a scheme similar to the following?

{ Y_i, Y_j } = { (Y_i * Y_j)_low, (Y_i * Y_j)_high }

I have a brain-stem distrust of integer multiplication in
such contexts, as it throws too much away. However, as it's
a hashing core that's not necessarily fatal, as long as
these values are combined in an intricate-enough manner.

Phil
--
What is it: is man only a blunder of God, or God only a blunder of man?
-- Friedrich Nietzsche (1844-1900), The Twilight of the Gods

[con...@matmail.com]

Phil Carmody wrote:
> ashish.s...@gmail.com writes:
> > Hi,
> >
> > My paper has been invited to SAM 06.
> >
> > The paper titled "FastFlex : A New Fast and Flexible Cryptographic
> > Function" deals with the design of a new cryptographic primitive which
> > is then used to construct a Stream Cipher (192-bit) and a Hash Function
> > (256-bit), both faster than AES in Counter mode and AES Hash by a
> > factor of at least two. It also has a smaller memory footprint as
> > compared t0 AES (One-Fourth or better).
> > The paper can be accessed at
> > http://fastflex.sourceforge.net/files/FastFlex-SAM.pdf
>
> How does its speed compare to Salsa, upon which it is based?
>
> Do any of the crypto-librarians out there known if there are
> there well-trusted primitives that use integer multiplication
> in a scheme similar to the following?
>
> { Y_i, Y_j } = { (Y_i * Y_j)_low, (Y_i * Y_j)_high }
>

No, but I've seen bad designs that have used such a strategy
(such as a chaotic hash function that was trivially broken, see crypto
eprint library)

> I have a brain-stem distrust of integer multiplication in
> such contexts, as it throws too much away. However, as it's
> a hashing core that's not necessarily fatal, as long as
> these values are combined in an intricate-enough manner.
>

I also distrust it. There have been a lot of bad designs that use
integer multiplication (though RC6 seems to have used the multiply
well).

But the real problem with his design is,
as you say, the values needed to be combined in an intricate-enough
manner. His design is easily seen to be insecure without looking at
the internals, because of the way he combines the data. One can
trivially compute collisions.

Scott

[ashish.s...@gmail.com]

Yes. The Hash has a severe flaw in the way the data is combined.
Withdrew it off the webpage. Wuill be using a Tree - XOR structure
(Which again will be faster than AES Hash)

Hash = Hash( Hash(M0) ^ Hash(M1) ^ Hash(M2) ^ Hash(M3)) ^ Hash(
Hash(M4) ^.....) ^

Conservative???

Thx Again!

Ashish Sharma

[ashish.s...@gmail.com]

It compares favourably to Salsa20/20 on which it is based in terms of
speed. Dr. DJB has posted a reduced round version Salsa20/8 which is
impressively fast but has little security margin.

FastFlex is faster than Salsa20/20 (Nearly the same security margin). A
reduced round version QuickFlex is also discused...but too early for
it.
Thx again.

Ashish Sharma

[con...@matmail.com]

That also looks insecure: certain permutations of the blocks will cause
a collision.

May I ask you, what experience do you have breaking hash functions?
Which
hash functions have you broken? If the answer is none, then maybe you
should
gain a little experience with attacks before trying to build one...

Scott

[David Wagner]

>Hash = Hash( Hash(M0) ^ Hash(M1) ^ Hash(M2) ^ Hash(M3)) ^ Hash(
>Hash(M4) ^.....) ^

Not a good choice. If Hash() produces n-bit outputs, there is an
attack that requires only 2^{n/3} time. I'm pretty sure there are
faster attacks, too, but I haven't tried to work out the details.

David Wagner, "A Generalized Birthday Problem" (CRYPTO'92).
http://www.cs.berkeley.edu/~daw/papers/genbday.html

I concur with the recommendation expressed elsewhere in this thread:
you need a lot of experience in hash function cryptanalysis before you
are qualified to design new hash functions.

[ashish.s...@gmail.com]

I have no experience in designing Hash Functions. I am 20, and this is
an undergrad college project.

I do however think (and have read) that an N-way XOR tree is a decent
yet fast way to make a compression function.

Hash(Hash( Hash(M0.C0) ^ ...Hash(M(N-1).C(N-1)) ^ ...).D1) ^ (Hash(
Hash(MN.CN) ^...)

Where C, D...are constants concatenated to the blocks before passing
them through the
Hash( ) transformation.

Is this construction OK?

[David Wagner]

>I have no experience in designing Hash Functions.

I'll say it a third time: you need experience in cryptanalyzing hash
functions before you will be qualified to design new hash functions.
If you just want to design them for fun, that's one thing, but then you
should clearly label them as "this is just for my own personal amusement
and no one else should even think of using this". On the other hand,
if you're hoping you can come up with the next successful hash function,
well, that's probably not a realistic goal, without some experience at
hash cryptanalysis.

>I do however think (and have read) that an N-way XOR tree is a decent
>yet fast way to make a compression function.
>
>Hash(Hash( Hash(M0.C0) ^ ...Hash(M(N-1).C(N-1)) ^ ...).D1) ^ (Hash(
>Hash(MN.CN) ^...)
>

>Is this construction OK?

I think I already answered this question. My answer is still the same.
I'm saying that this is not a very good way to build a compression function,
in the sense that there are attacks that are faster than what you'd expect
from an ideal n-bit hash.

You don't have to take my word on it. Read the paper I posted a pointer
to, and you can learn for yourself why.

If you think you read it somewhere, feel free to dig up where you read it
and post the reference here.

[con...@matmail.com]

David Wagner wrote:
> >Hash = Hash( Hash(M0) ^ Hash(M1) ^ Hash(M2) ^ Hash(M3)) ^ Hash(
> >Hash(M4) ^.....) ^
>
> Not a good choice. If Hash() produces n-bit outputs, there is an
> attack that requires only 2^{n/3} time. I'm pretty sure there are
> faster attacks, too, but I haven't tried to work out the details.
>
> David Wagner, "A Generalized Birthday Problem" (CRYPTO'92).
> http://www.cs.berkeley.edu/~daw/papers/genbday.html
>

There are simpler attacks than that for this construct. For example,
swap
M0 and M1 .

Scott

[con...@matmail.com]

ashish.s...@gmail.com wrote:
> FastFlex is faster than Salsa20/20 (Nearly the same security margin).

I'm going to open my mouth and display my ignorance here, since this
has been
bothering me for a while. But is salsa20 really a hash function? Hash
functions
are supposed to take an arbitrary length input and produce a fixed
length output.
I don't see any specification of salsa20 that takes an arbitrary length
input. What
am I missing?

Scott

[D. J. Bernstein]

con...@matmail.com wrote:
> But is salsa20 really a hash function?

The Salsa20 hash function is an extremely low-level cryptographic
primitive. It isn't meant to be a compression function, or a universal
hash function, or a collision-resistant hash function, or any of the
other (often incompatible) user-oriented types of hash functions that
one normally encounters. On the other hand, in the hands of a cipher
designer, it can be used to build fairly efficient user-oriented
functions, such as the Salsa20 stream cipher.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

[ashish.s...@gmail.com]

Now that you are here Dr DJB, Are there any proofs regarding Salsa20
security?
We are being taught Salsa20 and Trivium here in College of all the
proposals to eStream (Innovative Design I guess)? But when using
Salsa20 as a Low Level Crypto Primitive, could there not be any i/ps
for which a large part of the active bits cancel out? Logically I get
that the chances of this happening are too low to be significant, but
any proofs?
Also how does Salsa20 rate when in comes to more conventional measures
such as branch number and SAC? I folwed the discussion here at
Sci.crypt a year ago (Some heated exchanges :) ), but again no
conclusions.
The Salsa20 security and design documents are great to read, but not
very convincing!

I have not come accross any rlevant analysis of Salsa20 like structures
anywhere. If there are many, could you lease point me to some.
If no, do you plan to give any proofs regarding these in the near
future? If yes, plz do letme know.

Kind regards
Ashish Sharma

[con...@matmail.com]

Hmm, so it isn't really a hash function (according to the defn of hash
function
we have in the lierature).
Is it meant to be a one-way function then?
What exactly are the security properites it is meant to have?
(sorry, I haven't looked at your stream cipher yet...)

Scott

[D. J. Bernstein]

It's easy to prove that AES resists various restricted types of attacks.
But these proofs have limited value. Nobody is able to prove that AES
resists _all_ attacks. We _conjecture_ that AES resists all attacks.

ashish.s...@gmail.com wrote:
> Are there any proofs regarding Salsa20 security?

It's easy to prove that Salsa20 resists various restricted types of
attacks. But these proofs have limited value. Nobody is able to prove
that Salsa20 resists _all_ attacks. We _conjecture_ that Salsa20 resists
all attacks.

[tomst...@gmail.com]

D. J. Bernstein wrote:
> ashish.s...@gmail.com wrote:
> > Are there any proofs regarding Salsa20 security?
>
> It's easy to prove that Salsa20 resists various restricted types of
> attacks. But these proofs have limited value. Nobody is able to prove
> that Salsa20 resists _all_ attacks. We _conjecture_ that Salsa20 resists
> all attacks.

Really? What attacks are these? I don't recall reading an actual
proof against any attacks in your papers.

As for the attacks you so casually dismiss for AES ... keep in mind
they plagued in one way or another ... EVERY OTHER BLOCK CIPHER THAT
PRECEDED IT.

Granted they didn't do enough in my opinion to address the saturation
attacks. That said they did address them and so far they don't break
jack squat.

Tom

[D. J. Bernstein]

> Hmm, so it isn't really a hash function (according to the defn of hash
> function we have in the lierature).

What you mean is that it isn't a compression function. Hash functions
are a much broader concept.

> Is it meant to be a one-way function then?

No. The Salsa20 hash function is a low-level tool for cryptographers to
use in building higher-level objects such as stream ciphers and SHA
replacements.

[clark]

On 12 Apr 2006 17:45:17 -0700, tomst...@gmail.com wrote:

>D. J. Bernstein wrote:
>> ashish.s...@gmail.com wrote:
>> > Are there any proofs regarding Salsa20 security?
>>
>> It's easy to prove that Salsa20 resists various restricted types of
>> attacks. But these proofs have limited value. Nobody is able to prove
>> that Salsa20 resists _all_ attacks. We _conjecture_ that Salsa20 resists
>> all attacks.
>
>Really? What attacks are these? I don't recall reading an actual
>proof against any attacks in your papers.
>
>As for the attacks you so casually dismiss for AES ... keep in mind
>they plagued in one way or another ... EVERY OTHER BLOCK CIPHER THAT
>PRECEDED IT.

So these attacks are critically important.

>Granted they didn't do enough in my opinion to address the saturation
>attacks. That said they did address them and so far they don't break
>jack squat.

No... wait a minute... they uh... they don't break anything.

>Tom

Another raving, semi-coherent, yapping poodle, Dr. Bernstein
posted-so-I-have-to-blurt-something-anything posts. Great.

So what's your point?

Or are you just trying to hang on to Bernstein's jock?

[tomst...@gmail.com]

clark wrote:
> >As for the attacks you so casually dismiss for AES ... keep in mind
> >they plagued in one way or another ... EVERY OTHER BLOCK CIPHER THAT
> >PRECEDED IT.
>
> So these attacks are critically important.

And DJ hasn't addressed any of them.

> >Granted they didn't do enough in my opinion to address the saturation
> >attacks. That said they did address them and so far they don't break
> >jack squat.
>
> No... wait a minute... they uh... they don't break anything.

So if you read my whole paragraph you'll see I *disagree* with the
design on that basis. I'm *not* being hypocritical.

Please try to put the entire paragraph into context. Not just the
choice words you want to read.

> Another raving, semi-coherent, yapping poodle, Dr. Bernstein
> posted-so-I-have-to-blurt-something-anything posts. Great.

How is what I wrote semi-coherent? My complaint is very precise. DJB
doesn't concern himself with proofs of security.

And yes, I attack DJB quite a bit. Because he consistently makes the
same mistakes over and over and over again.

If he wants to be a cipher designer he should learn to actually analyze
his design with something he purports to study called "mathematics".

Tom

[noload]

Tom,
You may think you're fooling everyone here. But you're not fooling
anyone, except maybe yourself.
It's very easy to perceive, and I'm sure most everyone here would agree,
that you're extremely jealous of Dr. Bernstein, and that you would give
*anything* to be where he is today, a Professor of Mathematics,
Statistics, and Computer Science, at the University of Illinois at Chicago.
Please stop trying to fool everyone. You insult our intelligence.

[clark]

On 13 Apr 2006 12:13:19 -0700, tomst...@gmail.com wrote:

[...]

>
>And yes, I attack DJB quite a bit. Because he consistently makes the
>same mistakes over and over and over again.

Over and over again... golly.

I think his "mistakes" are in your head and you are somehow obsessed
in an unhealthy way as concerns Dr. Bernstein.

No one else is complaining. Why is that?

>If he wants to be a cipher designer he should learn to actually analyze
>his design with something he purports to study called "mathematics".

Dr. Bernstein, Silverman, and other accomplished mathmaticians have
consistently kicked your ass from one end of this group to the other.

They've proved you wrong and shown that their depth of knowledge far
exceeds yours over and over again, so I don't think you are
qualified to make that kind of out-of-hand statement suggesting Dan
Bernstein needs to take lessons from you on mathematics.

It is most certainly the other way around.

And by the way, he IS a cipher designer as opposed to failed wannabe
loud mouths in this group. Loud mouths like... well... you.

Take a trip over to http://www.ecrypt.eu.org/stream/index.html and
you'll find him in good company with other accomplished cipher
designers.

You can read about *Salsa20 and also find some papers by him as well.

*That was a bit tongue in cheek, because I know you already know about
Salsa20 from when you knee-jerked and jumped to conclusions regarding
Crowley's DC paper on reduced round Salsa20 back in October 2005.