[chord] new auth type patch

[Emil Sit]

> | Why does the nonce have to be so large? 
> 
> No good reason. That's what I arbitrarily picked and kept it. Would you
> like it to be smaller? If so, what size?

I guess 20 bytes isn't a lot smaller, though perhaps it would be more
in-line with the "SHA1" kind of sizes that we tend to customarily
used.  certainly, 32 bytes is more than you'll ever need... i guess
it would then be easy to be tempted to encode actual information
in the nonce.

> The verification of increasing version number happens, for keynonce 
> blocks, in the same place it happens for keyhash blocks -- in the store() 

er, i didn't realize it was verified elsewhere. n/m. it should
be signed though.

> behavior for existing DHASH_KEYHASH blocks, which also don't sign the
> version number, permitting a replay attack: the adversary takes an old

that seems poor.  we should fix that.  it looks like benjie was
the person most immediately responsible for the code.  i guess
we'll see if we can make that better.
 
> The replay attack I was talking about was one where the adversary takes a
> a valid (payload,sig) pair from one block and inserts it into another (and
> uses the nonce of the new block). Without binding the nonce to the payload
> with the signature, this attack is possible but, because of the binding
> you asked about, that replay attack won't work. 

this isn't so much a replay attack.

if the only change is the addition of 32 bytes of nonce data used
for naming, maybe we should just use this code, caling your stuff
'KEYHASH', and apps that don't care about being able to have
more than one block being signed by the same key could just set
the nonce to all zeros, perhaps via some sort of function that
hid such details...?

> Yes, you are exactly right about the purpose of the nonce. If the name
> 'nonce' is confusing, I will gladly change it. Suggestions?

'salt' might be more appropriate.

> o Finally, this seems like a tall order, full stop. Individuals continually
> check in to the repository with (sometimes) destabilizing and
> build-breaking changes. These changes are ones I've built and tested on

I think that there haven't been any build-breaking changes
recently.  

Anyway, until we come to some sort of consensus on the 'keynonce'
thingy [it would be nice if benjie offered his opinion at least, since
he's the primary user of the pkey stuff], we can either ignore your
other changes, or try to take them separately.  I'm inclined to take the
code cleanups and noauth exposure immediately.  Do you want to do the
work of supplying the patch, or do you want me to do the work and then
you can deal with the conflicts...?

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