Dealing with KeyStore larger than available memory.

Question

Hi,
I'm manipulating a JCEKS/SunJCE KeyStore that has grown larger than available memory on the machine. I need to be able to quickly lookup/create/and sometimes delete keys. Splitting into multiple KeyStores and loading/unloading based on which one the particular request needs isn't ideal.
Can anyone recommend a file backed KeyStore that doesn't depend on loading the entire file into memory to work with the KeyStore? Or perhaps a different way of using the existing framework?
Thanks,
Niall

Answer 1

You might check the diffferent providers (and ask their developers about it) to see if you can find one; they should be using BER encoding and not DER encoding of the ASN1 structures. In that case the provider is able to read entries and parse through to the target entry (PILE) on demand but you will have a "pile" version which will make your performace pay for it. If somebody offers that, there sure should be some caching and enhancements on the KeyStore implementation not to suck on random searches.
Start your tests with Bouncycastle provider but I remember, in 2001, certificates generated by the security provider of jcsi (later wedgetail and a part of Quest [Vintela]) were BER encoded. It does not necessarily mean, that they use BER for all constructs now. Furthermore that does not mean that partial load is supported for their implementation of key store.
Finally if none matched your needs, you can write one security provider yourself. Reading the current keystore once (you hopefully have the passwords for all entries), write the entries in the new keystore file( in BER format) then write a logic (probably with caching) to offer transparent partial load in your keystore implementation; drop me some lines if you need more details or commercial consulting services on this.