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