On Fri, May 15, 2020 at 2:50 PM Ard Biesheuvel <ardb@xxxxxxxxxx> 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?
