Can I use half of 256 bit key as AES 256 IV?

After some google research, I have found out the IV used in AES 256 bit encryption must be a 128 bit key.

My AES256 encryption is processed with key of random 256 bit key and IV generated of text string.

I am thinking about MD5 to generate such key, but MD5 seems outdated.

So Should it be okay if I use SHA256 generate a 256 bit key than split the hex string of the key equally into 2 parts and use the first part as an IV in AES 256 bit encryption?

So Should it be okay if I use SHA256 generate a 256 bit key than split the hex string of the key equally into 2 parts and use the first part as an IV in AES 256 bit encryption?

No, there are better ways.

First of all, when you create a key you need a cryptographically secure random number generator. If you derive a key from a master secret - sometimes called a seed - you need a key derivation function or KDF. In the latter case you could e.g. use HKDF with a good hash such as SHA-256. In principle you can create e.g. 384 bits output using HKDF - even when using SHA-256, but I don't think that's a good idea, because of the following part of the answer.

Second, reusing a key / IV combination is not a good idea; depending on the mode and message you may leak just some data or all of the message.

In general you can just use an all zero IV if the key is randomly generated for each message. That would be better than reusing part of the key. As indicated, an IV is generally not thought to be secret, so if you use key data as IV implementations may well leak it.'

If you need to encrypt multiple messages with the same key then you could use a synthetic IV or SIV. That way you would only leak data if messages are completely identical, at the cost of some performance, as SIV modes are multi-pass (messages need to be processed twice).

In general though you should just use a randomized IV and send it with the ciphertext. It isn't clear from the question if that has been considered; it would be the most common way of handling the IV generation.

Finally, keys are not alphanumerical; they consist of bits. Each time when a key is translated into text you are opening a security issue. So don't do that: keep keys binary. I'd rather use AES-128 with a fully random key and use the other 128 bits for the IV than revert to using hexadecimals.

Hexadecimals are only useful for human consumption, e.g. during testing or debugging when it comes to secret keys.

I assume you do not reveal this IV. Depends on what you want and what mode you use. IV for AES should be 128 bits for modes like OFB, CBC or CFB but it is usually shorter for modes like CTR or its authenticated variants where the most common way of creating block used to generate the stream would be concatenation of IV (nonce) and counter. There can be many problems with using part of key as IV:

I for once know no huge inherent security risk associated with revealing $E_k(k_{0..|k|/2})$ or $E_k(k_{0..|k|/2} \oplus P)$ or $E_k(k_{0..m} || ctr)$ for some known message $P$ for full AES (Please correct be if I am wrong). These are functions that you might see depending on modes used. Actual usage however may be insecure.

1. Essentially makes your encryption deterministic. So it does not fully hide the message. For modes like CBC or CFB you can detect common prefixes (full block prefixes in the message). For CFB, this can also allow you to deduce relationship between plain texts corresponding to the first divergent blocks, specifically $P_{1_i} \oplus P_{2_i}$ where the cipher texts diverge at $i^{th}$ block. For modes like CTR or OFB, it can be devastating if you ever reuse the key, you can deduce the xor relationship for the entire plain text for those two. This problem persists even if you use MD5 for IV. Hence, it makes it very unsuitable for reuse, even accidently which is easier said than done.

2. In some protocols if an attacker finds a way to obtain $E_k(k_{0..|k|/2})$ e.g by tricking into encrypting $0^{|k|}$ in CBC mode and then tricking them into encrypting $p_i||c_{i}$ where he had obtained $c_{i}$ from previous interaction in order to reveal $E_k(0^{|k|})$, he might trick them into revealing half of the key by asking to decrypt $E_k(0^{|k|})$. This is not my original idea so I suggest you see fgrieu 's answer on Here, see drawback 2.

3. It may be secure to use it if you don't reuse the key or in other similar protocols. For modes like CBC or even ECB with some high entropy (random) messages with no known structure may be OK as well in case you use more than once.