# Re: More security

David Brownell (db@Eng)
Mon, 08 Mar 1999 18:05:33 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Garrison M. Venn: "Re: CFB mode problems"
- Previous message: Ilan Zohar: "Security flaws in SealedObjects"
- Maybe in reply to: Frank Yellin: "More security"

    Date: Mon, 08 Mar 1999 18:05:33 -0800

    From: David Brownell <db@Eng>

    To: Frank.Yellin@Eng

    Subject: Re: More security

For kicks, have a look at /home/db/HMAC.java ... despite the date on
it, it's from summer 1997. One needs an HMAC like that to implement
TLS, both in the key generation (PRF.java) and per-message MACs. And
of course, the HMAC secret used in key generation can be substantially
more than the 64 bytes; that's typical, in fact.

One issue with that is that it uses byte arrays rather than key objects.
While this gives software all the flexibility it needs, it doesn't fit
with the notion of hardware key management (where secrets would never
ever leave the secured hardware device -- token or NCipher box or Rainbow
PCI card or whatever).

Sun needs some real hardware key management, and more apps that use its
crypto APIs, before it can know they really do the full job.

- Dave

Frank Yellin wrote:
>
> > 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: Garrison M. Venn: "Re: CFB mode problems"
- Previous message: Ilan Zohar: "Security flaws in SealedObjects"
- Maybe in reply to: Frank Yellin: "More security"