I've been thinking about signing recently. The truth is I'm a bit naive about the whole crypto scene but signing seems like an under used tech.

For example, when you register a domain name like noodle.com they could authenticate your public key. Then you'd set up your email server to sign all outgoing email as coming from noodle.com. Then when the guy on the other end recieves it he's can tell if it's fake noodle.com spam. You'd still be able to send anonymous email, but it would be detected on the other side if it was impersonating someone else.

Single sign on sounds like a good thing too. Someone registers your email and public key. A web site sends you a token, and you sign it. It checks against your public key. Authenticated.

In fact, it seems like passwords are a bad idea in general. It would be better to just use signing to authenticate who you are. That way you don't have to send your password over the wire and the server doesn't have to store your password, only your public key.

Perhaps you would have a key server that serves public keys. You would use a password for that so that later if you lost your private key you could reset your account. But all the rest of the time, you wouldn't use passwords you would only sign stuff.

I'm starting to ramble...

Thanks for the link. :)

I wrote some neat code last week for my unreleased Vantu p2p project.

The vision is that eventually, massive databases of Creative Commons media will be created. These databases will have an md5 hash of the best/official version of the media and p2p users will use this hash to specify that they want the official version.

The problem is, users can't know until the end of the download whether the md5 hash matches.

Instead of taking the md5 hash of the whole thing, Vantu takes the md5 hash of every 4k chunk. These hashes are grouped into pairs and we take the hash of each pair. We take the resulting hashes, group them, hash the group. This results in another set of hashes half the size of the first. We repeat this until only one hash remains. The final hash is the file signature.

At the application level, it rarely makes sense to use 4k hashes. An application could use 4k, 8k, 16k, 32k, or 64k etc chunks sizes. Vantu will probably only use 64k chunks. When the user wants to download a file the program asks the sharer for the hashes of the 64k chunks. We can check whether these hashes are correct. We can also check the data in each chunk as we download it. This way if someone is sharing bogus data we can find out after the first chunk rather than waiting for the entire download to complete.

It would be awesome if Vantu style file signatures caught on in other applications as well.

Here is the code to generate file signatures.

I have been lurking here since here since CodeCon. Funny how a person can lose track of time...

Smatch development is progressing slowly but surely. I have been playing with Apache source as part of a larger project. Here is a break down of some of the pointer uses in Apache.

There are 43108 pointer dereferences in the Apache source code. That is counting dereferences in macros once for each time the macro is used. It only counts code used in my compile, not all Apache source.

  Count Type of pointer     Explanation
  15225 parm_decl           *parameter (arrays are passed as pointers)
  12020 var_decl            *foo
  10466 plus_expr           *foo = bar; foo[2];
   1923 postincrement_expr  *foo++
   1604 component_ref       *foo.bar
    692 call_expr           get_foo()->bar
    461 addr_expr           pointers to a string constant mostly.
    398 indirect_ref        **foo
    120 cond_expr           *(foo?foo:bar)
     80 minus_expr          foo[a - b - c]
     71 preincrement_expr   *++foo
     25 predecrement_expr   *--foo
      9 array_ref           *foo[a]
      6 postdecrement_expr  *foo--
      4 va_arg_expr         *(va_arg(foo, int *))
      4 modify_expr         *(foo = get_bar())

Today I put up a page on the smatch.sf.net site to record bugs found by the smatch source checker. It's a pretty decent start. There are quite a few bugs listed so far.

The most fun script is the one that checks for UnreachedCode. These bugs are mostly harmless things like not printing out debug messages. This check shows that no matter how smart people are, the little things can still trip everyone up.

One thing that I expected to cause bugs was confusing "=" with "==". There are quite a few places where kernel hackers use "if (variable = variable){ ..." or "if (variable = constant) {..." (because of macros), but I didn't find any bugs.

I've already moderated most of the check results except SpinlockUndefined. Unfortunately because of a bug in smatch.pm, I couldn't print a start line for each bug so reading it is more difficult. The basic premise is that you should always know whether a lock is held or not.

spin_lock(&foo);
if (bar) {
        spin_unlock(&foo);
}
<--- Error because you don't know whether &foo is 
     held or not