Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Java > Other Java > BOOK: Beginning Cryptography with Java
|
BOOK: Beginning Cryptography with Java
This is the forum to discuss the Wrox book Beginning Cryptography with Java by David Hook; ISBN: 9780764596339
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Beginning Cryptography with Java section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old August 10th, 2006, 04:26 PM
Registered User
 
Join Date: Aug 2006
Posts: 5
Thanks: 0
Thanked 0 Times in 0 Posts
Default Basic PBE - Password Interpretation

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

Quote:
quote:Most, like PKCS #5, only consider characters in the ASCII range...
What is misleading about this is that PKCS #5 says nothing whatsoever about characters. What the PKCS #5 says is:

Quote:
quote:...a password is considered to be an octet string of arbitrary
length whose interpretation as a text string is unspecified.
I think you have just copied the specific interpretation that the Java PBEKeySpec class puts on the password:

Quote:
quote:Different PBE mechanisms may consume different bits of each password character. For example, the PBE mechanism defined in PKCS #5 looks at only the low order 8 bits of each character, whereas PKCS #12 looks at all 16 bits of each character.
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
 
Old August 11th, 2006, 08:45 AM
dgh dgh is offline
Wrox Author
 
Join Date: Aug 2005
Posts: 206
Thanks: 0
Thanked 20 Times in 20 Posts
Default

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.






Similar Threads
Thread Thread Starter Forum Replies Last Post
XML file interpretation DavidStowell Visual Basic 2008 Essentials 1 February 21st, 2008 01:33 PM
PBE bhizey BOOK: Beginning Cryptography with Java 1 August 21st, 2007 01:14 AM
HTML text interpretation omsadgamaya Crystal Reports 2 September 15th, 2006 07:23 AM
Wonder if its basic? aldwinenriquez ASP.NET 1.0 and 1.1 Professional 3 July 5th, 2005 11:01 PM
Password rajuru PHP Databases 1 February 10th, 2005 12:05 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.