# Re: JDK's Security API recommendations

Roni Korenshtein (ronikoren@yahoo.com)
Thu, 27 Aug 1998 13:09:26 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Vishal Goenka: "Accessing Security.getImpl outside the package using"
- Previous message: finance@cyber-host.net: "AD: Visa - MasterCard - 100% Guarantee Regardless of Credit Problems"
- Maybe in reply to: Roni Korenshtein: "JDK's Security API recommendations"
- Next in thread: David Brownell: "Re: JDK's Security API recommendations"

---Jan Luehe <luehe@laguna.Eng.Sun.COM> wrote:
> For example, NIST and OIW define the result of a DSA signature
> to be an ASN.1 SEQUENCE of "r" and "s", and PKCS#1 specifies
> the format of an RSA signature.

Jan, I don't think the JDK specifies in what format
a signature byte array should be returned.
So any code that you want to write to extract r & s
or any othr sub-components of any signatures is
simply a hack. as in:

byte[] r = null;
byte[] s = null;
byte[] result = signatureAlgorithm.sign()
if (signatureAlgorithm.equals("ECDSA")) {
int len = result.length;
//repeat the divide by 2 throughout
//to emphasize the hacking
r = new byte[ len / 2];
s = new byte[ len / 2];
System.arraycopy( result, 0, r, 0, len / 2);
System.arraycopy( result, len/2, s, 0, len / 2);
} else { //repeat a special hack for every
//algorithm, and possibly, for every
//provider
}

As I said in a previous email
my feeling about the JDK is that it makes you
write good code, whether you want it or not.
This ambiguity with signature would result in a hack
which is not in the spirit of the JDK and good coding
practice.

>If OpenPGP wants to keep
> the digest, it should encode the digest as part of the signature
result,
> e.g., define the resulting signature to be a SEQUENCE of
> "r", "s", and the digest. You would get such a signature result
> if you specified
>
> Signature.getInstance("DSAOpenPGP")
>
> when you instantiate your Signature object.

There are 2 problems with that, but the main one
is that OpenPGP is just an externalized format.
It may be desirable to use some or any provider
for cryptography algorithm, and simply save the
data (results of the crypto algorithms) in OpenPGP
format. The implementation of the algorithms and
the format in which the data is saved should
be compatible but independent.

The algorithm provider should not care what format
its results are stored on disk. The algorithm provider
should, however, provide any intermediate results
that may be required, for any reason, by the
algorithm user. However, the JDK does not provide
the mechanism for doing that. So even if a provider
wants to allow the user to retrieve the intermediate
hash, how would they do that? combine it with
the byte array that returns the signing result?
that's a hack. What's needed is a SignatureResult
class which allows the user to get the hash as an
option, as opposed to always or never.

As an application provider, I'd like to be able
to save the data in any format. It's not reasonable
for a person to contact the provider and request
that they support, and create a new algorithm
just for OpenPGP. If the sign() method returned
an instance of SignatureResult having the methods
byte[] getEncoded(), and
byte[] getHash()

This accomplishes the following goals:
1. intermediate data is available to any algorithm that
needs it, but it's not intrusive if you don't need it.
2. no specific external format is forced.
3. verification performance may improve.

I realize it's too late for 1.2.
i'm just hoping these issues receive some consideration
in future releases.

Thanks,
Roni

>
>
> > Of course, eventually Certificate should also have the same
framework,
> > consisting of
> > a CertificateGenerator, Certificate, and CertificateSpec, and then
the
> > security API would be
> > more usable and consistent.
>
>
> Yes, if we decide to provide a Java extension package for certificate
> creation, we will certainly follow the design patterns adopted for
keys.
>
>
> Jan
>
>

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

- Next message: Vishal Goenka: "Accessing Security.getImpl outside the package using"
- Previous message: finance@cyber-host.net: "AD: Visa - MasterCard - 100% Guarantee Regardless of Credit Problems"
- Maybe in reply to: Roni Korenshtein: "JDK's Security API recommendations"
- Next in thread: David Brownell: "Re: JDK's Security API recommendations"