From: Ray Dillinger <[EMAIL PROTECTED]>
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...)
[I seriously question what the purpose of mixing the address in to the
key is. It certainly provides no security since anyone can generate a
prime with a particular bit pattern. --Perry]
> 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.
[32 bits is certainly a lot more significant at 512 bit key
lengths. It isn't clear in practice whether an attacker can take any
advantage of the mixing of the IP address into the key, but again, I
don't know what security this provides. None I suspect. --Perry]
> 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 <[EMAIL PROTECTED]>
> 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.
