[chord] new auth type patch

[Benjie Chen]

> 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.

i don't like 20, because it's not power of 2. but i am not sure if
that matters.

> > 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.

okay, i see what you mean. i think there are a few reasons why this is
the case

  - you won't be able to stop replay attacks with a version number,
    since a malicious server can just withhold newer data and you would
    never even know you are being attacked against. you will have to use
    higher layer mechanisms. i include that in my keyhash payload.
  
  - including version number as part of the signed payload means dhash
    servers would need to know about structure of the payload, at least
    a header. this is not difficult, just that we need to iron this out.
    for example, there are already a header that goes on top of the
    signed payload right now, that includes the signature and key. do you
    want to have another layering? i am not opposed to this if it
    actually did something useful, but as i mentioned signed version
    number does not stop replay/stale attacks

> 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...?

i think this is a good idea, if this is adequate for michael. in this
case i would be happy to define a structure that includes a header with
a version and a nonce, then a payload, and the entire structure must be
signed.

then we can go from there, to see if any other changes need to be made

benjie

-- 
benjie chen
benjie at lcs.mit.edu