You most likely have a IDS or IPS system in place which may be affecting the hash values after it intercepts the traffic if you try this:

sudo nano /etc/apt/sources.list

change this line:
deb http://http.kali.org/kali kali-rolling main non-free contrib

to:
deb https://http.kali.org/kali kali-rolling main non-free contrib

Okay, now it looks different. After changing to the HTTPS protocol as @iiamloz suggested, none of the sums match (not even MD5, which did previously), and the error persists.

It's worth noting that I am currently on a university network, although this issue first appeared on private, secure home WiFi.

New error message:

Get:1 https://kali.download/kali kali-rolling InRelease [30.5 kB]
Get:2 https://kali.download/kali kali-rolling/main amd64 Packages [16.5 MB]
Err:2 https://kali.download/kali kali-rolling/main amd64 Packages
Hash Sum mismatch
Hashes of expected file:

• Filesize:16529193 [weak]
• SHA256:1c1acd65e890e618abd7e9485c10e4dc3910ac4541eaf5257d43bd7cd4354c97
• SHA1:776197031efaa718628377e7af681b7e8f775c71 [weak]
• MD5Sum:3a74af9ae9acc09c0a3781c2be62e5eb [weak]
  Hashes of received file:
• SHA256:4dc97b03880feff385f46b678dc77478c0e2f4c59419e1574ae01768cc2b6ab2
• SHA1:072f2bc1f1db1276a9fc402e8220767dd2a4680f [weak]
• MD5Sum:97e0eff3ff379af20c9c702f1e8c3d6c [weak]
• Filesize:16529193 [weak]
  Last modification reported: Tue, 18 Aug 2020 18:04:27 +0000
  Release file created at: Tue, 18 Aug 2020 18:05:22 +0000
  Get:3 https://kali.download/kali kali-rolling/non-free amd64 Packages [197 kB]
  Get:4 https://kali.download/kali kali-rolling/contrib amd64 Packages [102 kB]
  Fetched 16.5 MB in 17s (961 kB/s)
  Reading package lists... Done
  E: Failed to fetch https://kali.download/kali/dists/kali-rolling/main/binary-amd64/Packages.gz Hash Sum mismatch
  Hashes of expected file:
  • Filesize:16529193 [weak]
  • SHA256:1c1acd65e890e618abd7e9485c10e4dc3910ac4541eaf5257d43bd7cd4354c97
  • SHA1:776197031efaa718628377e7af681b7e8f775c71 [weak]
  • MD5Sum:3a74af9ae9acc09c0a3781c2be62e5eb [weak]
    Hashes of received file:
  • SHA256:4dc97b03880feff385f46b678dc77478c0e2f4c59419e1574ae01768cc2b6ab2
  • SHA1:072f2bc1f1db1276a9fc402e8220767dd2a4680f [weak]
  • MD5Sum:97e0eff3ff379af20c9c702f1e8c3d6c [weak]
  • Filesize:16529193 [weak]
    Last modification reported: Tue, 18 Aug 2020 18:04:27 +0000
    Release file created at: Tue, 18 Aug 2020 18:05:22 +0000
    E: Some index files failed to download. They have been ignored, or old ones used instead.

Note that HTTPS is now being used, as expected.

You can try this, it worked for me

Because apt use sha256 method from libgcrypto20, but optimized too much. We can deny this opt.
using configuration file /etc/gcrypt/hwf.deny.

$ sudo bash

mkdir /etc/gcrypt

echo all >> /etc/gcrypt/hwf.deny

After the code just run apt-get update it should work

Thank you, that did indeed fix the issue.

However, since the hash problem occurs immediately with a default VirtualBox install, shouldn't this fix be implemented by default?

Oh it definetly should, took a while to find the solution.

All right, another update on the issue. After your modifications (and while still using HTTPS), sudo apt update works properly. However, upon running sudo apt upgrade, further hash sum mismatches occur, on more than 50% of all downloaded ".deb" files. Removing the hardware optimization flag file does not resolve this.

What is your host system? Is there any antivirus running?

The workaround above disables hardware optimizations in gcrypt, nothing else.

I'm on Windows 10, build 1909 (as up-to-date as I can be at the moment). I have Windows Defender enabled, and the free version of Malwarebytes installed. (Note that the latter cannot monitor proactively, however.)

As noted previously, I'm also on a university network for the moment, although this issue first appeared on a private, secure home network, with Kali 2020.1.

A friend of mine just installed Kali in VirtualBox on a Macbook, and was able to run apt update and apt upgrade without issue, using default settings. Therefore, this issue appears to be restricted to Windows host systems.

@Kunkaa Where/how did you find this solution?

It's either a bug if libgcrypt or (more likely) a bug in virtualbox badly virtualizing some hardware feature to compute checksums. It's nice to have a work around but this should really be fixed where it's broken, aka likely in virtualbox itself.

I have not found any related bug report in https://www.virtualbox.org/report/10

The closest I found is this one: https://www.virtualbox.org/ticket/19695
But here it's really the downloaded data that is corrupted, it's not only the checksum that differs. Still it would be nice to know if disabling HyperV and Container features helps.

One of those who can reproduce the issue should file a bug report there... see https://www.virtualbox.org/wiki/Bugtracker

All right, I'll file a report with VirtualBox. Also, it would be nice to test another linux distro in a VM to verify this - I'll look around and see if I can find a Ubuntu appliance or something similar.

Relatedly, how does one close an issue here?

After a rather long lapse, I have another update. There was an existing VirtualBox ticket for this (https://www.virtualbox.org/ticket/19695), and it appears the issue will be fixed when a VirtualBox version above r140284 is released.

I don't see a way to mark this issue as closed, so I'll just leave it for now -- if a moderator (or someone else) with this ability sees this, feel free to close this ticket.

Also, thank you to everyone who contributed above! As this is my first Kali bug report, I'm grateful for the assistance.

We will keep this bug open until we import virtualbox 6.1.15 (once released).

thumbs up

I'm happy to announce that a post to a Kali Forum topic related to this issue has contributed to its resolution! (Original post https://forums.kali.org/showthread.php?48809-Kali-2020-2-OVA-(VirtualBox)-setup-errors&p=99519#post99519)

Solution (for Windows):
Open the "Turn Windows features on or off" item from the Start search bar and disable the "Windows Hypervisor Platform" entry.

After rebooting my actual computer twice, VirtualBox no longer showed the turtle variant of its virtual CPU icon (which it did previously, and began doing so near the time when this issue appeared for me), and apt update and apt upgrade worked as expected. Also, this change does not seem to have affected my WSL (version 1) installation of Kali Linux, and should thus be completely safe.

Okay, yet another update. I just received an update to Windows 10 version 2004, which enables WSL 2. Unfortunately, WSL 2 requires that the "Virtual Machine Platform" Windows feature be enabled, which causes VirtualBox to return to its slow virtualization mode (with the turtle vCPU icon). For users who need both VirtualBox and WSL, I feel this issue would be best resolved with a VirtualBox setting to select the virtualization mode (if that's even possible).

virtualbox version 6.1.16 is now in kali-rolling