attacker cannot use a Sec value smaller than that of the target address (like 0) in an attempt to skip (or scale down) the brute-force attack on Hash2. This would namely yield a different CGA from the target CGA since at least one of the three leftmost bits of the interface identifier would not match. If the target Sec value is written to the interface identifier anyway, then Hash2 will (almost certainly) be found to lack the required amount of leftmost 0-bits during the verification process. During the CGA generation process, it is very unlikely that three address collisions occur. If a duplicate address would be detected for the third time, then this would most likely be due to a configuration or implementation error or a denial-of-service attack. For this reason, the number of valid values for collCount is limited to the range from 0 to 2. This parameter must be verified to be in this range during the CGA verification process in order to prevent an attacker from exploiting it and trying all different values without the need to perform another brute-force search for Hash2 each time a different value is tried. By including the subnet prefix in the digest operation that results in Hash1, it can be prevented that an attacker is able to use a single pre-computed database to attack addresses with different subnet prefixes. A verifier can also be sure that the public key has been bound to this exact address and not possibly to an address with the same interface identifier but a different subnet prefix. Since the CGA specification prescribes to use the subnetPrefix from the CGA Parameters data structure for the digest operations, it must be verified that it matches the subnet prefix of the CGA during the CGA verification process. See also SHA-1 References Cryptographic protocols IPv6 Articles with example pseudocode