If you take a look at user_hash_password, you can see that the hashing algorithm being used is SHA512. This is something different than the encryption algorithm though, which in its own could use a hashing algorithm.
The way Drupal 7 encrypts passwords actually is PBKDF2, using SHA512.
PBKDF2 applies a pseudorandom function, such as a cryptographic hash,
cipher, or HMAC to the input password or passphrase along with a salt
value and repeats the process many times to produce a derived key,
which can then be used as a cryptographic key in subsequent
Since lots of passwords can be generated in the blink of an eye by modern hardware, it's all about making an algorithm slow. This means generating rainbow tables becomes more expensive.
The problem with SHA-algorithms is that they can still be generated quite fast on GPUs. Some algorithms, like bcrypt are slow by design, which, in my opinion, means it would be a better fit.
When the standard was written in 2000, the recommended minimum number
of iterations was 1000, but the parameter is intended to be increased
over time as CPU speeds increase.
In Drupal 7: assuming DRUPAL_HASH_COUNT is being used in the default encryption algorithm, 32768 iterations (1 << 15) would be used to encrypt a password. This means encrypting a password is quite slow, hence more secure (compared to just 1 iteration). You can adjust the count with the password_count_log2 variable, with a maximum value of 30 (1073741824 iterations) and a minimum value of 7 (128 iterations).
It's not worth it to change encryption algorithm; just let Drupal do its job.
Update: how it's done in D8: https://drupal.org/node/1850524