That sounds like it's only helpful for ddos mitigation, in which case the attacker could trivially synthesize a correct checksum.

▲

phire 2 days ago | parent [-]

You don't have to use a publicly documented checksum.

If you use a cryptographically secure hashing algorithm, mix in a secret salt and use a long enough checksum, attackers would find it nearly impossible to synthesise a correct checksum.

▲

ben-schaaf 2 days ago | parent [-]

I don't follow. The checksum is in "plain text" in every key. It's trivial to find the length of the checksum and the checksum is generated from the payload.

Others have pointed out that the checksum is for offline secret scanning, which makes a lot more sense to me than ddos mitigation.

▲

phire a day ago | parent [-]

I'm not sure it's a good idea.

But it's trivial to make a secret checksum. Just take the key, concatenate it with a secret 256-bit key that only the servers know and hash it with sha256. External users might know the length of the checksum and that it was generated with sha256. But if they don't know the 256-bit key, then it's impossible for them to generate it short of running a brute force attack against your servers.

But it does make the checksum pretty useless for other usecases, as nobody can verify the checksum without the secret.

▲

ben-schaaf a day ago | parent [-]

Ah that makes sense. I wouldn't call that a checksum though; that's a signature :)

▲

phire a day ago | parent [-]

I don't think it counts as a signature, because it can't be verified without revealing the same secret used to create it.

	▲	ben-schaaf a day ago \| parent [-]
		You're right, the correct term seems to be MAC (Message Authentication Code).