Blogsig Spec Progress Report

I figured I had better give y’all a brief update on how my specification documentation for blogsig is coming along. As it turns out defining a spec is a bit like looking into a crystal ball, as you have to try and anticipate any future changes to the standard and how someone would implement them. The most long lived protocols are ones that have an innate ability to be easily modified and upgraded as time goes by and the needs of the users change. However this often isn’t the best way to engineer a security related protocol as such modularity can often be used against you, for example TLS and its vulnerability in certain configurations to a cipher downgrade attack.

So again we run into the age old problem where engineering in modularity and making your protocol more upgradeable could potentially compromise its security. The answer is always going to be a compromise but I believe that we will try and get the balance right.

Another practical design goal for blogsig was to have the signature take up no more than a single traditional 80 column line. Fortunately this was easy enough to achieve, but there are certain features that probably should make their way into the spec despite everything I have already mentioned.

The traditional PoC browser plugin – once it had found a blogsig string would parse out the length from the blogsig line and use a fuzzy algorithm to find, through trial and error based on an educated guess (derived from the length field – which you must remember will never be absolutely correct due to the way that blogs reformat text) where the first character of the encoded message is located. Obviously this is a matter of continually validating until we find the honey spot. This is very time consuming and slows down the identification and processing of the signature significantly.

The most obvious solution would be to have a PGP style BEGIN header but this quite flagrantly violates two of our design goals, those being a) the blogsig must add just one line of a maximum of 80 characters to any post, and; b) the blogsig should waste as little space as possible within the post.

I am playing with a potential solution where the first eight characters of the post are encoded within the blogsig (which isn’t a problem as we are consistently coming in well under our 80 character limit) and this is used in addition to the length information to assist the detection algorithm in finding the beginning of the post in a rapid manner. Obviously a “meet me in the middle” compromise solution would involve the use of a header, but one that is far more unobtrusive – perhaps an unused Unicode character or a sequence of a few low ASCII characters that are unlikely to find themselves in normal conversation, like +BsG:

Of course my simple algorithm that searches “near” the boundary inferred from the length encoded in the blogsig works just fine: it just isn’t particularly efficient. An optional combination of all of the above may be the most flexible, but again, I feel there is a much more simple solution staring me in the face.

The final solution is to have the browser plugin that does the verification to be somewhat blog platform aware. Fortunately there are only a handful of blogging software that runs well over 50% of the Internet’s blogs. A blog agnostic solution – like the “hunting” algorithm I described earlier – could be used only on blogs that the plugin is not aware of. Fortunately most of the popular blogs use a pretty sensible format and the post divider is generally within one or two lines of the beginning of the text.