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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 31/07/2006, a las 9:09, Francis Dupont escribió:

>  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.


so for multihoming purposes, which is the scope of this working group, 
the security of the shim6 protocol provided by HBA and CGA are exactly 
equivalent right?

>  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.

yes, buy again this is exactly the same for HBA and for CGAs

>    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.

but this is exactly why the modifier is included in the initial part of 
the string, in order to prevent other type of attacks (i.e. the part 
that is easy to change is at the begining, so the attacker cannot 
benefit from precomputed parts of the hash)

Regards, marcelo


> Regards
>
> Francis.Dupont@point6.net