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