# RE: More security

Frank Yellin (fy@Eng)
Mon, 8 Mar 1999 16:13:12 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Frank Yellin: "Security, oops."
- Previous message: Yang-Chao Lin: "JCE 1.2"

    From: "Frank Yellin" <fy@Eng>

    To: "Jan Luehe" <Jan.Luehe@Eng>, <java-security@java.sun.com>,

    Subject: RE: More security

    Date: Mon, 8 Mar 1999 16:13:12 -0800

    In-Reply-To: <libSDtMail.9903081600.3921.luehe@laguna>

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

This is where you and I disagree. A MAC is >>precisely<< a secret-key
algorithm.

The Handbook of Applied Cryptography writes: (p.33)

Hash functions as discussed above are typically publicly known and
involve no secret keys. . . . Related to these are hash functions which
involve a secret key, and provide data origin authentication as well as
data integreity; these are called message authentication codes.

The Handbook of Applied Cryptography writes (p. 31)

A message authentication code,. . . is a one-way hash function with the
addition of a secret key.

> See above. The particular secret-key algorithm is not relevant.
> All the implementation does is call:
>
> secretKey.getEncoded()

I think that the fact that the current implementation allows you to pass any
Key object, and then calls .decode() on is is a hack. It makes it seem that
MACs
are an afterthought to the JCE, rather than an integral part. Particular
MAC
algorithms may have particular key requirements or prefer particular key
lengths. Just
like any other secret key algorithm.

- Next message: Frank Yellin: "Security, oops."
- Previous message: Yang-Chao Lin: "JCE 1.2"