Hashing items of different Bytes but same length would enable a timing attack? I am following this paper which comes highly recommended as a secure Registration/Login system over TLS which uses client side computation for the Password Processing Function (PPF). What my main question is about is how the design prevents account enumeration (an attacker finding out if usernames are valid on the server).

To summarise the final solution in Section 4:


  On the server, each valid user has a different $v$ which is generated by a CSPRNG and is at least 128-bits of random data.
  
  For login, if the user exists, it computes the salt as:
  
  hash( username || domain-name || $v$ ).
  
  If the user does not exist, it computes the salt as:
  
  hash( username || domain-name || $σ$ )
  
  Where σ is a server secret value of 128 bits of random data.


The point of this is that a salt is always returned, regardless of whether the username is valid or not. This prevents an attacker from making many queries to figure out everyone's usernames and it also prevents timing attacks as the computation is always done server side and it takes the same time.

However in the system we have, we do not have usernames so we are replacing the username here with the user's email address instead. Also we have another requirement where our support team needs to change user's email addresses on their behalf if they lose access to them. The design in the paper would appear not to work in that case because the salt is then based on the email address, and hence the PPF computation is also tied to it. So if the user changes their email then their previous salt is no longer valid and they need to re-do the PPF computation which is a nuisance. Also it's much worse if the support team changed the user's email because then they would definitely be locked out of their account.

So my thoughts to resolve this for valid users is to have the salt calculated as:


  Salt = hash( domain-name || padding || $v$ )


And for invalid users the salt would be calculated as:


  Salt = hash( email || domain-name || padding || $σ$ )


So for this to work, emails would be limited to maximum 80 characters. Then the length of email + domain-name + padding would always be 100 Bytes. And for valid users the domain name + padding would also always be 100 Bytes. The padding character could just be a 'P' and everything is always padded to 100 Bytes.

So my main questions:


Is it possible for an attacker to do a timing attack on the network
request with the server to check if an email is valid/invalid?
Will there be a give-away (detectable) timing difference between hashing        the email || domain-name || padding, vs hashing just domain-name || padding if they're both 100 Bytes in length? I.e. does hashing different characters make the computation take longer or go faster.
It is a bad idea to use any user information of host information to generate a salt. Salt should be random.

Use password stretching. Depending on tools available to you considers bcrypt, scrypt, argon2. Then no matter if user exists or not the password stretching can take (depending configuration) substantial time. It will be safe against timing attacks.

Since the stretched password hash will not depend on user ID,  your users will be able to change their IDs (whatever you use as ID - email, user name or anything else) as often as they want. When user ID changes, it will not bve necessary to recalculate the password hash.