[chord] new auth type patch

Wed Jul 23 16:20:13 EDT 2003

Hi Emil,

Thanks for getting back to me. Much appreciated. Comments and thoughts
inline.

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

No good reason. That's what I arbitrarily picked and kept it. Would you
like it to be smaller? If so, what size?

| >    -- 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 verification of increasing version number happens, for keynonce 
blocks, in the same place it happens for keyhash blocks -- in the store() 
method in server.C. I'm not sure I understand the point about verifying 
the increase in verify_keynonce.

As for not signing the version number, yup, that's a problem and one I've
known about. My reason for not signing it is that I was imitating the
behavior for existing DHASH_KEYHASH blocks, which also don't sign the
version number, permitting a replay attack: the adversary takes an old
(payload,sig) pair for someone other than himself, increments the version
number, keeps the block name fixed, does an insert, and voila, he just
rolled back the contents of the block and told dhash the version number was
new. (With DHASH_KEYHASH blocks, the adversary can also lie about the
contentlen, allowing him to truncate other people's blocks;
DHASH_KEYNONCEHASH blocks have the same problem, but my upper layer handles
this case.)

If the above problems should be fixed, I'd be happy to change the
dhashclient::insert() methods and my own insert method to sign the version
number and contentlen. I think both of these should be done, but I was
trying to have my stuff be as similar to the current code as possible.

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. 

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

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

Hmmm. It's been hard enough to maintain the patch against the often-in-flux
repository for even a short while. Maintaining three co-dependent patches
is a tall order and a possible recipe for error (unless there's an easy way
to do this that I'm missing). My thoughts on splitting the patch are:

o I can probably split the noauth interface export out, though making that
patch readable depends on method renaming. 

o Splitting the keyhash_nonce and code cleanups could be done, but it's a
pain b/c the keyhash_nonce stuff will need to apply on top of the code
cleanups.  

o The code cleanups aren't really necessary if you're not accepting the
keyhash_nonce.

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
multiple platforms. I would be happy to iron out any details about the
patch, discuss it at length, modify it according to your requests, and do
whatever else you want that seems reasonable, including splitting up the
existing .patch file into different pieces. An actual layered split,
however, doesn't seem worth the effort.

If I'm misjudging, please let me know. I'm not trying to make anyone's
life difficult, and I appreciate all of the help I've been given.

Please let me know how to proceed.

Thanks,
Mike