Antoine Beaupr : A short history of password hashers
These are notes from my research that led to the publication of the
password hashers article. This article
is more technical than the previous ones and compares the various
cryptographic primitives and algorithms used in the various software I
have reviewed. The criteria for inclusion on this list is fairly
vague: I mostly included a password hasher if it was significantly
different from the previous implementations in some way, and I have
included all the major ones I could find as well.
The first password hashers
Nic Wolff claims to be the first to have written such a
program, all the way back in 2003. Back then the hashing algorithm
was MD5, although Wolff has now updated the algorithm to
use SHA-1 and still maintains his webpage for public use. Another
ancient but unrelated implementation, is the Standford University
Applied Cryptography's pwdhash software. That implementation
was published in 2004 and unfortunately, that implementation was
not updated and still uses MD5 as an hashing algorithm, but at least
it uses HMAC to generate tokens, which makes the use
of rainbow tables impractical. Those implementations are the
simplest password hashers: the inputs are simply the site URL and a
password. So the algorithms are, basically, for Wolff's:
The first password hashers
Nic Wolff claims to be the first to have written such a
program, all the way back in 2003. Back then the hashing algorithm
was MD5, although Wolff has now updated the algorithm to
use SHA-1 and still maintains his webpage for public use. Another
ancient but unrelated implementation, is the Standford University
Applied Cryptography's pwdhash software. That implementation
was published in 2004 and unfortunately, that implementation was
not updated and still uses MD5 as an hashing algorithm, but at least
it uses HMAC to generate tokens, which makes the use
of rainbow tables impractical. Those implementations are the
simplest password hashers: the inputs are simply the site URL and a
password. So the algorithms are, basically, for Wolff's:
token = base64(SHA1(password + domain))
And for Standford's PwdHash:
token = base64(HMAC(MD5, password, domain)))
SuperGenPass
Another unrelated implementation that is still around
is supergenpass is a bookmarklet that was created around 2007,
originally using MD5 as well but now supports SHA512 now although
still limited to 24 characters like MD5 (which needlessly limits
the entropy of the resulting password) and still defaults MD5
with not enough rounds (10, when key derivation recommendations
are more generally around 10 000, so that it's slower to bruteforce).
Note that Chris Zarate, the supergenpass author, actually credits Nic
Wolff as the inspiration for his implementation. Supergenpass is still
in active development and is available for the browser (as
a bookmarklet) or mobile (as an webpage). Supergenpass allows
you to modify the password length, but also add an extra profile
secret which adds to the password and generates a
personalized identicon presumably to prevent phishing but it also
introduces the interesting protection, the profile-specific secret
only found later in Password Hasher Plus. So
the Supergenpass algorithm looks something like this:
token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
The Wijjo Password Hasher
Another popular implementation is the Wijjo Password
Hasher, created around 2006. It was probably the first shipped as
a browser extension which greatly improved the security of the
product as users didn't have to continually download the software on
the fly. Wijjo's algorithm also improved on the above algorithms, as
it uses HMAC-SHA1 instead of plain SHA-1 or HMAC-MD5, which makes it
harder to recover the plaintext. Password Hasher allows you to set
different password policies (use digits, punctuation, mixed case,
special characters and password length) and saves the site names it
uses for future reference. It also happens that the Wijjo Password
Hasher, in turn, took its inspiration on different
project, hashapass.com, created in 2006 and also based on
HMAC-SHA-1. Indeed, hashapass "can easily be generated on almost
any modern Unix-like system using the following command line pattern":
echo -n parameter \
openssl dgst -sha1 -binary -hmac password \
openssl enc -base64 \
cut -c 1-8
So the algorithm here is obviously:
token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
... although in the case of Password Hasher, there is a special
routine that takes the token and inserts random characters in locations
determined by the sum of the values of the characters in the token.
Password Hasher Plus
Years later, in 2010, Eric Woodruff ported the Wijjo Password Hasher
to Chrome and called it
Password Hasher Plus.
Like the original Password Hasher, the "plus" version also keeps those
settings in the extension and uses HMAC-SHA-1 to generate the
password, as it is designed to be backwards-compatible with the Wijjo
Password Hasher. Woodruff did add one interesting feature: a
profile-specific secret key that gets mixed in to create the security
token, like what SuperGenPass does now. Stealing the master password is therefore not enough to
generate tokens anymore. This solves one security concern with
Password Hasher: an hostile page could watch your keystrokes and steal
your master password and use it to derive passwords on other
sites. Having a profile-specific secret key, not accessible to the
site's Javascript works around that issue, but
typing the master password directly in the password field, while
convenient, is just a bad idea, period. The final
algorithm looks something like:
token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
Honestly, that seems rather strange, but it's what I read from the
source code, which is available only after decompressing the extension
nowadays. I would have expected the simplest version:
token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain + ":" + counter))
The idea here would be "hide" the master password from bruteforce
attacks as soon as possible... But maybe this is all equivalent.
Regardless, Password Hasher Plus then takes the token and applies the
same special character insertion routine as the Password Hasher.
LessPass
Last year, Guillaume Vincent a french self-described "humanist and
scuba diving fan" released the lesspass extension for Chrome,
Firefox and Android. Lesspass introduces several interesting
features. It is probably the first to include
a commandline version. It also uses a more robust key
derivation algorithm (PBKDF2) and takes into account the username
on the site, allowing multi account support. The original release
(version 1) used only 8192 rounds which is
now considered too low. In the bug report it was interesting
to note that LessPass couldn't do the usual practice of running the
key derivation for 1 second to determine the number of rounds needed
as the results need to be deterministic.
At first glance, the LessPass source code
seems clear and easy to read which is always a good sign, but of
course, the devil is in the details. One key feature that is missing
from Password Hasher Plus is the profile-specific seed, although it
should be impossible, for a hostile web page to steal keystrokes
from a browser extension, as far as I know.
The algorithm then gets a little more interesting:
entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
where
rounds=10000
length=32
entropy is then used to pick characters to match the chosen profile.
Regarding code readability, I got quickly confused by
the PBKDF2 implementation: SubtleCrypto.ImportKey() doesn't
seem to support PBKDF2 in the API, yet it's how it is used there... Is
it just something to extract key material? We see later what looks
like a more standard AES-based PBKDF2 implementation, but this code
looks just strange to me. It could be me unfamilarity with newer
Javascript coding patterns, however.
There is also a lesspass-specific character picking routing that
is also not base64, and different from the original Password Hasher
algorithm.
Master Password
A review of password hashers would hardly be complete without
mentioning the Master Password and
its elaborate algorithm. While the applications surrounding the
project are not as refined (there is no web browser plugin and
the web interface can't be easily turned into a bookmarklet), the
algorithm has been well developed. Of all the password managers
reviewed here, Master Password uses one of the strongest key
derivation algorithms out there, scrypt:
key = scrypt( password, salt, cost, size, parallelization, length )
where
salt = "com.lyndir.masterpassword" + len(username) + name
cost = 32768
size = 8
parallelization = 2
length = 64
entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
Master Password the uses one of 6 sets of "templates" specially
crafted to be "easy for a user to read from a screen and type using a
keyboard or smartphone" and "compatible with most site's password
policies", our "transferable" criteria defined
in the first passwords article. For example, the default template
mixes vowels, consonants, numbers and symbols, but carefully avoiding
possibly visibly similar characters like O and 0 or i and 1
(although it does mix 1 and l, oddly enough).
The main strength of Master Password seems to be the clear definition
of its algorithm (although Hashpass.com does give out OpenSSL
commandline examples...), which led to its reuse in another
application called freepass. The Master Password app also
doubles as a stateful password manager...
Other implementations
I have also considered including easypasswords, which uses
PBKDF2-HMAC-SHA1, in my list of recommendations. I discovered only
recently that the author wrote a detailed review of many more
password hashers and scores them according to their relative
strength. In the end, I ended up covering more LessPass since the
design is very similar and LessPass does seem a bit more
usable. Covering LessPass also allowed me to show the contrast and
issues regarding the algorithm changes, for example.
It is also interesting to note that the EasyPasswords author
has criticized the Master Password algorithm quite severely:
[...] scrypt isn t being applied correctly. The initial scrypt hash
calculation only depends on the username and master password. The
resulting key is combined with the site name via SHA-256 hashing
then. This means that a website only needs to break the SHA-256
hashing and deduce the intermediate key as long as the username
doesn t change this key can be used to generate passwords for other
websites. This makes breaking scrypt unnecessary[...]
During a discussion with the Master Password author, he outlined that
"there is nothing "easy" about brute-force deriving a 64-byte key
through a SHA-256 algorithm." SHA-256 is used in the last stage
because it is "extremely fast". scrypt is used as a key derivation
algorithm to generate a large secret and is "intentionnally slow":
"we don't want it to be easy to reverse the master password from a
site password". "But it' unnecessary for the second phase because
the input to the second phase is so large. A master password is tiny,
there are only a few thousand or million possibilities to try. A
master key is 8^64, the search space is huge. Reversing that doesn't
need to be made slower. And it's nice for the password generation to
be fast after the key has been prepared in-memory so we can display
site passwords easily on a mobile app instead of having to lock the UI
a few seconds for every password."
Finally, I considered covering Blum's Mental Hash
(also covered here and elsewhere). This consists of an algorithm
that can basically be ran by the human brain directly. It's not for
the faint of heart, however: if I understand it correctly, it will
require remembering a password that is basically a string of 26
digits, plus compute modulo arithmetics on the outputs. Needless to
say, most people don't do modulo arithmetics every day...
token = base64(SHA1(password + domain))
token = base64(HMAC(MD5, password, domain)))
token = base64(SHA512(password + profileSecret + ":" + domain, rounds))
The Wijjo Password Hasher
Another popular implementation is the Wijjo Password
Hasher, created around 2006. It was probably the first shipped as
a browser extension which greatly improved the security of the
product as users didn't have to continually download the software on
the fly. Wijjo's algorithm also improved on the above algorithms, as
it uses HMAC-SHA1 instead of plain SHA-1 or HMAC-MD5, which makes it
harder to recover the plaintext. Password Hasher allows you to set
different password policies (use digits, punctuation, mixed case,
special characters and password length) and saves the site names it
uses for future reference. It also happens that the Wijjo Password
Hasher, in turn, took its inspiration on different
project, hashapass.com, created in 2006 and also based on
HMAC-SHA-1. Indeed, hashapass "can easily be generated on almost
any modern Unix-like system using the following command line pattern":
echo -n parameter \
openssl dgst -sha1 -binary -hmac password \
openssl enc -base64 \
cut -c 1-8
So the algorithm here is obviously:
token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
... although in the case of Password Hasher, there is a special
routine that takes the token and inserts random characters in locations
determined by the sum of the values of the characters in the token.
Password Hasher Plus
Years later, in 2010, Eric Woodruff ported the Wijjo Password Hasher
to Chrome and called it
Password Hasher Plus.
Like the original Password Hasher, the "plus" version also keeps those
settings in the extension and uses HMAC-SHA-1 to generate the
password, as it is designed to be backwards-compatible with the Wijjo
Password Hasher. Woodruff did add one interesting feature: a
profile-specific secret key that gets mixed in to create the security
token, like what SuperGenPass does now. Stealing the master password is therefore not enough to
generate tokens anymore. This solves one security concern with
Password Hasher: an hostile page could watch your keystrokes and steal
your master password and use it to derive passwords on other
sites. Having a profile-specific secret key, not accessible to the
site's Javascript works around that issue, but
typing the master password directly in the password field, while
convenient, is just a bad idea, period. The final
algorithm looks something like:
token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
Honestly, that seems rather strange, but it's what I read from the
source code, which is available only after decompressing the extension
nowadays. I would have expected the simplest version:
token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain + ":" + counter))
The idea here would be "hide" the master password from bruteforce
attacks as soon as possible... But maybe this is all equivalent.
Regardless, Password Hasher Plus then takes the token and applies the
same special character insertion routine as the Password Hasher.
LessPass
Last year, Guillaume Vincent a french self-described "humanist and
scuba diving fan" released the lesspass extension for Chrome,
Firefox and Android. Lesspass introduces several interesting
features. It is probably the first to include
a commandline version. It also uses a more robust key
derivation algorithm (PBKDF2) and takes into account the username
on the site, allowing multi account support. The original release
(version 1) used only 8192 rounds which is
now considered too low. In the bug report it was interesting
to note that LessPass couldn't do the usual practice of running the
key derivation for 1 second to determine the number of rounds needed
as the results need to be deterministic.
At first glance, the LessPass source code
seems clear and easy to read which is always a good sign, but of
course, the devil is in the details. One key feature that is missing
from Password Hasher Plus is the profile-specific seed, although it
should be impossible, for a hostile web page to steal keystrokes
from a browser extension, as far as I know.
The algorithm then gets a little more interesting:
entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
where
rounds=10000
length=32
entropy is then used to pick characters to match the chosen profile.
Regarding code readability, I got quickly confused by
the PBKDF2 implementation: SubtleCrypto.ImportKey() doesn't
seem to support PBKDF2 in the API, yet it's how it is used there... Is
it just something to extract key material? We see later what looks
like a more standard AES-based PBKDF2 implementation, but this code
looks just strange to me. It could be me unfamilarity with newer
Javascript coding patterns, however.
There is also a lesspass-specific character picking routing that
is also not base64, and different from the original Password Hasher
algorithm.
Master Password
A review of password hashers would hardly be complete without
mentioning the Master Password and
its elaborate algorithm. While the applications surrounding the
project are not as refined (there is no web browser plugin and
the web interface can't be easily turned into a bookmarklet), the
algorithm has been well developed. Of all the password managers
reviewed here, Master Password uses one of the strongest key
derivation algorithms out there, scrypt:
key = scrypt( password, salt, cost, size, parallelization, length )
where
salt = "com.lyndir.masterpassword" + len(username) + name
cost = 32768
size = 8
parallelization = 2
length = 64
entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
Master Password the uses one of 6 sets of "templates" specially
crafted to be "easy for a user to read from a screen and type using a
keyboard or smartphone" and "compatible with most site's password
policies", our "transferable" criteria defined
in the first passwords article. For example, the default template
mixes vowels, consonants, numbers and symbols, but carefully avoiding
possibly visibly similar characters like O and 0 or i and 1
(although it does mix 1 and l, oddly enough).
The main strength of Master Password seems to be the clear definition
of its algorithm (although Hashpass.com does give out OpenSSL
commandline examples...), which led to its reuse in another
application called freepass. The Master Password app also
doubles as a stateful password manager...
Other implementations
I have also considered including easypasswords, which uses
PBKDF2-HMAC-SHA1, in my list of recommendations. I discovered only
recently that the author wrote a detailed review of many more
password hashers and scores them according to their relative
strength. In the end, I ended up covering more LessPass since the
design is very similar and LessPass does seem a bit more
usable. Covering LessPass also allowed me to show the contrast and
issues regarding the algorithm changes, for example.
It is also interesting to note that the EasyPasswords author
has criticized the Master Password algorithm quite severely:
[...] scrypt isn t being applied correctly. The initial scrypt hash
calculation only depends on the username and master password. The
resulting key is combined with the site name via SHA-256 hashing
then. This means that a website only needs to break the SHA-256
hashing and deduce the intermediate key as long as the username
doesn t change this key can be used to generate passwords for other
websites. This makes breaking scrypt unnecessary[...]
During a discussion with the Master Password author, he outlined that
"there is nothing "easy" about brute-force deriving a 64-byte key
through a SHA-256 algorithm." SHA-256 is used in the last stage
because it is "extremely fast". scrypt is used as a key derivation
algorithm to generate a large secret and is "intentionnally slow":
"we don't want it to be easy to reverse the master password from a
site password". "But it' unnecessary for the second phase because
the input to the second phase is so large. A master password is tiny,
there are only a few thousand or million possibilities to try. A
master key is 8^64, the search space is huge. Reversing that doesn't
need to be made slower. And it's nice for the password generation to
be fast after the key has been prepared in-memory so we can display
site passwords easily on a mobile app instead of having to lock the UI
a few seconds for every password."
Finally, I considered covering Blum's Mental Hash
(also covered here and elsewhere). This consists of an algorithm
that can basically be ran by the human brain directly. It's not for
the faint of heart, however: if I understand it correctly, it will
require remembering a password that is basically a string of 26
digits, plus compute modulo arithmetics on the outputs. Needless to
say, most people don't do modulo arithmetics every day...
echo -n parameter \
openssl dgst -sha1 -binary -hmac password \
openssl enc -base64 \
cut -c 1-8
token = base64(HMAC(SHA1, password, domain + ":" + counter)))[:8]
token = base64(HMAC(SHA1, password, base64(HMAC(SHA1, profileSecret, domain + ":" + counter))))
token = base64(HMAC(SHA1, HMAC(SHA1, profileSecret, password), domain + ":" + counter))
LessPass
Last year, Guillaume Vincent a french self-described "humanist and
scuba diving fan" released the lesspass extension for Chrome,
Firefox and Android. Lesspass introduces several interesting
features. It is probably the first to include
a commandline version. It also uses a more robust key
derivation algorithm (PBKDF2) and takes into account the username
on the site, allowing multi account support. The original release
(version 1) used only 8192 rounds which is
now considered too low. In the bug report it was interesting
to note that LessPass couldn't do the usual practice of running the
key derivation for 1 second to determine the number of rounds needed
as the results need to be deterministic.
At first glance, the LessPass source code
seems clear and easy to read which is always a good sign, but of
course, the devil is in the details. One key feature that is missing
from Password Hasher Plus is the profile-specific seed, although it
should be impossible, for a hostile web page to steal keystrokes
from a browser extension, as far as I know.
The algorithm then gets a little more interesting:
entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
where
rounds=10000
length=32
entropy is then used to pick characters to match the chosen profile.
Regarding code readability, I got quickly confused by
the PBKDF2 implementation: SubtleCrypto.ImportKey() doesn't
seem to support PBKDF2 in the API, yet it's how it is used there... Is
it just something to extract key material? We see later what looks
like a more standard AES-based PBKDF2 implementation, but this code
looks just strange to me. It could be me unfamilarity with newer
Javascript coding patterns, however.
There is also a lesspass-specific character picking routing that
is also not base64, and different from the original Password Hasher
algorithm.
Master Password
A review of password hashers would hardly be complete without
mentioning the Master Password and
its elaborate algorithm. While the applications surrounding the
project are not as refined (there is no web browser plugin and
the web interface can't be easily turned into a bookmarklet), the
algorithm has been well developed. Of all the password managers
reviewed here, Master Password uses one of the strongest key
derivation algorithms out there, scrypt:
key = scrypt( password, salt, cost, size, parallelization, length )
where
salt = "com.lyndir.masterpassword" + len(username) + name
cost = 32768
size = 8
parallelization = 2
length = 64
entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
Master Password the uses one of 6 sets of "templates" specially
crafted to be "easy for a user to read from a screen and type using a
keyboard or smartphone" and "compatible with most site's password
policies", our "transferable" criteria defined
in the first passwords article. For example, the default template
mixes vowels, consonants, numbers and symbols, but carefully avoiding
possibly visibly similar characters like O and 0 or i and 1
(although it does mix 1 and l, oddly enough).
The main strength of Master Password seems to be the clear definition
of its algorithm (although Hashpass.com does give out OpenSSL
commandline examples...), which led to its reuse in another
application called freepass. The Master Password app also
doubles as a stateful password manager...
Other implementations
I have also considered including easypasswords, which uses
PBKDF2-HMAC-SHA1, in my list of recommendations. I discovered only
recently that the author wrote a detailed review of many more
password hashers and scores them according to their relative
strength. In the end, I ended up covering more LessPass since the
design is very similar and LessPass does seem a bit more
usable. Covering LessPass also allowed me to show the contrast and
issues regarding the algorithm changes, for example.
It is also interesting to note that the EasyPasswords author
has criticized the Master Password algorithm quite severely:
[...] scrypt isn t being applied correctly. The initial scrypt hash
calculation only depends on the username and master password. The
resulting key is combined with the site name via SHA-256 hashing
then. This means that a website only needs to break the SHA-256
hashing and deduce the intermediate key as long as the username
doesn t change this key can be used to generate passwords for other
websites. This makes breaking scrypt unnecessary[...]
During a discussion with the Master Password author, he outlined that
"there is nothing "easy" about brute-force deriving a 64-byte key
through a SHA-256 algorithm." SHA-256 is used in the last stage
because it is "extremely fast". scrypt is used as a key derivation
algorithm to generate a large secret and is "intentionnally slow":
"we don't want it to be easy to reverse the master password from a
site password". "But it' unnecessary for the second phase because
the input to the second phase is so large. A master password is tiny,
there are only a few thousand or million possibilities to try. A
master key is 8^64, the search space is huge. Reversing that doesn't
need to be made slower. And it's nice for the password generation to
be fast after the key has been prepared in-memory so we can display
site passwords easily on a mobile app instead of having to lock the UI
a few seconds for every password."
Finally, I considered covering Blum's Mental Hash
(also covered here and elsewhere). This consists of an algorithm
that can basically be ran by the human brain directly. It's not for
the faint of heart, however: if I understand it correctly, it will
require remembering a password that is basically a string of 26
digits, plus compute modulo arithmetics on the outputs. Needless to
say, most people don't do modulo arithmetics every day...
entropy = PBKDF2(SHA256, masterPassword, domain + username + counter, rounds, length)
where
rounds=10000
length=32
key = scrypt( password, salt, cost, size, parallelization, length )
where
salt = "com.lyndir.masterpassword" + len(username) + name
cost = 32768
size = 8
parallelization = 2
length = 64
entropy = hmac-sha256(key, "com.lyndir.masterpassword" + len(domain) + domain + counter )
O and 0 or i and 1
(although it does mix 1 and l, oddly enough).
The main strength of Master Password seems to be the clear definition
of its algorithm (although Hashpass.com does give out OpenSSL
commandline examples...), which led to its reuse in another
application called freepass. The Master Password app also
doubles as a stateful password manager...
Debian LTS
February marked the 22nd month I contributed to 
Just over 2 years ago, I 
As mentioned in my 
Github recently drafted an update to their Terms Of Service. The new TOS
is potentially very bad for copylefted Free Software. It potentially
neuters it entirely, so GPL licensed software hosted on Github has an
implicit BSD-like license. I'll leave the full analysis to the lawyers,
but see 
Please use 
Here is my monthly update covering what I have been doing in the free software world (
Previously: 
Once again, I'm making an announcement mainly for my local circle of friends and (gasp!) followers. For those of you over 100Km away from Mexico City, please disregard this message.
Back in July 2015, and after two years of hard work, my university 
The 
Following the 
The x-axis is seconds used for the encode (note the logarithmic scale;
placebo takes 200 250 times as long as ultrafast).
The y-axis is SSIM dB, so up and to the left is better. The blue line is
8-bit, and the red line is 10-bit. (I ran most encodes five times and
averaged the results, but it doesn't really matter, due to the logarithmic
scale.)
The results are actually much stronger than I assumed; if you run on
(8-bit) ultrafast or superfast, you should stay with 8-bit, but from there
on, 10-bit is on the Pareto frontier. Actually, 10-bit veryfast (18.187 dB)
is better than 8-bit medium (18.111 dB), while being four times as fast!
But not all of us have a relation to dB quality, so I chose to also do a
test that maybe is a bit more intuitive, centered around bitrate needed for
constant quality. I locked quality to 18 dBm, ie., for each preset, I
adjusted the bitrate until the SSIM showed 18.000 dB plus/minus 0.001 dB.
(Note that this means faster presets get less of a speed advantage, because
they need higher bitrate, which means more time spent entropy coding.)
Then I measured the encoding time (again five times) and graphed the results:
x-axis is again seconds, and y-axis is bitrate needed in kbit/sec, so lower
and to the left is better. Blue is again 8-bit and red is again 10-bit.
If the previous graph was enough to make me intrigued, this is enough to make
me excited. In general, 10-bit gives 20-30% lower bitrate for the same
quality and CPU usage! (Compare this with the supposed up to 50% benefits
of HEVC over H.264, given infinite CPU usage.) The most dramatic example
is when comparing the medium presets directly, where 10-bit runs at
2648 kbit/sec versus 3715 kbit/sec (29% lower bitrate!) and is only 5%
slower. As one progresses towards the slower presets, the gap is somewhat
narrowed (placebo is 27% slower and only 24% lower bitrate), but in the
realistic middle range, the difference is quite marked. If you run 3 Mbit/sec
at 10-bit, you get the quality of 4 Mbit/sec at 8-bit.
So is 10-bit H.264 a no-brainer? Unfortunately, no; the client hardware support
is nearly nil. Not even Skylake, which can do 10-bit HEVC encoding in
hardware (and 10-bit VP9 decoding), can do 10-bit H.264 decoding in hardware.
Worse still, mobile chipsets generally don't support it. There are rumors
that iPhone 6s supports it, but these are unconfirmed; some Android chips
support it, but most don't.
I guess this explains a lot of the limited uptake; since it's in some ways
a new codec, implementers are more keen to get the full benefits of HEVC instead
(even though the licensing situation is really icky). The only ones I know
that have really picked it up as a distribution format is the anime scene,
and they're feeling quite specific pains due to unique content (large
gradients giving pronounced banding in undithered 8-bit).
So, 10-bit H.264: It's awesome, but you can't have it. Sorry :-)