CDR: Key-Address correspondence in networks?

[Ray Dillinger]

I want to run this idea past some knowledgeable people and see if 
it looks like a good idea.... 

In an application which passes encrypted messages from one host to 
another, it is desirable to have the message differently encrypted 
at each 'hop' along the way (to defeat traffic analysis).  But, this 
link-to-link encryption requires keeping track of an enormous number 
of keys, and that introduces complexity which a cracker could use 
to get into the system.  

Bluntly, after reviewing PKI and x.509 certs, I don't think that 
there is a sufficient reason to trust that the machine I'm talking 
to is actually the machine its cert claims it to be.

The proposal is to use longer keys for each machine, and have the 
IP address of each machine be part of its key.  (or in another 
network environment, assign it an "address" which happens to *be* 
its key...)  


That way, you can instantly spot at least one class of bogus 
requests and constrict the possibilities for an attacker.  
(ie, "if the key presented does not match the address it's 
presented for, refuse no matter what DNS or the key database 
say about the name-to-key correspondence and the name-to-entity 
correspondence".)  

Note, these keys are for asymmetric encryption - probably elliptic-
curve or RSA.  The IP address will be on the public-key side.  The 
actual packets will be encrypted under a symmetric algorithm, with 
the key for the packet encrypted under the asymmetric algorithm and 
transmitted with it. 

My questions: 
   1)  Is using a longer key just paranoia in this case, or is there 
       an actual weakness in constricting the choice of public key
       that makes the private key easier to derive?  

   2)  Is there a reasonable class of attacks and spoofs that this 
       protects against?

   3)  If so, does this protection make the system noticeably harder 
       to break? (ie, does it protect against what would otherwise be 
       the easiest attacks?)