[chord] new auth type patch

[Emil Sit]

> o the addition of a new type called DHASH_KEYNONCEHASH
>    -- in this type, ChordID = hash(pubkey, nonce); the user selects 
>       the 32-byte nonce arbitrarily

Why does the nonce have to be so large? 

>    -- the signature that goes in the backing store is taken over a 
>       concatenation of the actual payload and the nonce. this binds the
>       nonce to the payload and prevents an adversary from doing replay
>       attacks

How does this prevent replay attacks?  Do you want this system to
prevent an adversary from replacing newer data with older data?
In that case, you want a version number, which it looks like you
have, but don't verify as increasing in verify_keynonce (and isn't
signed anyway). The nonce doesn't seem to provide any freshness
guarantees, despite what I would expect from its name. [Maybe
it could be renamed.]

It seems like the "nonce" is really just a "random" way for the
application to pick the name of the block and then the signature
by the public key is used to bind the contents to the name.

> Questions? Comments? Public beheadings?

Can you split your patch into three (or more?) based on functionality?
e.g.
- code cleanups (such as method renaming, refactoring, etc.)
- noauth interface export
- keyhash_nonce stuff

then we can take some of your fixes/changes as we iron out details
about what you are trying to do with this nonce stuff.

-- 
Emil Sit / MIT LCS PDOS / http://pdos.lcs.mit.edu/chord/