|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: references on non-central authority network protocols
Uh, let's see - you submask k_public to route, hmm... either you have 32 bit encription or you have IP1024... IP1024 - THAT would solve address space limits, but imagine the BGP prefix updates... Bruce Williams "Two is not equal to three, even for large values of two" > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > Scott A Crosby > Sent: Saturday, April 13, 2002 6:45 PM > To: Stephen Sprunk > Cc: Patrick Thomas; [email protected] > Subject: Re: references on non-central authority network protocols > > > > On Sat, 13 Apr 2002, Stephen Sprunk wrote: > > > > > Thus spake "Patrick Thomas" <[email protected]> > > > I am looking for any and all research (and perhaps your > > > comments), references, etc. regarding replacements for the > > > TCP/IP protocol that do not require centralized authority > > > structures (central authority to assign network numbers). > > > > Please explain how you think any protocol could support > non-trivial numbers > > of users without some arbiter to prevent address collisions. > > Rolling off the top of my head, I think its doable. The > general trick is > to make it hard to forge packets with arbitrary addresses (by using > authentication). > > Assume each host has an public and private key pair by some > conventional > algorithm (RSA, or other). The private key is never disclosed. > > K_public, K_private. > > Let H be a collision resistant hash function, and SIGN do a digital > signature that may be verified by anyone who knows K_public. > > Then, each host is given an address of: > > k_public > > Now, annotate each packet with sufficient information to authenticate > that the packet came from the host k_public. > > SIGN(H(k_public || BODY)) || k_public || BODY > > (Note: hosts could be given addresses of H(k_public) for shorter > addresses. Another enhancement would be to annotate the packet with a > counter to help catch replay attacks.) > > Anyways, I think this fits the bill, you cannot create an arbitrary > k_public of your choice. If you could, then you could break > the public key > cryptosystem (or the cryptographic hash). > > The only way to create a valid signature is to know > k_private. Packets are > not accepted unless they come with a valid signature, so > knowing k_public > does not tell one how to create packets. > > -- > > A variant of this could be made where just the network is > assigned with > this scheme, the host isn't. IE, hosts are assigned addresses of: > > k_public || hostaddr > > Which isn't robust against malicious hosts in the same > network, but thats > fixable with a heirarchial scheme. > > -- > > This is off the top of my head, so I probably made a stupid > mistake.. But > I'm pretty sure some variation of this scheme would work. > > Scott > >
|