Wirelessly posted
That's a good idea to have a setting for the frequency of password checking. We have caching on the enhancment list, but it was designed as #3 on your list. I can't see us allowing #4 on the list at all (for security reasons), but #1 and #2 are great options.
As for the exception, open up the log (main screen, ALT-LGLG), set it to debug mode, and try to decrypt the message again. You might see the issue there. If not, list the events (Atomichelix ones) here and we'll try to help you. Most likely, it's a bug.
We did all our development and testing with 2048-bits keys, so we know of which you speak when you are talking about the speed issues. 2048-bit isn't too bad for speed, but it's noticable. For RSA, the encryption is fast (~5 seconds) while the decryption is slower (~120 second). For DH keys, the encryption is slow (~120 second) while the decryption is faster (~20 second). We're assuming all the devices are the same from the 7xxx series to the 8xxx series, because the processors are all the same (our testing shows this true, for which models we've tried). However, we were able to narrow down where in the code the bottleneck takes place -- (techspeak incoming) the J2ME lib doesn't have a BigInteger class, so there is no native math function on the device to calculate xPOWy. This means, with BigInteger, xPOWy is very slow as it converts the String to int to do the calculations. This means a 2048-bit number pair is about 4 times as slow as a 1024-bit number pair. So, a 4096-bit number pair is about 16 times slower than a 1024-bit pair. The estimates matched our tests, but the root cause is that the method on a 1024-bit is slow to begin with. Now, if the BB API had a xPOWy method available to a BigInteger with native code, our guess is it would increase the speed of our app signifigantly. Right now, we have to make do with the fact that it works.
M