I'm working on a encryption/decryption mechanism for exchanging a token (in some previously agreed format). The solution uses asymmetric cryptography. A key pair is generated (using some key algorithm - RSA). The public key is passed to the client to encrypt text and we use the private key to decrypt it. Now, the key pair that is generated can be stored in keystore file (on our server) and use the private key during decryption. Another way could be, to store the keys in a database and use the private key during decryption. I may have to use different sets (public/private) of keys for different clients. I can use client name as alias while generating keys. Which of the options is better and why? (I mean - storing in database or leave keys in keystore). Though it should not matter, I can depend on SunJCE or IBMJCE.
I wrote a similar system for a Client and used a DAO (Data Access Object) that implements an interface that had methods to add, delete, get etc the public and private keys. I then had the best of both worlds. I started with a DAO that worked with Java KeyStore and then when the number of public keys became too large to sensibly handle with a KeyStore I just wrote a DAO that used MySQL. No code change at all to my main application because the application picked up the DAO class name from the command line. It turned out to be a very very good move because later extensions to the project required storage of all sorts of other information about clients.
Using just the client name as a key to access the client information may not be a good idea since you may want two or more different key pairs associated with one client or you may have two clients with the same name. I used a fingerprint (nothing clever - just the SHA1 digest of the client's certificate) and the client's name as indexes. My DAO allowed me to access all client information with a given name or a particular client with a given fingerprint.
Joined: Jan 18, 2013
Thanks a lot, Richard. Your description gives me a clear idea to implement the solution. Instead of client name, I can go with client reference id (every client has a six-digit reference number) and make something like 123456_0, 123456_1 when the same client needs multiple keys. Sure, the DAO implementing the interface would be pretty clean and flexible. Thanks again for the proposed solution.