AleHu / Blog: Recent posts

The latest AleHu version 'AleHu 20150106.zip' ships with a preconfigured AleHu test server that runs under HTTPS. Thus, the whole startup procedure for registering your public key with the server is SSL encrypted and should thus avoid any 'man in the middle' attack.

After months of development and testing the AleHu system finally has reached a sufficient maturity level so it was about time to shift from Beta to Production state.

Since the client now also transfers messages without problems to and from an AleHu server that runs under HTTPS (and whose SSL certificate is not trusted by the JVM default trust store), the version 'AleHu 20140622.zip' is the first production release.

Currently, the focus of the AleHu client developement lies on enabling connections to an AleHu server that runs under HTTPS and whose certificate is not trusted by the standard CAs that come with the JVM's keystore. One possible approach would be to add the AleHu server's certificate to the standard keystore's contents and store this expanded keystore in the client's resources subfolder for further usage. We'll see if this method works out and solves the important requirement of exchanging messages via HTTPS.

The latest release 'AleHu 20140531.zip' fixes a couple of bugs that incorrectly forced the client to use the (default) AleHu Testserver instead of the server specified at registration.

Besides, usability was improved a bit by memorizing things such as window size and position. So the next time you start up the client again, it appears at the same location where you quit, having the same size as with the previous session.... read more

The latest version AleHu 20140523.zip has undergone heavy testing for quite a while by sending gigabytes of data on different systems (including Mac OS) to each other. The AleHu client now handles tough situations such as the sender going offline, the receiving client going offline, the sender pausing its transmission, the receiver pausing its reception, as well as the server not beeing available. In all those circumstances the client reliably resumed transmission and the transmitted data was received completely by the receiver. All in all, the client is amlost ready for production!... read more

The AleHu client uses several threads in order to solve different tasks (create new message, receive packets, send packets, GUI handling, etc.) concurrently. When a user transmits big attachments (let's say larger than 100 MB), it happens occasionally that SQL exceptions are thrown. Those excpetions don't seem to harm (more testing is necessary), however I definitely would like to resolve those issues. In my opinion, a valid solution would be to use (thread-safe) pooled database connection sources (provided by ORMLite and apparently possible for Derby) for for each thread. However, further reading and tests are required.

In the latest version of the AleHu client it is possible to pause the transmission/reception of messages.

Besides, an improved exception handling in case of connection problems should further improve the stability of the client.

And finally, a check at startup was added to test if connections to the AleHu server were possible. If connections fail, the user is advised to check the proxy settings in the properties file of the client.

The AleHu client has been tested with the following setups:

• Windows XP, Java 6
• Windows XP, Java 7
• Windows 7, Java 6
• Windows 7, Java 7
• Windows 8, Java 7
• Windows 2003 Server, Java 7
• Windows 2012 Server, Java 7
• Ubuntu Linux, Java 7 (Oracle)
• Ubuntu Linux, Java 7 (OpenSDK)

The client was tested under some heavy load: receiving several messages having attachments up to 720 MB and simultaneously transmitting several messages having large attachments, too. In the latest versions of the client these messages could be transmitted to the last bit without any crashes, showing only occasional timeout exceptions.... read more

Until now the transmission of a new message started only after the termination of a heartbeat period. If this period is set to - let's say one minute - this can take quite some time. The latest version of the AleHu client interrupts the heartbeat period and transmission starts immediately. Likewise, after the first packet gets acknowledged by the AleHu server, until now the transmission of the remaining (attachment) packets started with the end of the current heartbeat period. In the latest version, the transmission of these packets starts immediately, too.

In the latest version of the AleHu client a couple of icons were added - so now the UI looks a bit fancier.

Besides, tests on a Windows Server machine experienced a problem with the operating system not being able to play the WAV file whenever a new message comes in. Additional exception handling simply catches this problem and now the client should work nicely on Windows Server as well.

The latest version of the AleHu client now offers several new possibilities to maintain the client user and the recipients: renaming, changing images and deleting users can now be done in the Users tab. Besides, one gets additional information about users such as key data and the AleHu IDs that are provided by the AleHu server at registration.

A couple of changes have been made to the client and the server code base lately:

• The client now checks at startup wheter the 'Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files' are installed - if not the program terminates presenting a corresponding message to the user.
• The client now checks if packets haven't been acknowledged within the last 5 minutes and if so puts them back into the 'Pending' state.
• At startup the client now resets all outgoing packets back to the 'Pending' state.
• The server code was adapted so that packets that haven't been relayed within the last 5 minutes get deleted.
• Finally a button has been added to the 'New message' tab so that users are now able to clear the attachment field in case an attachment has been sent before.
• A couple of additional exception catch blocks have further improved robustness and stability of the client code.... read more

So far, signature validation has only been done by the AleHu server. However, with the latest release (AleHu 20140315.zip) this deficiency was solved and signature validation is now done by the receiving AleHu client, too.

Further testing has been done lately and the results seem to be rather promising. Adding an appropriate RequestRetryHandler to the HttpClient logic was a major leap forward in client stability.

With the latest version of the AleHu client I was able to transmit a 380 MB video (to myself) without any disruptions. After the transmission was completed, I could start the playback of 'Captain Kidd' (downloaded from the Internet Archive) in my VLC player simply by clicking on the attachment icon in the client's 'Received messages' panel. However, more testing is necessary, especially transmitting to another peer's client.

Since the download button on the start page of the AleHu project simply refers to the latest uploaded file, the client and server code are now packaged into one single ZIP-file, the separation of code is no longer maintained.

Finally, the missing AleHu server source code and the ZIP-file have been uploaded. The Wiki has been extendet to include a description on how to install the AleHu server. Now the complete AleHu system (client and server) can be checked out and tested.

The latest version "AleHu client 20140210.zip" generates a new symmetric key for each packet that is sent. This should improve the strongness of the encryption. The generated symmetric keys are no longer stored in the client's database (there's no need for storing them, the recipient extracts the symmetric key from the wrapped key).

The previous version "AleHu Client 20140208.zip" was lacking the license file, this was fixed in the latest version, too.

Since the AleHu project uses a symmetric key length greater than 64 bits and the project has more than 25% U.S-origin parts or components, according to the project's MetaData section I am supposed to inform crypt@bis.doc.gov and enc@nsa.gov of the publicly available encryption source code. Thus, I just sent an e-mail informing those two addresses about the source code location at http://sourceforge.net/p/alehu/code/HEAD/tree/ .