To start off, users enter a master password, which a key is then derived from (with a salt from a server) using scrypt, which a key length of 512 bits (the dkLen could be changed, although I would like to keep it to 512 bits/64 bytes for legacy reasons).
On the client-side, I would also like to use AES, which requires 256 bits (or 128/192) keys. My problem is getting a shorter key that is based on the original key.
My current proposal is using PBKDF2 (with HMAC-SHA-256) with a salt from the server (or use the same salt as the master key) to derive a secondary key, which will be recreated every time the user logs in. My problem with this solution is that there is no need for an intensive deriviation, since the original key will already be "secure", therefor having a low iteration count (or even just 1) would be an option. Which could also just be HMAC-SHA-256(master key, salt).
My second solution is simply calculating the SHA-256 of the master key, since using a salt seems overkill for digesting a 512 bits key already. This is simpler since there's no need to store a secondary salt (if not using the master salt). I would prefer this solution but I'm unsure if this is fit for this usage, since the generated hash would be used for AES purposes.
The third solution was to simply slice the master key and take the first half, which would be 256 bits. I was also unsure if this would be recommended.