Mark O'Donohue wrote:

>Hi Jim
>
>I think you've either misunderstood something in PKCS or have got
>confused over the usages of one of the PKCS packages.
>
>
>
>

The key formats from RSA PKCS #1 are:

A.1.1 RSA public key syntax

An RSA public key should be represented with the ASN.1 type
RSAPublicKey:

RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}

The fields of type RSAPublicKey have the following meanings:
n modulus is the RSA modulus n.
e publicExponent is the RSA public exponent e.

A.1.2 RSA private key syntax

An RSA private key should be represented with the ASN.1 type
RSAPrivateKey:

RSAPrivateKey ::= SEQUENCE {
version Version,
modulus INTEGER, -- n
publicExponent INTEGER, -- e
privateExponent INTEGER, -- d
prime1 INTEGER, -- p
prime2 INTEGER, -- q
exponent1 INTEGER, -- d mod (p-1)
exponent2 INTEGER, -- d mod (q-1)
coefficient INTEGER, -- (inverse of q) mod p
otherPrimeInfos OtherPrimeInfos OPTIONAL
}

My point is that the RSAPrivateKey format contains the public key.

There are two primary purposes of PKCS, encryption (i.e. key exchange)
and digital signatures. All crypto packages I investigated expose the
"public key encryption" and corresponding "private key decryption", but
many don't expose the primitives beneath digital signatures, exposing
only "compute signature" and "validate signature". If, for any number
of good reasons, you want your own signature validation layer, you can
be tempted to encrypt a digest with the public key and use the private
key for validation. This is completely insecure, because the private
key format contains all elements of the public key.

Crypto++ is an example of a library that doesn't expose the RSA
primitives. CryptTomLib, as does my more abstract TransformLib. In
general, it seems that crypto libraries oriented toward X.509
certificate processing tend to package/expose only functionality
requires by X.509. If you want to encrypt with a key you want to keep
secret and decrypt with a corresponding public key, you are going to be
disappointed, at best. At worst, if you assume you can just use the
public key to encrypt and expose the private key to decrypt, you are
making a very serious mistake.

A couple of other minor points. Mapping BER into XML is a waste of time
since BER is nothing that a tree of data values. It requires an ASN.1
schema to make sense of it. Second, a very serious drawback of BER
encoding (yeah, I know that's redundant) is that since the length a
SEQUENCE's children precedes the children, it is necessarily two pass,
requiring either intermediate storage or unpleasant head standing.




[Non-text portions of this message have been removed]