Threading design pattern ?

When designing the new libssh architecture, we decided to make it completely callback-based, even internally. This provide cool features, like the possibility to extend libssh without recompiling it, or executing more easily asynchronous or nonblocking functions. Libssh 0.5 will run as a state machine, which listen for packets, and then calls callbacks from the packet type. The handlers will evaluate the current state of the session and what to do with packets. Sometimes, the state of the session itself changes as the result of a packet (e.g. when receiving a SSH_AUTH_SUCCESS packet).

A sequence diagram of a synchronous function such as authentication or simple channel read can be systematized as following:

What’s happening is pretty straightforward. The thread X is waiting for a specific packet x (or more precisely, the internal state change caused by packet x). It calls a function called ProcessInput (this is a simplification) which itself locks itself and tries to read packets from the socket. After a packet has been read, the callback for the packet (in this case, x) is called, which updates the internal state of the session.

ProcessInput returns after reading one packet. X verifies that the state changes to x, otherwise, it simply tries a ProcessInput again (not on the drawing) until it receives a state change it can process. Continue reading “Threading design pattern ?”

Debugging a cryptographic bug in libssh…

Hey there, you may know I am a developer of the SSH Library libssh. Last week, a post on the libssh mailing list was reporting a connection problem under Redhat RHEL 4.8. It seemed that the new cipher aes128-ctr, recently implemented in libssh, had a little problem…

This bug looked strange, firstly because we never ever had any cryptographic problems within libssh, secondly because the debugging did not report something broken :

[3] Set output algorithm to aes256-ctr
[3] Set input algorithm to aes256-ctr

[3] Writing on the wire a packet having 17 bytes before
[3] 17 bytes after comp + 10 padding bytes = 28 bytes packet
[3] Encrypting packet with seq num: 3, len: 32
[3] Sent SSH_MSG_SERVICE_REQUEST (service ssh-userauth)
[3] Decrypting 16 bytes
[3] Packet size decrypted: 44 (0x2c)
[3] Read a 44 bytes packet
[3] Decrypting 32 bytes
2010-04-12 13:14:54,211557; 1126189408 procSrvAuth; Did not receive SERVICE_ACCEPT

While giving on the OpenSSH side :

sshd[22341]: debug1: SSH2_MSG_NEWKEYS sent
sshd[22341]: debug1: expecting SSH2_MSG_NEWKEYS
sshd[22341]: debug1: SSH2_MSG_NEWKEYS received
sshd[22341]: debug1: KEX done
sshd[22341]: Disconnecting: Corrupted MAC on input.

Continue reading “Debugging a cryptographic bug in libssh…”

My new blog

Hi there !

After some solicitation from third parties (read: libssh developers), I finally installed a real blog to replace more or less my wiki-based website. I’m going to discuss some things about libssh development, thoughts about programming, networks, computer security and internet.

I’ll take the occasion to tell about the FOSDEM convention that took place this week-end. Awesome meeting of opensource developers, it was a great occasion to meet people, in particular Andreas which is a libssh developer as well. It’s also interesting to note that this is the fist time FOSDEM is connected to the IP world through BELNET (note: I work for BELNET). FOSDEM was connected to BELNET on IPv4 and IPv6 using fiber, and this bandwidth was distributed to users through WiFi access points distributed in the ULB campus. The bandwidth used peaked around 100 Mbit/s (a poor 1/10th of the available bandwidth) due to technical limitation of airwaves, but I’m sure the tech staff will find a solution for next year. Also interesting to note, an IPv4 was available for each participant (two /19 were allocated) and the IPv6/IPv4 enabled ratio was around 90%.

I’m looking forward for more good stuff next year !