In chapter 2, the section Basic PBE, the discussion under The Password is a bit misleading.

What is misleading about this is that PKCS #5 says nothing whatsoever about characters. What the PKCS #5 says is:

I think you have just copied the specific interpretation that the Java PBEKeySpec class puts on the password:

Note that this statement that "PKCS #5 looks at only the low order bits of each character" is also incorrect - PKCS #5 explicitly states that it doesn't deal with string passwords at all, it deals with passwords as an octet string. The JCE interpretation that picks out the low order bytes to produce that octet string is simply one possible approach.

Also note that "low order bytes" is not the same thing as ASCII. ASCII uses characters in the range 0 to 127, but if we use the low order bytes from the characters in the password string, we actually get characters in the range -128 to 127.

It is possible to work around the issue of high-order bytes in the password string being ignored (e.g., encode as UTF-8 and use that to create the input string). The real problem is interoperability. You can come up with a scheme to map an arbitrary string into an input for the key derivation function, but the algorithm identifier (or OID) doesn't describe this.

It might be useful to state explicitly in the book (perhaps in Appendix B) which algorithms in JCE use the "use the low order bytes of characters" password string transformation (so they can be avoided). By my reckoning, they are:

• PBEWithMD5AndDES
• PBEWithSHA1AndDES
• PBEWithMD5AndRC2
• PBEWithSHA1AndRC2

Also note the the list of PBE algorithms in Appendix B has a couple of errors in it. The following are listed, but they should have the hyphen removed:

• PBEWithSHA1And3-KeyTripleDES
• PBEWithSHA1And2-KeyTripleDES

The comment is based on two things, the first being the sentence that immediately follows the one you have quoted:

"In the interest of interoperability, however, it is recommended that applications follow some common text encoding rules. ASCII and UTF-8 [27] are two possibilities." (PKCS#5 page 5)

The second being for the correct interpretation of the test vectors RSA supply, using the ASCII encoding of a Java character string is one correct way of interpreting the password.

The introduction of UTF-8 is a comparatively recent introduction to the standard compared with the age of the Java implementations - these predate PKCS#5 version 2. You can find the original quote in PKCS#12. This quotes PKCS#5 version 1.5 and refers only to ASCII - in this case it even goes so far to refer to printable US-ASCII. The BC implementations relax this restriction to allow extended ASCII character sets to be used.

The PKCS#12 algorithms are the only ones that make full use of Java's 16 bit characters.

I'll look into the typos in algorithm names. It may be easier just to add them to the provider.