AES as hash function and PRNG

Hello,

for an embedded device (8bit uC) I need encryption, a one way hash
function and a RNG to generate session keys. For encryption I decided
to use AES-128.

In
http://csrc.nist.gov/CryptoToolkit/aes/rijndael/Rijndael-ammended.pdf
Daemen and Rijmen wrote, Rijndael can also be used hash function and
as PRNG. In
http://dimacs.rutgers.edu/Workshops/Practice/slides/shrimpton.ppt
(slide 25) Shrimpton showed 12 ways to use a symetric cipher as hash
function.

In my application there will be 6 to no more than 16 bytes to hash
at once. And they have to remain secret. Due to some restrictions an
initial hash value (Hi) must be considered known and will be constant.
So, I think not all of the 12 ways are suitable:

the 12 ways (here + = xor) with known Hi not better than
H1 = E_Hi(M) + M
H2 = E_Hi(M+Hi) + (M+Hi) H4
H3 = E_Hi(M) + M + Hi H1
H4 = E_Hi(M+Hi) + M
H5 = E_M(Hi) + Hi E_M(Hi)
H6 = E_M(M+Hi) + (M+Hi) E_M(M+Hi) + M
H7 = E_M(Hi) + M + Hi E_M(Hi) + M
H8 = E_M(M+Hi) + Hi E_M(M+Hi)
H9 = E_{M+Hi}(M) + M
H10 = E_{M+Hi}(Hi) + Hi E_{M+Hi}(Hi)
H11 = E_{M+Hi}(M) + Hi E_{M+Hi}(M)
H12 = E_{M+Hi}(Hi) + M

IMHO I can discard H2, H3, H5-H8, H10 and H11. But I don't know which
remaining function is the best one. I would like to use H1, because
it's the easiest. But is it realy one way, with known Hi?
Btw: if there are less than 16 bytes to hash, would a simple padding
with zero bytes be ok?

Another question:
To generate session keys, I need random numbers. Because there is no
true random source, I have to use a PRNG. This PRNG (if it is one)
is invoked only once for every key generation. At the moment I'm
thinking about the following way:

1. Store 128 as random as possible bytes as secret(!) seed at the
   first power up.
2. Collect a few differing values to provide some entropy (won't be
   much, but better than nothing).
3. XOR the entropy values and 16 bytes of the seed.
4. The hash value (using the same known Hi as above) of the result
   will be the random number. (The key will be generated from it.)
5. The random number will be hashed again and stored, overwriting
   the used bytes of the seed. (I don't like the idea to store
   something which was used to generate a key, even though it won't
   be used again.)
6. For the next key generation go back to step 2 and use the next
   16 bytes of the seed.

Would this be all right?

I'm not an expert on cryptography, not even an amateur. So any
suggestions will be appreciated.

Thanks in advance
Mike
Received on Thu Sep 29 21:41:08 2005