Crypto Algorithm Evaluation - My hash function

Hi, is someone willing to check out the cryptographic hash function I designed ? Here are the links (I had to write them differently because of the new-user limitation, so change "hxxp" in "http", ":_/" in "://", ",com" in ".com", and "hxxx" in "html") :

-> Delphi language
hxxp:_/rapidshare,com/files/288440983/LEA.pas.hxxx

-> C language
hxxp:_/rapidshare,com/files/288441163/LEA_C.c.hxxx

(note : one of my friends coded the C version, we checked it, the algorithm seems ok but may not be optimized).

Characteristics of the hash function :
- takes data by blocks of 512 bits.
- output of 32 to 512 bits (32, 64, 96, 128, 160,...).
- uses two small tables to work.
- a bit slow though.

Thanks all, and nice forum

Any reason why not to use existing hash functions and CRCs?

Well, it's kind of boring when you always use the same two algorithms ... So why not innovate ? (of course, if I were to do a professional application, I would use the standards, but these will change shortly I believe)
And for the CRC's, these are not cryptographic, so they don't quite interest me.

It's a little hard to evaluate the algorithm solely based on the source code. You have a lot of constants defined, for instance. Without giving an argument why such constants were chosen and how exactly, it's hard to "trust" the algorithm. The same holds for the "mixing" transformations.

There is a competition going on to chose SHA3 standard. All the proposals making in to the second round had to explain all the reasoning of the design.

If you want someone to have a closer look, it is at least necessary to give a clear description of the algorithm. The source code is not enough.

I had written a kind of rfc on my algorithm but I think I lost it (shame on me).
I'll just have to write it down again.
In fact, the constants are - in both tables - defined in a recurrent prime pattern. But I'll explain that in details in the documentation.

Alright here is the start of it (I'm out of battery).
I explained the constants, and part of the mixing operations. I'll work on a more complete rfc in the following days.
Sorry for the bad english by the way, I'm french.

hxxp:_/rapidshare,com/files/288585911/LEA-RFC.pdf.html

(same URL changes as before)

First, there are plenty of reasons not to use your own cryptographic hash function. It's easy to design something you can't break, but harder to design something truly secure. There's nothing wrong with trying to put together your own algorithm just as a logic exercise for yourself, but at the end of the day when you need to use an algorithm, use a real one.

I'm uncertain how your hash function works.
* You define four "boolean functions" (I'm uncertain if you actually want them to be boolean, why would they perform bitwise operations just to return a true/false value?) but don't mention, in step 3, exactly how they are used.
* You don't define exactly how you iteratively enter and exit each round (or internal state as you call it).
* I'm confused as to why you process input in blocks of 512 bits, it seems that you only work on 32 bits at a time.
* Is your use of the word "field" in the last paragraph supposed to be in a mathematical sense? If you've seen the word "field" show up before in, say, the AES S-Boxes, it's because the values come from a very specific mathematical field. "Field" is a very specific mathematical term that requires a set of objects and two operations defined on it (in addition to many other constraints).

No worries, if I need something professional done, I use AES and SHA, of course. You don't want to lose your credit card numbers by using that *** algorithm you designed !
* boolean functions ... I mean by that that the (deterministic) function can be achieved with the 4 logical operators : and, or, xor and not. Alright you'll tell me every feature on a computer is then boolean, but still ...
* Oh, yes I forgot the padding. First, the algorithm processes all the 512-bit blocks that are all part of the message (uhm ... like the block contains only message data). Each block goes through the internal function. Then, it takes the last block (it can be empty if the message has a size congruent to 512 bits), adds a bit "1" at the end of the message (if there is no message left, it adds it at the beginning of the last block), then the remaining block is set to 0. And the last block is sent to the internal function.
* Actually, it looks like I only work on 32 bits at a time, but the particular construction of the internal function does that each bit of the block influences all the other ones, but that relation breaks at the end of each internal function. I should explain why that construction works, I'll do that.
* The field ... yes ... I dunno why I used that term, I should have used "domain", or "range" ... uhm both in fact. I wrote too quickly there, thanks for making note.