# Re: Couple of things wrt JDK 1.2 java.security.*

Jan Luehe (Jan.Luehe@Eng)
Thu, 19 Feb 1998 16:51:08 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Doug Haber: "signing an applet"
- Maybe in reply to: George Chung: "Couple of things wrt JDK 1.2 java.security.*"

    Date: Thu, 19 Feb 1998 16:51:08 -0800 (PST)

    From: Jan Luehe <Jan.Luehe@Eng>

    Subject: Re: Couple of things wrt JDK 1.2 java.security.*

    To: java-security@web1.javasoft.com, gchung@openhorizon.com

George:

> The new MessageDigest.digest(byte buf[], int offset, int len) is a great
> idea. It allows the message digest to be placed in an already allocated
> array.
>
> Unfortunately, the implementation of the above method allocates a new byte
> array anyway. I don't understand this. The data member digestBits doesn't
> seem to serve any useful purpose. This would have a non-trivial impact to an
> SSL implementation which needs to digest every SSLRecord.

I agree that "digestBits" is pretty useless. The only reason why we have
it is to be able to print out the digest in the "toString" method.

"toString" displays the internal state of your digest object:
If you're in the middle of a multiple-part digest operation (using "update"),
"toString" prints "incomplete"; when you're done (after calling
"digest"), "toString" prints the digest result as a hex string.

The reason why we clone the result buffer passed in as an argument
is so that any modifications to that buffer will not affect the
"digestBits".

Do you think this granularity of state information is useful
(considering that it impacts performance as you noted)?

>
> =============
>
> Signature should be enhanced (per the new digest() method) with a sign()
> method that places the signature in an already allocated array.

I agree this would be useful. We will see what we can do.

>
> =============
>
> Finally, the javadoc is not so clear on what MessageDigest.digest(byte
> buf[], int offset, int len) is supposed to return. It says the length of the
> hash. But this info is already available through
> MessageDigest.getDigestLength(). Shouldn't it be the number of digest bytes
> placed into buf?

Right. But this will be the same as the digest length, because
if you provide a buffer that's too small, we throw a DigestException.
We do not return "partial" digests.
But for consistency with other API docs, we should say: "Return the
number of bytes placed into buf".

Thanks,

Jan

- Previous message: Doug Haber: "signing an applet"
- Maybe in reply to: George Chung: "Couple of things wrt JDK 1.2 java.security.*"