Please guide me on the issue of private key

Hi,

Here's the solution :

// Deserialize from a file

File fileKey = new File("C:/Temp/PrivateKey.ser");

ObjectInputStream inPK = new ObjectInputStream(new FileInputStream(fileKey));

// Deserialize the object

PrivateKey privateKey = (PrivateKey) inPK.readObject();

inPK.close();

It's the same for the public key.

Good luck.

FB13a at 2007-7-12 9:26:26 >

Doesn't matter what's the extension, ".cer" or ".ser".

Only matter what's is in the file and of course it works !!!

For the public key, it's the same :

// Deserialize from a file

File fileKey = new File("C:/Temp/PublicKey.cer");

ObjectInputStream inPK = new ObjectInputStream(new FileInputStream(fileKey));

// Deserialize the object

PublicKey publicKey = (PublicKey ) inPK.readObject();

inPK.close();

I've tried it and it works fine !!!

FB13a at 2007-7-12 9:26:26 >

CertificateFactory certfac=CertificateFactory.getInstance("X509");

X509Certificate cert=(X509Certificate) certfac.generateCertificate(new FileInputStream("C:\\MyFDREncryptssl\\client1\\client1.cer"));

System.out.println(cert.getPublicKey());

this worked..

but i have one doubt. I got this certificate signed by CA that i created using openssl. Now signing means the public key stored in certifcate will be encrypted using CA private key. But when i did this cert.getPublicKey i think the output that i got is not encrypted.

Help...!!!

Thanks and Regards

Pankaj Tiwari

pkta at 2007-7-12 9:26:26 >

> but i have one doubt. I got this certificate signed

> by CA that i created using openssl. Now signing means

> the public key stored in certifcate will be encrypted

> using CA private key. But when i did this

> cert.getPublicKey i think the output that i got is

> not encrypted.

>

You are making too much of this. Your public key held on the certificate is normally only verified by this approach by comparing it with the CA decrypted version.

From the point of view of your original post I have avoided this thread because I think the task is bigger than you think. To me, the easy bit is sorting out the keys. I think the more difficult bit will be finding out the encryption protocols used in conjunction with your RSA keys and then finding a Java library that will handle these protocols.

sabre150a at 2007-7-12 9:26:26 >

> You are making too much of this. Your public key held

> on the certificate is normally only verified by this

> approach by comparing it with the CA decrypted

> version.

More Confusion can u please go in some details of that. Details in the sense how is verification done. I mean with certificate how do i verify if it is signed by CA?

Message was edited by:

pkt

pkta at 2007-7-12 9:26:26 >

This is how i create the private and the public key files (Not the certificate file) :

KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");

kpg.initialize(2048); // 2048 is the keysize.

KeyPair kp = kpg.generateKeyPair();

PublicKey publicKey = kp.getPublic();

PrivateKey privateKey = kp.getPrivate();

// Serialize to a file

ObjectOutput outPK = new ObjectOutputStream(new FileOutputStream("C:/Temp/PrivateKey.ser"));

outPK.writeObject(privateKey);

outPK.close();

This is how i verify the signature of a file :

File fileKey = new File("C:/Temp/KeyPair/publicKey.ser");

ObjectInputStream inPK = new ObjectInputStream(new FileInputStream(fileKey));

PublicKey publicKey = (PublicKey) inPK.readObject();

inPK.close();

// C:/Temp/myfile.zip.sign is the file that was generated when i signed my file C:/Temp/myfile.zip

String algorithm = "SHA1withRSA";

String myFile = "C:/Temp/myfile.zip";

File fileSign = new File("C:/Temp/myfile.zip.sign");

ObjectInputStream inSign = new ObjectInputStream(new FileInputStream(fileSign));

byte[] signature = (byte[]) inSign.readObject();

inSign.close();

Signature verif = Signature.getInstance(algorithm);

verif.initVerify(pubKey);

FileInputStream in = new FileInputStream(myFile);

int chVerif = 0;

while ((chVerif = in.read()) != -1) {

verif.update((byte)chVerif);

}

if (verif.verify(signature))

System.out.println("OK");

else

System.out.println("Error");

FB13a at 2007-7-12 9:26:26 >

> Well, i don't think so !

>

> pkt wrote "The only requirement is to have public key

> and private key in two different files."

>

> So, who's clutching at straws ? ;-)

Of course, we're in a Cryptography forum, the topic under discussion involves certificate exchange, and .cer has a well-understood meaning in that context. Read here, for example:

http://en.wikipedia.org/wiki/X.509

I find it highly unlikely that the OP's clients are delivering serialized Java objects in files that by sheer coincidence happen to use an extension that the rest of the computing universe interprets as a cert encoded using the Canonical Encoding Rules.

If I post code showing the OP how to extract the desired certificate, assuming that the clients will be delivering files which are actually JPEGs with the necessary information hidden steganographically, how helpful do you think that would be?

Grant

ggaineya at 2007-7-21 21:04:19 >

Pankaj,

You are attempting the equivalent of a marathon without having trained for it.I would recommend that you read up on public-key cryptography (http://docs.sun.com/source/816-6154-10/index.html) and then - more importantly - David Hook's book (Beginning Cryptography in Java) before tackling something like this. The time will be well spent.

For at least making a pretense of some security, you should ask that the private key be delivered inside a JCEKS keystore (read up on Keytool) rather than a serialized object; serialized objects have no security, unless you've already secured the object's contents before serializing it. The JCEKS keystore attempts to protect its contents with Password-Based-Encryption (PBE) and has a well-defined JDK API to access it (http://java.sun.com/j2se/1.5.0/docs/api/java/security/KeyStore.html).

Sadly, maintaining a private-key on a file on the operating system - even inside a JCEKS keystore - is almost surely asking for it to be attacked - unless your machine is off the network. An attacker can copy the file and run a dictionary attack on it to reveal its contents in less than 30 minutes (for 95% of the passwords out there). If security really matters for your production application, then you need to store the private key in an external cryptographic hardware token - such as a FIPS 140-2 certified smartcard or HSM, which are designed to thwart these and other forms of attacks.

arshad.noora at 2007-7-21 21:04:19 >