[This email isn't just about OpenBSD; please forward it to the relevant places and people.]
Short version: Mistakes were made. Magic numbers have changed. $2b$ is the hash of the future. Background: The original bcrypt code (released in OpenBSD 2.1) identified itself as $2$. Shortly after release, a bug was fixed and the hash identifier changed to $2a$. Support for "minor" versions wasn't really planned, but it was backwards compatible. Solar Designer wrote a second implementation of bcrypt. This reimplementation suffered from a flaw dealing with 8 bit characters, and led to the introduction of the 'x' and 'y' flavors. OpenBSD did not have this problem and supports neither 'x' nor 'y' hash versions. Current problem: Solar found a bug in the OpenBSD implementation of bcrypt when hashing long passwords. The length is stored in an unsigned char type, which will overflow and wrap at 256. Although we consider the existence of affected hashes very rare, in order to differentiate hashes generated before and after the fix, we are introducing a new minor 'b'. OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes, although it will still generate 'a' hashes. OpenBSD 5.6 (coming this fall) will change to generating 'b' hashes by default. A future release of Solar's bcrypt code should also support 'b'. What this means: For OpenBSD users, all systems that might verify a password need to be upgraded before any systems start generating password hashes. This may be a concern in YP environments if ypcipher has been changed from the default and you attempt to run a mix of 5.4 and 5.6 systems. For 3rd parties, adding future compatible support for $2b$ now will enable a smoother transition in the future. The decision to generate 'b' hashes should be based on one's need to support password verification on a heterogenous mix of systems. Hopefully this will be the last version change for a while. Thanks to Solar Designer for helping to keep us honest.
