AES encryption using a Diffie-Hellman key exchange I have two systems which need to encrypt their communication by AES-128. The key for the AES encryption should be exchanged with the Diffie-Hellman (DH) algorithm.

Now, I've read about DH and got a lot of question marks over my head. These are my questions:


Typically with AES-128, you need a password and a key which will be generated from the password. What exactly will be exchanged with DH, is it the password or the key? In other words, what is the secret that Alice and Bob will calculate?
If I use a 1024 bit prime and a 256 bit private secret for DH, the calculated secret will consist of a lot more than the required 128 bit for AES-128. How can I transform the secret to match the required 128 bit? Is there a standard to do it, because the two systems use different programming languages?


You see, there is a lot of confusion. Maybe you could help me and shed some light on it.
There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other contexts, in particular the one you are talking about, there is no password.

In Diffie-Hellman, computations occur modulo a big prime p, and the resulting shared secret is an integer modulo p, i.e. a value ranging from 0 to p-1. This value has some "structure" so you should not truncate it blindly. The "safe" way is to apply a hash function on an encoding of that value, for instance SHA-256. The hash function output is then what should be used as key (with possible truncation to get the proper length; at that point, this is safe). There are standards which describe such a process in full details.



Of course, you are in the process of reinventing your own homemade kind-of-SSL, and that is a thoroughly bad idea in general (unless you are doing it for pedagogical reasons, e.g. as homework). A really secure protocol will need key exchange, proper symmetric encryption, integrity checks and at least one-sided authentication, so you will have to assemble at least three cryptographic algorithm. Every single detail can doom your security, both in the design and in the implementation. This is hard. It took two decades of hard labour, from hundreds of the best cryptographers, to come up with a decently secure version of SSL. 

So there is a standard, it is called TLS (the "standard" name for SSL).