I'm developing the login part of my application and I was asking myself how to do it right. My application stores some users' data server-side that must be inaccessible from us, so all the content must be encrypted using AES-256 with a password derived from the user's login password and this key would never leave the user's device. What I thought to implement is PBKDF2-SHA512 and use the first 32 bytes of output as the AES key of the user and the last 32 bytes as the hash to login.
My questions are: How many interactions should I use given that my software will have to work on iPhone and Smartphones in general? (Note that I will force the user to use a password that is 8-char minimum in length, that has at least one uppercase char and a number) What should I use as salt? I was thinking of using the username (that actually is the user's email address) combined with some string that uniquely identifies my application but... What's the best way to do so? Is it useful to do it using a combination of crypto algorithm? For example making a little hash function based on AES so an attacker who has the ability to make custom hardware will have to implement more than one algorithm. How should I save the login hash (the last 32 bytes of PBKDF2-SHA512) in the server's database? I think a simple salted hash (without stretching) would be enough given that the original password is already stretched client-side. If yes, should I use SHA-256 or SHA-512?
EDIT: PBKDF2-SHA512 means PBKDF2 using HMAC using SHA512 (so it doesn't mean SHA512(PBKDF2).
I can't "generate" any random salt. All that I can do is to "derive" it from the login information. I thought something like HMAC-SHA512(email || password, str) where email || password is the string to be hashed and str is a string that uniquely identifies my application being used as HMAC Key. What do you thing about that? Is there a better way to to it?