April 17, 2011

Notes on implementing TLS. #1: Reasons for.

The last few months I've been busy implementing TLS protocol support for this product of ours. It's in fairly good shape by now and I'd like to share a few thoughts.

First of all, why having own implementation when there are existing ones ? Actually there are quite a few reasons.

1. We need it to support Russian GOST family of cryptoalgorithms.
2. In Russia one cannot freely implement GOST, only using of certified libraries produced by state accredited companies is allowed.
3. We need it tightly integrated with our existing product. For example different such crypto libraries may need to be used simultaneously.
4. To make things worse, one option is to have crypto operations done by hardware token or smart card.

Therefore in the worst case you have USB dongle with GOST support inside, and you have to pass all crypto operations through it. Not just the private key operations, but even simple hash you can't do outside.

One other thing is that the product is not crypto-centric. We need a client-server tunnel in which the server supports hundreds if not thousands connections and utilizes multiple cores effectively. This asks for a different approach in which you think about the server architecture upfront and leave a modest place for cryptography. It leaves a lot more room for maneuver.

Besides, doing things is fun !

April 08, 2011

Better programming is just a way of telling no later

You work hard to build clean and extensible architecture to help your product withstand every possible requirement, hoping this will allow it to live long and prosper. And it will, but not for long. No matter how good your skills, one day some customer wants something so awkward that your only choice is to tell him no. No, this is not possible. No, this is not going to work. No, this is technically infeasible. You'd love to, but no.

But then, isn't good programming just a delaying that moment of telling your customer no ? Of reasoning finally backed with technical impossibility ? You had jumped through hoops implementing every possible wish while it was possible. Not anymore. You say no.

On the other hand, if you had your software written badly, you'd have this moment of truth ages ago. This could have provoked confrontation with the customer but perhaps would make both of you realize the limits earlier and come to a different, even non-technical solution, don't you think ?