Well, with the remaining trust available at this point you might just as well use something cryptographically secure, like encrypted ones, twos, or simple HMACs of the block number.

A too-simple scheme is likely to be detected (and bypassed!) by the firmware a nearly no time.

Simpler: fill the drive with random data, hashing as you go, flush the kernel's buffer cache, hash the entire contents of the drive, and compare.

Conceptually,

  # tee /dev/DEVICE </dev/random | sha256sum
  # echo 1 > /proc/sys/vm/drop_caches
  # sha256sum /dev/DEVICE

though I wouldn't expect this exact command sequence to work unless tee's buffer size divides /dev/DEVICE's capacity and tee errors out writing past the end of /dev/DEVICE before writing to stdout.

I did exactly this earlier last week

the drive size divided by 4MB, so dd with bs=4M and fixed count

(with oflag=direct you don't even need to drop caches)

Oh, that's a clever way of doing things.

The "write the block #'s to the given block" would help identify where a fraudulent device goes wrong.

But for just checking if a device is storing data 100% correctly then your way would probably be more robust. :)

Sure, that's a decent idea too. :)