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

Advertisements

9 thoughts on “Reader Queries On Blogsig – A Message Authentication System for Internet Forums

  1. Once someone impersonates me (which I’ve already seen some form of MITM where someone impersonated contacts on MSN lol, really didn’t care found it rather funny) on the 1 site I currently care about (s.com); then I’m interested in this. I also want to know more how it works, and how hard (or easy) it would be to bypass. I already consider the entire internet pretty untrustworthy and I actually question the material being returned to my computer.

    I’d still prefer your work on cell phones over this, but that’s just me. “Free” country, do what you want, blah blah…

    BTW, don’t let the lack of comments affect the blog, I still want to hear your perspective on things (just don’t get carried away! 🙂

    • Yeah, well that’s the thing – it is so easy to impersonate someone on a blog like Schneier’s where registration isn’t required. Sure, you’d hope the moderator would notice what is going on but given many would be posting via proxies or tor it may be difficult to determine who the “real” poster is. It is an interest of mine. I have a working proof of concept using ECDSA but it is quite deficient and needs a lot of work. I posted only because I received an email inquiry about it.

      Which brings me to my annoyance regarding comments and discourse. Someone can go onto my blog, download my PGP key and pull my email address out of the metadata and contact me yet they can’t just add a comment to the most pertinent article. It seems to be a recurring theme with bloggers – generating discussion seems to be quite difficult unless you are posting something particularly controversial. The visitor to comments ratio must be well over 500:1, which is sad IMHO and a bit discouraging.

      Regarding cell phones – I intend to do a spot on this very soon. It is quite plain and simple to see the variety of privacy issues that the modern smartphone revolution has created yet nobody seems to care. Sure even dumb phones on second gen GSM networks could be located using standard radiolocation techniques like triangulation, but to have your phone actively assisting in location without your consent (whether by artificially creating traffic by acknowledging but not displaying specially structured class 0 SMS messages or by actually sending back GPS derived location) is a massive violation.

      I think many would be happy enough to accept E911 if the feature was enabled only after an emergency call was initiated and there were assurances it couldn’t be remotely activated but this simply isn’t the case. So this isn’t analogous to “tracing” a fixed line call. It is possible to remotely enable auto answer and call the phone creating essentially a listening device, something the FBI themselves referred to as a “roving bug”. It is literally a minefield of violations.

  2. Yeah, seems like it would be more of a problem. Well, maybe they’re nervous, that’s always possible.

    Tell me about it, all the ridicule I get for my phone choice, some new data formats (or maybe just massive amounts of metacrud) take awhile to load on my phone (iphones especially). Only accepting E911 in an emergency call seems like common sense; another instance of hiding surveillance and potential for abuse behind “it’s for your safety”.

    Another thing I noticed on my phone that I never asked for or didn’t want, aside from random updates I never approved (and suspect may be used for malicious purposes) is City ID: http://en.wikipedia.org/wiki/City_ID
    You probably don’t need to worry about it having rooted the phone, but a large majority of people who don’t (or can’t); it’s yet another layer of surveillance.

    • Wow, and Verizon is preinstalling this crap? It is funny because the service it offers is absolutely useless. It’s not a crowdsourced live caller ID service (like Google now offers), it just looks up the prefix and displays the locale. Given most people know their neighboring area codes and few receive calls from out of state from unknown callers (exceptions being service providers, insurance salesmen etc who always have caller ID disabled anyway) it seems like it has limited utility especially as Android 4.4 has this functionality out of the box.

      Hadn’t heard about this as I never buy my phones through providers. I always buy outright and install a custom ROM and try and delete as much crap as possible. Of course this doesn’t fix the major problems with these phones – the evil stuff is hiding in the baseband but at least you can minimize commercial spyware.

    • Oh, and something a bit more interesting… It turns out these guys have a patent on uh, having a database of prefixes and displaying the town… Yeah turns out that BS is patentable and have been trolling all of the free alternatives off the respective app markets with threats of lawsuits. About as evil a corporation as you can get. I wonder if Google had to license its “technology” in 4.4 from these guys? (I think they got around it by doing a remote lookup to Google’s servers on each incoming call – if it finds a name it returns that, if not it returns a city or town). Yes, obviously the Google solution effectively sends incoming call metadata straight to Google as a side effect. Clever huh? The NSA must be proud.

  3. Yep, preinstalled. Basically any consumer taking a phone out the box will have this stupid crap and then can’t “delete” unless you supposedly tell it to after 15 days…or just alter the phone you just bought. Wow…figures for such a worthless product they have to force on you to buy then waste your time in a courtroom.

    I’ve never rooted a phone b/c I assumed pure compromise anyway; also don’t like messing w/ tools I kind of need and now I’m trusting some software on the internet. Always got to do things yourself if you want them done correctly I guess….

    Anyways sorry for OT. Someone has to impersonate me (trivially simple of course just like most any other crime or immoral act) and then I’m interested (even you could do it!) 🙂

    • Nah, I am not a Nazi about OT comments. At least someone is commenting!

      Re rooting – I can understand your rationale there. I just can’t handle the idea of Google Inc having all of my personal info by default and figure that a partially secured handset is better than completely owned. Of course I would never trust my cell nor the open internet.

      Oh and by the way if you pick a fake email address and stick to it WordPress won’t keep quarantining your comments as potential spam. I keep whitelisting your fake address and you keep changing it! 🙂

    • Hah! Sure thing Mr. Figureitout. Notice how your post appeared without the moderation delay? If you keep using that address it won’t be delayed. I only go through the queue about once a day as most of it truly is spam.

      I liked your links on s.com to antenna designs. I particularly liked the 20m design.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s