Question on private scalar derivation (ed25519)

[matthiasgeihs]

noble-curves/src/abstract/edwards.ts

Lines 424 to 427 in 0a66339

	const hashed = ensureBytes('hashed private key', cHash(key), 2 * len);
	const head = adjustScalarBytes(hashed.slice(0, len)); // clear first half bits, produce FE
	const prefix = hashed.slice(len, 2 * len); // second half is called key prefix (5.1.6)
	const scalar = modN_LE(head); // The actual private scalar

As far as I understand, the reason for bit clamping ed25519 keys is to mitigate small subgroup attacks. This is achieved by ensuring that the secret scalar is a multiple of 8 (by clamping the 3 lowest order bits).

In line 427, however, the clamped secret scalar is reduced modulo the prime group order (and thereby the bit representation is changed). Doesn't this defeat the purpose of the clamping? Shouldn't the final scalar have the 3 lowest order bits zeroed out? Or am I getting something wrong here?

[matthiasgeihs]

I'll try to answer my own question here.

In the case of ed25519 signatures, this modulo operation does not have an effect, since we know that we are operating on points of the prime order subgroup.

In the case of x25519 this would have an effect, but here we are not applying the modulo operation.

noble-curves/src/abstract/montgomery.ts

Lines 157 to 163 in 0a66339

	function decodeScalar(n: Hex): bigint {
	const bytes = ensureBytes('scalar', n);
	const len = bytes.length;
	if (len !== montgomeryBytes && len !== fieldLen)
	throw new Error(`Expected ${montgomeryBytes} or ${fieldLen} bytes, got ${len}`);
	return bytesToNumberLE(adjustScalarBytes(bytes));
	}

[paulmillr]

yeah we just follow the spec even if it doesn’t matter much