IV and hmac from shared secret, and replay attacks.

Question

Hello all!
I am working on a client server project where i use the diffi-hellman keyexchange.
both server and client has the secret and can decrypt enc messages from eachother.
Q1:Up to now i have only used a predifiened IV for the 3des cbc cipher. But I would like to generate a IV from the shared secret somhow. Which way is the most secure way to do that?
the way things look now i enc/dec by my self whithout the cipheroutputstream, (got to much trouble whith the cipherbuffers) and just send it over by my self.
I would like to use a SHA1 hmac and send that over whith the msg.
Q2: I now use println for sending, is it ok to first send the enc msg, and then send the hmac after, from security point of view?
Q3: how do i use my shared secre to calculate a sha1 hmac from the msg?
Q4: how do i use a timestamp whith the above cipher and hmac in a secure way to prevent replay attacks?
Sry for the many questions, I have tried for several days to figure some of this stuff out, any help/code is appreciated
/Mike

Answer 1

Bossk wrote:
Thanks for your reply.
I've read most (if not all) .net to java migration threads I could find. None helped me with my problem.
If I understood your reply correct, there are some fundamental flaws in the .NET encrypt/decrypt routines:Yes but I am not aware of any in the code you are using.
>
- the AES blocksize is set to 256 but can only be 128 bitsYour .NET code is using Rijndael which does allow a block size of 256 but your Java code is using AES which does not allow a block size of 256. You need to get a Rijndael implementation from another provider. I suggest you look at BouncyCastle. They may also have an Rfc2898DeriveBytes port.
- ECB mode is used. However, ECB does not use an IV, right? So the .NET classes must be ignoring this parameter.Yes. What I find interesting about the .NET crypt routines is that they (almost) never throw exceptions when illegal or inappropriate parameters are used.
>
I also have the PasswordDerivedBytes class from the thread you linked, when I try to decode using this code it still does not work:.NET class PasswordDerivedBytes is a mess but you actually need an implementation of RFC2898 some of which PasswordDerivedBytes implements. Check with BouncyCastle provider they may have an Rfc2898DeriveBytes class but if not then you need to implement the relevant part of RFC2898. The problem you will have is knowing which of the 5 RFC2898 key generation algorithms is actually uses with the .NET code.