Re: More security

Jan Luehe (Jan.Luehe@eng.sun.com)
Mon, 8 Mar 1999 16:00:02 -0800 (PST)

Date: Mon, 8 Mar 1999 16:00:02 -0800 (PST)
From: Jan Luehe <Jan.Luehe@eng.sun.com>
Subject: Re: More security
To: java-security@java.sun.com, Frank.Yellin@eng.sun.com

Frank:

> I'm glad, now, to know that this is how you do it. All I'm asking is that
> there be more information about these >>in the written documentation<<

I have added a paragraph to the user guide that will make this
clear. Thanks for pointing this out!

> The names of the MAC's that we claim to implement are HmacMD5 and HmacSHA1.
> There's no a priori reason that I should know that I'm supposed to
> initialize these
> with a DES key.

You can initialize them with *any* secret key of any type.
The implementation does not care which kind of secret-key
algorithm you are using. It simply calls

secretKey.getEncoded()

to retrieve the key material, and adjusts it for length
if necessary.

>
> Actually, the more I think about it, the more I really do want more than
> just better documentation
>
> In the future, someone may come up with a MAC that doesn't have any
> particular connection with aparticular cipher algorithm.
> Yet a MAC still uses the abstraction of a
> SecretKey, just
> like a cipher does. The way you're supposed to get a secret key is to use
> SecretKey.getInstance(secret-key-type). It seemed obvious to me when I
> first tried it that SecretKey.getInstance("HmacMD5") should give me an
> HmacMD5 secret key generator. And that KeyAgreement.getInstance("HmacMD5")
> should do likewise.
>
> What's gained by treating MAC's as orphans?

Not sure I agree. "HmacMD5" is not a secret-key algorithm.
I think now that I added a paragraph about this in the user guide,
there should be no confusion.

> I've even looked at the source code for HmacMD5 an HmacSHA1. Both seem to
> want a key
> from 1 byte to 64-bytes. I could find no reference in them to what,
> exactly, they want as their key. Certainly no reference to DES.

See above. The particular secret-key algorithm is not relevant.
All the implementation does is call:

secretKey.getEncoded()

and then operate on the returned key material.
This will work for any secret-key algorithm.

Jan