Signatures for SignaturePayload can be re-interpreted to be signatures for distinct messages

[kayabaNerve]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

polkadot-sdk/substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs

Lines 245 to 262 in 1914775

	impl<Call, Extra> Encode for SignedPayload<Call, Extra>
	where
	Call: Encode,
	Extra: SignedExtension,
	{
	/// Get an encoded version of this payload.
	///
	/// Payloads longer than 256 bytes are going to be `blake2_256`-hashed.
	fn using_encoded<R, F: FnOnce(&[u8]) -> R>(&self, f: F) -> R {
	self.0.using_encoded(|payload| {
	if payload.len() > 256 {
	f(&blake2_256(payload)[..])
	} else {
	f(payload)
	}
	})
	}
	}

The potential reduction, which I can't identify the reasoning for in the first place, means that a hashed message can be re-interpreted as a message itself (or an unhashed 32-byte message can be reinterpreted as the hash of a longer message, yet this requires finding a preimage).

This shouldn't practically be an issue due to the lack of 32-byte messages in the ecosystem. Extrinsic almost always has several extensions which will place its payload far beyond 32 bytes. It'd require a distinct use of SignaturePayload, which I presume unlikely.

I did follow responsible disclosure on this, as it is arguable as a critical fault in the signature as a formal object, and was told it's a non-issue I'm welcome to publicly disclose.

Steps to reproduce

No response

[kayabaNerve]

I'd presume this will be resolved with #2415 is.

[bkchr]

Yes, I added this comment because of your report. Thank you for the report.

I don't see any reason to keep this issue open, as it is already tracked in the linked issue. You can leave there a comment if you like.