On Fri, May 15, 2020 at 2:50 PM Ard Biesheuvel ardb@kernel.org wrote:
In this case, you are using the digest to decide whether the same code has already been loaded, right?
So it makes sense to think about the threat model here: if you are able to defeat the strong hash, what does that buy an attacker? If an attacker is able to create a different piece of code that has the same digest as the code that was already loaded, the only thing that happens is that the loader will ignore it. If that is a threat you want to protect yourself against, then you need sha256. Otherwise, a crc is sufficient.
My original intention is to: - avoid transmitting duplicate data if remote processor already has the same binary blob (be reminded that the transmission may be costly) - check integrity if any transmission error
Not considering preventing an attacker in the original design. If an attacker can send arbitrary binary blobs to the remote processor (via a dedicated SPI or a specific memory region), the attacker should already "root" the kernel and the device.
I understand your point that CRC should be sufficient in the use case. However here are my considerations: - as the payload is possibly executable, I would like to use stronger hash to pay more attention - calling calculate_sha256() is in-frequent, I don't really see a drawback if it is almost one time effort
If we want to switch to use CRC32, we cannot change the kernel code only. There is an implementation of a remote processor that also needs to modify accordingly. I will keep in mind whether to switch to use CRC32 next time when we are revisiting the design.
In general, you shouldn't use crypto at all unless you can explain why it is necessary.
When you are mentioning "crypto", do you refer to both crc32 and sha256 in the case?