Does ECC's cofactor affects ECC's private key selection?

Question

I am doing a project using ECDH with Curve25519. I use mbedtls library, in the implement, I realize that the private key of Curve25519 is clear 3 last bit, or it is divide by 8 and the cofactor of Curve25519 is 8 too. I looked to another curve (Curve448) it cofactor is 4 and the private key is divide by 4 too. I tried choosing a non-divisible key for 8 and the algorithm still works. So does cofactor affects private key on ECC.

• Does ECC's cofactor affects ECC's private key selection?
• If I intentionally choose a key that is not divisible by 8, is there a problem?

Answer 1

Diffie-Hellman on Curve25519 and Curve448 is specified on RFC 7748 and the algorithm clearly mentions that the scalar must be a multiple of the cofactor (by setting the 2 or 3 least significant bits to zero depending of the curve).

If you choose a key with least significant bits not all zeros, then it depends of the implementation. An correct implementation following the RFC will make sure the least significant bits are set to zero before the scalar multiplication (whether when the key is imported in the program, or just before the scalar multiplication).

Now, you can eventually make an implementation that does not clear the least significant bits, the algorithm will give you something, but then it is vulnerable to small subgroup attack.

If someone sends you a small order point (let's say $4$), then by getting rid of the least significant bits of your private key, the result of the algorithm will give $0$ which is consider invalid and the small order point will be automatically detected.