Binary key initialisation in PBKDF2

[Stephen White-3]

Some code I'm working on requires the use of PBKDF2, but requires that
it operate on specific binary data.  The implementation of PBKDF2 in GNU
Crypto takes a password as a char[], which is then converted to a byte[]
using the default character set (or UTF-8 in the latest codebase).  This
makes it impossible to pass in arbitary binary data as the 'password',
something which I need to be able to do for interoperability reasons.

I have added the option to use a new attribute IPBE.MAC_KEY_MATERIAL
instead of IPBE.PASSWORD in the initialisation data to the setup()
routine in my local copy of PBKDF2.java.  If provided this attibute is
interpreted as the literal byte[] to use as the key, avoiding the char
-> byte conversion issues.

My modified key/password initialisaion code is:

   byte[] key = (byte[]) attributes.get(IPBE.MAC_KEY_MATERIAL);
   char[] password = (char[]) attributes.get(IPBE.PASSWORD);
   if (password != null) {
      try {
        key = new String(password).getBytes("UTF-8");
      } catch (UnsupportedEncodingException uee) {
         throw new Error(uee.getMessage());
      }
   }
   
   if (key != null) {
     macAttrib.put(IMac.MAC_KEY_MATERIAL, key);
   } else if (!initialised) {
      throw new IllegalArgumentException("no password specified");
   } // otherwise re-use previous password.


It would be helpful to me, and possibly others, if this code (or an
alternative implementation of a similar idea) could be included in the
standard gnu.crypto codebase.

Many thanks,

--
Stephen White


_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@...
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss

[Raif S. Naffah]

hello Stephen,

just in case you're not aware of the latest news, GNU-CRYPTO is now
part of the GNU Classpath project; see
<http://www.gnu.org/software/classpath/classpath.html> and more
specifically
<http://www.gnu.org/software/classpath/announce/20060306.html>.


my comments on your proposed changes are in-line below.


On Saturday 15 April 2006 09:42, Stephen White wrote:
> Some code I'm working on requires the use of PBKDF2, but requires
> that it operate on specific binary data.  The implementation of
> PBKDF2 in GNU Crypto takes a password as a char[], which is then
> converted to a byte[] using the default character set (or UTF-8 in
> the latest codebase).  This makes it impossible to pass in arbitary
> binary data as the 'password', something which I need to be able to
> do for interoperability reasons.

noted.

> I have added the option to use a new attribute IPBE.MAC_KEY_MATERIAL
> instead of IPBE.PASSWORD in the initialisation data to the setup()
> routine in my local copy of PBKDF2.java.  If provided this attibute
> is interpreted as the literal byte[] to use as the key, avoiding the
> char -> byte conversion issues.
>
> My modified key/password initialisaion code is:
>
>    byte[] key = (byte[]) attributes.get(IPBE.MAC_KEY_MATERIAL);
>    char[] password = (char[]) attributes.get(IPBE.PASSWORD);
>    if (password != null) {
>       try {
>         key = new String(password).getBytes("UTF-8");
>       } catch (UnsupportedEncodingException uee) {
>          throw new Error(uee.getMessage());
>       }
>    }
>
>    if (key != null) {
>      macAttrib.put(IMac.MAC_KEY_MATERIAL, key);
>    } else if (!initialised) {
>       throw new IllegalArgumentException("no password specified");
>    } // otherwise re-use previous password.
>
>
> It would be helpful to me, and possibly others, if this code (or an
> alternative implementation of a similar idea) could be included in
> the standard gnu.crypto codebase.

* the new package for both IPBE and PBKDF2 classes in Classpath is
gnu.javax.crypto.prng.

* i don't see the need for an IPBE-specific MAC key material constant;
instead, the already existing IMac.MAC_KEY_MATERIAL constant can be
used in PBKDF2.

* i will add another constant (in IPBE): IPBE.PASSWORD_ENCODING =
gnu.crypto.pbe.password.encoding; which can be used to pass a string
denoting the character encoding used to interpret the password
characters.  if a password is passed without a character encoding then
UTF-8 will be used as the default encoding.  the setup() method would
then look like so:

    byte[] macKeyMaterial;
    char[] password = (char[]) attributes.get(IPBE.PASSWORD);
    if (password != null)
      {
        String encoding = (String) attributes.get(IPBE.PASSWORD_ENCODING);
        if (encoding == null || encoding.trim().length() == 0)
          encoding = "UTF-8";
        else
          encoding = encoding.trim();

        try
          {
            macKeyMaterial = new String(password).getBytes(encoding);
          }
        catch (UnsupportedEncodingException uee)
          {
            throw new Error(uee.getMessage());
          }
      }
    else
      macKeyMaterial = (byte[]) attributes.get(IMac.MAC_KEY_MATERIAL);

    if (macKeyMaterial != null)
      macAttrib.put(IMac.MAC_KEY_MATERIAL, macKeyMaterial);
    else if (!initialised)
      throw new IllegalArgumentException("no password specified");
    // otherwise re-use previous password/key-material


if this does not address your problem, then let me know.  i plan to
check in these changes within the next 24-hours.

thanks for your comments and suggestions + cheers;
rsn


_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@...
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss

[Stephen White-3]

On Tuesday, 18 Apr 06, at 13:20, Raif S. Naffah (raif@...) wrote:
> specifically
> <http://www.gnu.org/software/classpath/announce/20060306.html>.

Ok, thanks, I hadn't spotted that.

> * i don't see the need for an IPBE-specific MAC key material constant;
> instead, the already existing IMac.MAC_KEY_MATERIAL constant can be
> used in PBKDF2.

I don't really see the need for a new constant either, so that sounds
fine.

> if this does not address your problem, then let me know.  i plan to
> check in these changes within the next 24-hours.

That looks great, many thanks,

--
Stephen White


_______________________________________________
gnu-crypto-discuss mailing list
gnu-crypto-discuss@...
http://lists.gnu.org/mailman/listinfo/gnu-crypto-discuss