Authentication Implementation

The most recent Fractus client and server builds currently accept and process any message (sign-on notification, instant message, etc.) as implicitly authenticated. This is, of course, a major flaw and was planned to simplify the beginning stages of development. As noted in the ticketing system ("Issues") on the Fractus Server Github site, this is a high priority fix.

While using BouncyCastle (this project's cryptography library), I noticed that the key generator could generate Elliptic Curve Digital Signature Algorithm ("ECDSA") and Elliptic Curve Diffie-Hellman ("ECDH") keys. Recently, I investigated Stackoverflow, one of my favorite and highly recommended websites, and found little about the potential for interaction between the two keys.  So, I decided to ask StackOverflow and this post came to my rescue: Is there a difference between ECDH and ECDSA key?

Thomas Pornin, provided a thorough answer which included important issues regarding Fractus's potential authentication mechanism.

It's important to note that in the future, different authentication and encryption algorithms could be used. Perhaps in a few years someone will find a weakness in Elliptic Curve cryptography (as was found years ago in Single DES) or, alternatively, a tricky weakness in the curve used in Fractus currently. This needs to be accounted for in the protocol and implementation by specifying useful ciphers which possibly are not installed on the clients computer.

It's also entirely conceivable that the server, which acts as a CA, can be taken down in the future. Therefore the authentication mechanism will be "pluggable" enough on the client to allow for the use of a (perhaps simplified) Web of Trust model.

Many decisions need to be made today. I will post once I decide on the details of authentication and certificates.

FractusServer Database

Recently I encountered my old FractusServer ("fractusd") database code.  This was entirely written before I had real database application programming experience and it made me cringe.

Possibly the most appalling part is that it works for a small number of users.  Yet if a single user had one hundred contacts, each with on average .5 valid connections, my implementation of the database abstraction would cause an unfortunate 52 connections from fractusd to the database upon sign on: one to authenticate the user, one to retrieve his contacts, and 1 to retrieves his contacts' (about 50) locations.

I have coded stored procedures for all necessary database operations in MySQL (checked into the "fractusd" repository on my Github).  For instance, there was one that returned either 1 or 0 if a set of credentials could authenticate or not.  There was one that returned a set of contacts' usernames.  I actually found the learning curve of SQL (except for tricky optimizations) much shallower than a complex ORM framework like Hibernate.

The tricky part is the connection pooling, as hinted above.  I don't mind repeating a bunch of boilerplate code, but the way I see this, a single thread should lease one of maybe 32 connections and release it when done and after a timeout.  I'm working on the simplest way to do this without J2EE.

Update:  It's definitely BoneCP -- this does all the connection pooling (and configuration) without any of the overhead of ORM which I don't need for such a simple application.