From: Ray Dillinger <bear@sonic.net> You seem to have 2 different questions.
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.
You might consider proxy cryptography here. ftp://research.att.com/dist/mab/proxy.ps
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...)
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?
Assuming RSA and IPv4 you are only planning to fix 32 bits (perhaps the next to least significant because you want to cater for even numbered IP addresses) out of each prime of size 512 or 1024 or whatever. That does not sound like much reduced security.
2) Is there a reasonable class of attacks and spoofs that this protects against?
I think so. Hard cheese for DCHP users though. From: Bram Cohen <bram@gawth.com>
Like I said, the important thing is that it stops passive attacks - in practice man in the middle attacks just don't seem to happen.
Sorry to take issue with Bram again but this reminds me of As far as we know, our computer has never had an undetected error.