More security

Frank Yellin (Frank.Yellin@eng.sun.com)
Mon, 8 Mar 1999 15:33:49 -0800

From: "Frank Yellin" <Frank.Yellin@eng.sun.com>
To: <java-security@java.sun.com>
Subject: More security
Date: Mon, 8 Mar 1999 15:33:49 -0800

[Oops. I meant to send this to both Jan and to Java Security.]
I've also added some additional comments.]

My comment is that this is completely undocumented in the JCE documentation.

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<<

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.

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?

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.

>> You can initialize your MAC object with any secret-key object
> of a secret-key algorithm supported by your JCE provider.
>
> For example, in the case of the SunJCE provider, you could
> use the DH keyagreement to come up with a shared secret, and
> then use the key returned by
>
> SecretKey skey = keyagree.generateSecret("DES")
>
> to initialize your MAC object.