[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006



 In your previous mail you wrote:

   The fact that there are no secrets is exactly the beauty of HBA. You  
   can easily determine what the real user's prefixes are, and also the  
   extra index or whatever it's called, and then you can compute the  
   hash. But that doesn't buy you anything: in order to redirect  
   traffic, you need to find an alternative prefix+index set that  
                                ^^^^^^^^^^^

=> this issue is this word "alternative": an attack is to use the
same set, i.e., HBAs just extend the steal of address to the steal
of address set. It does not matter for multi-homing but only for
multi-homing. This is why I say HBA+CGA is a strictly stronger
mechanism than HBA.

   resolves to the same hash. This requires 2^58 tries on average  
   without using sec.
   
=> as 2^(20*sec+58) is greater the hash extension is or will be
a necessary addition.

   CGA is exactly the same, except that here, you don't put in a prefix  
   set of your own, but a public key for which you have the private key.
   
=> no, CGA has the RSA part too.

   > => no, either the attacker has to find a key pair giving the same hash
   > or to inverse the public key into the private one. Both problems are
   > harder than for HBAs.
   
   CGA and HBA use the same hash, you can break CGA by breaking the hash  
   and substituting your own keys, rather than break the public key crypto.

=> I am afraid you believe any bit string is a valid public key, this is
not the case for RSA. It does not matter for real brute force attacks
(the modifier is long enough) but should matter for more sophisticate
attacks using some vulnerabilities in the hash function.

Regards

Francis.Dupont@point6.net