[mhreljac]

Atomichelix PGP for BlackBerry

We are proud to announce that we're releasing "Atomichelix PGP for BlackBerry" to the public in beta format. We feel that it's been thoroughly tested (OS 4.1 through 4.3 on seven different 8xxx devices on four different networks, both with and without data plans) that we are confident (almost) everyone will be able to run it without many issues (we can't possibly test every combination, thus the open beta before we go live).

We are hoping to go live with it in two to four weeks, barring anything drastic. Currently, the beta is complete except for two things: the translations (that are currently being sent to people to complete) and turning the transactions live. Since the transactions are not currently live, you may use a test credit card number (such as a Visa number of 4111-1111-1111-1111) to complete a transaction through the "License Management" screens. Once we go live, we will be wiping the license database, so please feel free to do whatever with the application.

For those that do not know, PGP is a standard way of encrypting emails. By it's very nature, sending emails is insecure -- even from a BlackBerry. BlackBerry devices encrypt their communication with the BES/BIS, but once that is done, the messages are in plaintext format and sent (either on the internal or external network) from the BES/BIS. We have created a PGP program for BlackBerry devices that we feel is easy to use and transparent to everyday use.

Just a couple of notes:

1) The application itself is fairly large (about 1.4Mb) so we suggest to those not on unlimited data plans that you download the ZIP file and install it via the Desktop Manager.

2) We'd like everyone that has technical comments/suggestions/issues with the program to post here, mentioning your OS version and device model number. We haven't yet tested it on OS 4.5, for example, so we'd like to collect any issues about the software and see if it's an OS problem or an application problem.

3) There are a few problems that we are aware of that are in the OS that we either can't fix and have workarounds or we have decided (currently) to live with. An example of each is that when you 'Send Public Key' to someone and the email pops up, the first 'To:' in the email composition is blank and dead -- you can't edit it. This is an OS issue. The example of something we have decided to live with currently is the main screen you can only scroll up and down (not side-to-side) as we are supporting OS 4.1 (which doesn't have a trackball). We may eventually release different OS builds, but not currently.

We really hope that this is useful and hope you give it a try. We have worked for months to get this software together and can only hope you all find it as useful as we do for protecting privacy.

The demo mode in the software is a fully functional, time-constrained version with all the functionality of the full version, with the sole exception of not being able to import private keys (though, in demo license mode, they are able to be generated).

Again, please post any issues here as this is the only place we're going to advertise the open beta.


M

[rivviepop]

Glad to see the team making open beta!

To all the forum members, this is a really well done piece of software that I helped test out awhile back and if PGP is your thing I encourage y'all to give it a try. Full key management in a nice UI, importing and exporting keys (the team worked with me to get a keypair I've had since 1999 working!) and of course encrypting and decrypting your messages which is what matters most.

Two thumbs up to this piece of software from rivvie.

EDIT: it's completely GPG (Gnu Privacy Guard, GnuPG) compatible, of course - I didn't/don't even use the 'real' PGP.

[djm2]

I would love to use this, but do have a few concerns about the size of the memory footprint. Rivviepop, does it burn 1.4 mb on your 8320? I'm sitting at 16 mb free on the 8830 and this would get me close to danger territory for the dreaded memory leak problem.

[rivviepop]

Originally Posted by djm2

I would love to use this, but do have a few concerns about the size of the memory footprint. Rivviepop, does it burn 1.4 mb on your 8320? I'm sitting at 16 mb free on the 8830 and this would get me close to danger territory for the dreaded memory leak problem.

I haven't gotten a chance to put this beta on yet, but previously yes - it does have a large footprint. I'm guessing it's due to the need of installing the crypto code as part of the package as it's not native on the BB devices they have to include the J2ME classes. (just a guess)

[mhreljac]

Yes, it's 1.4Mb because of the crypto library. We created a J2ME PGP library and the COD for it is 900k. Nothing we can really do about it if we want to fully support all of PGP (and that includes all compression and encryption types). But, in return, this allows the PGP that you run on your BlackBerry to be compatible with PGP messages sent to and received from other programs.

M

[djm2]

Originally Posted by mhreljac

Yes, it's 1.4Mb because of the crypto library. We created a J2ME PGP library and the COD for it is 900k. Nothing we can really do about it if we want to fully support all of PGP (and that includes all compression and encryption types). But, in return, this allows the PGP that you run on your BlackBerry to be compatible with PGP messages sent to and received from other programs.

M

Thanks for your response. I have downloaded it and am doing some testing of it. What I haven't figured out yet is how I can import my private key used on the desktop, as well as the assorted public keys that I already have on the desktop. Is there a real simple way to do that which I am just missing. Probably is -- some very straightforward stuff is known to go right by me, while other things I can get right at and understand in depth.

Thanks. This looks very nice, and maybe I should get rid of some junk to preserve memory.

Oh, 8830 with OS 4.2.2.196

[djm2]

Wirelessly posted

OK I now see the comment about the private key importation. Does this apply to public keys as well?

[mhreljac]

Importing of public keys is always allowed (in order for someone to demo it, we assume you need to). Importing of private keys isn't allowed on the demo because you can generate a keypair on the device to test with. The thought was that someone that wanted to get the same emails on their device and desktop, with being able to decrypt them in both places, would need the full version.

M

[djm2]

Originally Posted by mhreljac

Importing of public keys is always allowed (in order for someone to demo it, we assume you need to).

Perhaps I am extremely dense, but on the public key section I see no option on the menus for importing a public key. I assume that we need to email the *.asc file from a desktop PGP application to the BB for the import; does the import option only show up if there is a file that has been sent?

[mhreljac]

Wirelessly posted

It's not you, don't worry.

Because of the way attachments are handled in the BB (it's getting better with newer OSes), we felt the best way to handle the importing (initially) was to have it so the email you send has the key in it.

For example, if you go to the Private Keys page, open a menu and select 'Send Public Key', you will see an example email. The same email can be sent from the desktop to the device to import a public or private key (though, in the case of a private key, you should generate a pair on the device, send the public key from that pair to the desktop, and use that public key to encrypt the private key before you send it to the device).

We will be adding .asc attachment support soon, along with keyserver lookups, for public key importing. Trust me, we have about 50 enhancements we'd like to do, but there's only 24 hours in a day. :(

M

[djm2]

Thank you. I will see if I can get that to work properly.

[djm2]

Yes, that definitely helped as I can now get keys in a bit more readily. Thanks. If I was in your shoes, I would consider posting a fairly detailed description on your web site regarding how to do this (import keys), because your process is not completely intuitive -- at least to me. And I'm certain that others will pose the question before you get around to making key rings, etc.

Having said that, it seems to work pretty much as advertised.

The following is a question, and certainly not a complaint. When decrypting an email that arrives, it seems to take quite a while for a moderate length (100 word) email -- probably something in the range of 25 seconds. Now given what we are doing, and the limited processor on a BB, this doesn't strike me as inordinately long, but I did want to ask if that squared with your expectations or have I come across something.

[mhreljac]

Wirelessly posted

Yeah, the next steps are the walkthroughs and tutorials online to show how to import keys, generate keys, change settings and what they mean, etc.

As for the speed at which the application works, that's expected. The processor in these devices aren't fantastic, but they work. In our speed trials, the smaller keys are relatively fast while the larger keys are slower. For example, an RSA 1024-bit key encrypting an average-sized message takes about 3-5 seconds. Decrypting that message with that key is about 10 seconds. Creation of that keypair (on the device) is anywhere from 1.5-2.5 minutes. DH keypairs are about twice as long to generate, about five times as long to encrypt a message and about twice as fast to decrypt (for the same size keypairs). Generating a 4096-bit key for either type is currently impossible on the device (as it takes longer than 10 minutes to do and after 10 minutes the BB OS thinks the thread is stuck so it kills it), but you can import them for use.

We're hoping the Bold (and successors) with it's better processor will be quite a bit faster.

However, the speed of the 1024-bit is fast and more than enough protection for the common user, and since the device does all the encryption/decryption, you can be sure that your messages are protected from point-to-point. Fair trade, in our opinion.

M

[djm2]

Originally Posted by mhreljac

Wirelessly posted

However, the speed of the 1024-bit is fast and more than enough protection for the common user, and since the device does all the encryption/decryption, you can be sure that your messages are protected from point-to-point. Fair trade, in our opinion.

M

I agree with that assessment regarding the fair trade. We must be realistic when evaluating performance and take into account the task that is being completed and the horsepower applied to that task.

[rivviepop]

Originally Posted by djm2

I agree with that assessment regarding the fair trade. We must be realistic when evaluating performance and take into account the task that is being completed and the horsepower applied to that task.

I think with every copy of the PGP software we should get an add-on CPu for our devices and a soldering iron.

BlackBerry 8320, now with an Intel Xeon CPU!
(some assembly required)

[djm2]

Originally Posted by rivviepop

I think with every copy of the PGP software we should get an add-on CPu for our devices and a soldering iron.

BlackBerry 8320, now with an Intel Xeon CPU!
(some assembly required)

Some Assembly required. Cute.

[djm2]

Update on the speed issue: Part of my issue on speed is tied to the fact that my long-held private key is 2048 in length. Encrypting of the message is quite quick; decrypting is the pain in the butt. I am going to consider adding another private key of length 1024, but I will have to push that out to people for use.

All in all, however, this appears to be a fairly solid application. My only comments so far really pertain to the documentation, and you've seen those in previous messages.

[djm2]

I have a suggestion regarding the cacheing of pass phrases. Right now, it appears that every time an encrypted message arrives that the pass phrase must be entered in order to decrypt it. I suggest the following options, if it is not too difficult to implement:

- Required for every message
- Required the 1st time an encrypted message is received following a security/password unlock of the system.
- Required for the 1st message following power on/power off
- Always cached (bad security practice, but some might use it).

On a different note, I have also just now received two messages where the decrypt failed with the notification of an EXCEPTION. No idea what this means, and what could be done. It was a fairly vanilla text (no html) message with some embedded links, etc., but nothing extraordinary.

[mhreljac]

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

[djm2]

Weird -- nothing is showing up in the log with only the Atomichelix items checked. By any chance, are there known conflicts with BBSmart Emailviewer?