Re: [Mipshop] comments on drafts using CGA

["CAO, ZHEN" <caozhenpku at gmail.com>]

Hi Christian,

 

I agree with you.

 

Thanks for your detailed explanation:)

 

Many thanks,

Zhen

 

On 10/25/06, Christian Vogt <chvogt at tm.uka.de> wrote:

Hi Zhen!

> So for an attacker to break a victim's CGA, the attacker has two
> options:  It could either integer-factor the victim's RSA public key,
>  or it could choose an arbitrary RSA key pair and do a brute-force
> search for a suitable modifier.  If the attacker chooses to
> integer-factor the victim's public key, it does no longer need to do
>  a brute-force search for a modifier.  It can simply copy the
> modifier from the victim.
>
>> Note as well that the two methods are different, because the
>> integer-factoring of the victim's public key will result in
>> permanent risk before the victim changes its key pair, but the
>> brute-force search attack is one-off since the victim may change
>> its address and then the attacker should have brute-forced again.
>> From this respect, the following analysis does not stand well. The
>> integer-factoring costs more but the attacker gains more.

I agree with you.  But note that I did attend to this issue further down
in my email where I described the case that the attacker wants to spoof
multiple CGAs from the same victim which are all generated from the same
RSA key pair.

The example that I was giving below is a DoS attack against the victim
during Duplicate Address Detection.  But other situations are also
conceivable.  E.g., the victim may change its CGA for location privacy
reasons.  The normal operation in such a case is to keep the same RSA
key pair and use a different modifier.  An attacker that has previously
integer-factored the victim's key can then spoof the victim's new CGA
without going through another brute-force search.

Note that the attacker actually spends *less* effort than the victim in
such a case:  While the victim must do another brute-force search for a
modifier that suffices the desired hash extension length, the attacker
can simply "copy and paste" that modifier.  So the attacker is at an
advantage over the victim.

>> The key length becomes more critical when the attacker wishes to
>> generate multiple CGAs which are all based on the same
>> public/private key pair.  E.g., an attacker that wants to DoS a
>> node during Duplicate Address Detection must repeatedly generate a
>>  new CGA (in order to generate a false Neighbor Advertisement
>> message "defending" that CGA), whereas only the collision count
>> changes on the victim side.  It would then be of advantage for the
>>  attacker to integer-factor the CGA's owner's public key, and thus
>>  get the private key that it needs to spoof /any/ CGA from the
>> victim without doing another brute-force search. (The modifier
>> remains stable if only the collision count changes amongst the CGA
>>  parameters.)

But I must revise something else that I said, which is this:

>> But as far as the CGA/CBA protocol goes, an attacker needs to spoof
>>  only /one/ CGA, namely, the victim's home address.

This is not necessarily true.  The victim may change its home address
every once in a while for location privacy reasons.  This might increase
the motivation for an attacker to integer-factor the victim's public
key.  OTOH, the purpose of the home address is to sustain reachability,
which means that most mobile nodes would likely change their home
address only occasionally.

> Whether we need longer keys therefore depends on the complexity of
> integer-factoring a *specific* 384-bit RSA public key relative to the
>  complexity of a brute-force search for a suitable modifier given an
> *arbitrary* RSA public key.  The latter is 2^(59+H) hash operations,
> where H is the length of the hash extension encoded into the CGA and
> 59 is the number of cryptographic bits in the CGA.  I'm not sure
> about the former, as I am not a crypto expert.  (Maybe someone can
> help?) 2^(384/2) = 2^192 factor tests should be an upper bound for
> the complexity of integer-factoring a 384-bit key, but there are
> certainly more efficient algorithms.
>
>> some results on integer factoring can be found on
>> http://en.wikipedia.org/wiki/Integer_factorization, it should be
>> much better than 2^(192)

Right, I know.  I wanted to keep things simple in the email.  If we
really require a longer key length, then we will need the help of
security experts from the IETF anyway.  We should not rely on Wikipedia
in that case. ;-)

<snip>

> If folks would prefer longer keys nonetheless, we could do one of the
>  following three options:
>
> (1)  Specify a higher minimum key length as part of the CGA/CBA
> protocol.  This is what you are suggesting.
>
>> We are suggesting a security consideration should be given. IMO,
>> e.g., some words should be added to the Security Consideration
>> section of drafts using CGA.

Yes, you are definitely right about that.  Will include text on that in
the next draft version.

Thanks!
- Christian

--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop