Reader Queries On Blogsig – A Message Authentication System for Internet Forums

A reader e-mailed several days ago asking a few questions regarding my “blogsig” concept. To call the effort a project is perhaps premature as only a small amount of proof of concept code has been produced and work on this has proceeded at a slow pace due to other much more important commitments.

I first mentioned this concept to Nick P. and others on Bruce Schneier’s blog several months ago and had quite a few somewhat verbose discussions with forum regulars in regards to the most optimum way of achieving my desired goal.

It was effectively an open brainstorm and no promise was made that a project would ultimately result from the very crude proof of concepts that were created to demonstrate the viability of the concept.

The executive summary is that blogsig is a message signing system optimized for online forums such as blogs or social media sites like Facebook. Through the use of elliptic curve crypto we are able to keep keylength small.

The ultimate goal of the project is to produce a single line signature that could either be appended to the message or alternatively embedded in a link. A browser plugin would provide both signing and verification functions.

I hope that midway through 2014 we will have a complete specification and some solid implementations out in the community. That said, blogsig will only be developed if there is sufficient community demand. The naive will retort with comments such as “just use PGP” but nobody really wants a mass of lines choking up every forum post. Detatching the signature and hosting it elsewhere doesn’t solve the problem, it simply shifts the burden.

The threat metrics of blogs and social media are different to electronic mail. The internet needs a web forum optimized message authentication and assurance system that is easy for the common folk to use.

Rather than repeat myself I have included some quotes from posts made on Schneier’s forum along with a link to the full page. As I cannot repost content without the original author’s permission you will have to view the original pages to see any replies directed toward me.

Many of the information described is deprecated and no longer valid. The current PoC uses DJB’s ED25519 and encodes text using ASCII85.

“Nick: there have been comments that have appeared once or twice and I have looked back and think “did I say that? it looks like my writing style kinda but it is certainly not my personality?” – honestly I just play along and go with it because by the time I go back to the thread to respond I’ve long forgotten where and when I was when I wrote the original comments. Now my memory is like that of a deadbeat alcoholic. I can remember most things fine – probably more than fine. Song titles, lyrics, code, commands, citations, who did what when and where, etc. but I can’t for the life of me remember small actions that happened in a day of other bigger events should I need to a few days down the track. In my teenage years I had some brain injury in a prank gone wrong (don’t ask! seriously though I am okay now and am not writing this from a wheelchair or anything) but no doubt I feel that these little chunks of memory that go ‘walkies’ are somehow related. Or some jerk is posting randomly as me once a month (or maybe once every two months) and making me doubt my sanity :-). But getting to the point – message signing certainly has utility. Nothing stops impersonation on blogs. Only trust (and an eagle eyed moderator who can make tough calls with limited data – often both users may be on services like tor or otherwise won’t have a static IP so you won’t be able to just go “oh, *normal* IP = good guy).
I think perhaps signing with, say a 4096 PGP key is a bit excessive for blog use. Perhaps a 512 DSA key just for signing? It’s not earth shatteringly important after all.”
– October 26 2013 15:01

“the key is that it should be tiny enough to be embedded in the blog post – either covertly (in an element like a ‘title’ for a link for example, or as an actual link) or overtly (the last line in the post). I am working on this concept just for fun… and it will give me something to fill up my next weekend. The concept is that we don’t need high security – we just need something that makes spoofing expensive and time consuming for the adversary. By putting the data on an outside link you are making the system centralized and forcing users to either use “our” server that we put up for testing (if we went this way) or run their own. that said we could probably use an API for something like pastebin to populate the full signature in a paste. Given blog posts are going to be checked within a few months of submission this might just work.

Nick: I might just hack up something quick and dirty using either shell or perl that parses a blog post and generates a ‘tiny’ signature line – and of course another script that can take a blog and verify the signature line.

I imagine people would just generate in-app keypairs for use with this, but with a bit of mucking around there is no reason why we can’t integrate this with their exisiting PGP keypair. Now we can’t directly import ours as a subkey as PGP requires >1024bit (gpg is okay with 512 in expert mode) and it is handled a lot differently. The easiest way to do this would be to create a subkey on a trusted key of theirs and use their blogsig public key as their comment field. By putting their PGP keyID in the metadata space of their blogsig instead of some other identifier (which would be limited to about 16 chars by necessity) they can advertise the link and the client software can validate it by pulling the key from the servers and verifying if a subkey exists, etc. Again love sounding ideas off everyone here. One day we’ll come up with something that is not just useful but indispensable. We’re not there yet, of course.”
– October 26 2013 17:59

“I am considering using ECDSA (or the ec based digital SIG system Nick spoke of on Friday) for my blogsig project. This is due to the need to fit both a signature and metadata into an 80 character (a single standard length line) signature. Given I have stated that non-repudiation and absolute certainty are not part of the brief I think it is a reasonable enough choice. A blogsig is designed only to certify that there is a high (not absolute or legally provable) probability the signed post was composed by the keyholder and has not been modified (except for reformatting, a concession we must make with blogs).”

– November 7 2013 05:12

“My current PoC code is a bit of script hackery that uses wget to dump the page you wish to validate, then trawls the page looking for blogsig footers. Each footer found gets pumped into a routine. This routine pulls the blogsig into its component parts – the metadata and the digital signature.

The first block is the key identifier, which is encoded in five characters of the blogsig (and thus is limited to 94 chars, that is 7bit minus the space and controlchars). The keyID is actually in hex but is encoded in 7bit printable to save space. The sixth character of the blogsig metadata stores whether to verify the entire block as teXt (strip all HTML), full HTML, or strip all but Links. It can also be instead set to K which means the public ECDSA key follows. I will likely be able to avoid the sixth char of metadata entirely if the client software is smart enough to try the three methods until a good sig is found (and of course notify as to what method has been used). An embedded key could easily be differentiated from a SIG, of course obviating the need for the sixth char entirely. Directly following the six char metadata is the length of the signed post in characters (with all whitespace ignored and the HTML stripping settings of the mode chosen enforced) immediately followed by a ! and then the signature proper (or the key in the case of mode K). Obviously I could move char six to this location and have a relatively predictable delimeter rather than wasting a character. The blogsig ends with a % sign, thus giving a blogsig a pretty unique layout to be found with a regex.

Anyway my PoC can take a chunk of blog and verify sits against my test keyring without any hassles. The stripped HTML with the exception of links (mode L) is the default as link forgery is a possibility with plaintext strip mode. I have tested it with WordPress and the comment section of drupal without any problems. Of course this is just a proof of concept.

The next obvious piece of the puzzle is key servers. My idea of being able to push our your public key on a blog sucks as not everyone will see it and people might request it time and time again. A key server is the logical solution.

I am considering whether I can “dress up” a blogsig key so that the existing PGP key servers can do this job for us. It would be trivial to change my key identifier to PGP’s system. How it would be done remains to be seen. The servers might refuse abnormal looking keys. The easiest way would be to use the metadata of a PGP key (like the comments field) to publish our public key. It is short and shouldn’t pose an issue. People that wish to use both blogsig and pgp could generate a subkey with the required info and publish it to the key servers. This is just an idea I am toying with.

So that’s what I got up to on a boring Saturday evening. Obviously it is all just a test and my mind is made up about nothing. But I think the concept of a short low security key for signing blog posts is a good one. If I end up hiding the blogsig data in a link then it would annoy readers of the blogs less (although a one line blog SIG has to be less annoying than a multi line PGP sig). If you had the link point to the blogsig website, is http://sig.co/b?blogsig_blob_goes_here then those with the browser plugin installed would get instant verification but those without the plugin could simply click the link. If it is a public blog a CGI script on the server could fetch the page, parse it and verify the blogsig. How is that for graceful fallback behavior?

As we have discussed the aim of the blogsig is for a short digital signature to provide a low to medium level of assurance that the user is the one who owns the public key. The key size is small enough that an attacker with time, money and resources could potentially forge it, but in a way that’s the point – non-repudiation is not a good feature to have in a system like this. Really all it is doing is providing a mild level of assurance. For anything serious – use PGP.”
– November 3 2013 09:22

“The keyID is a throwback to few things I was trying – in my first implementation keyID was derived from a hash of the public key. Obviously collisions would be an issue that I have not yet considered. The second idea was to use the keyID (and lengthening the field) to give the PGP key that contains our blogsig key embedded in its metadata – as a way for the client to know where to go and fetch the public key. Not sure exactly where I am going with this yet.

Re edu I’d be happy enough to use it. I just chose ECDSA as there was reference code available and it was a “known quantity”

Re the URL idea – thanks. I thought it may at least remove the signature blob from public view and stop people going “huh? What’s that line of crap at the end of your blog posts?”.. I may have misunderstood you but are you stating that the server would, in effect act as a proxy, searching for signatures and verifying them if they are present?

Agreed re your comments on SSL. While we have different aims In have no doubt the solutions could be engineered to be similar or indeed solved in a single implementation. I think the key here is lots of discussion, simple proof of concepts etc before going to the spec/RFC stage. You can spot that some very popular internet protocols were thought up on paper without ever being implemented as a proof of concept – IPSEC comes to mind.
The benefit of doing some hacky proof of concept code – even if its just a bit of perl or even shell that, say takes your message and signs it – and another script that you can pump a HTML page into and it will find and verify any embedded sigs. Such code is never intended to actually be used but by doing that you encounter some of the problems that an actual implementation would face without going to all of the trouble at such an early stage.”
– November 4 2013 05:58