I am well aware that the general consensus is that a hashing algorithm with a digest of 1024 bits is unnecessary, but I'm just curious about how that would be implemented for Keccak, even though it isn't necessary.

According to SHA-3 block sizes / bitrate calculation?, the bitrate of the algorithm would be calculated by 1600 - 2c = r. However, with C being 1024, one would get a negative value, which I assume would mean the algorithm will not work for that capacity.

Am I wrong in my assumption? Are there any workarounds that would allow for a capacity this high?

Again, this is just a theoretical question to sate my curiosity. I am well aware that such a level of security is considered unnecessary.

I am well aware that the general consensus is that a hashing algorithm with a security of 512 bits is unnecessary, but I'm just curious about how that would be implemented for Keccak despite that.

According to SHA-3 block sizes / bitrate calculation?, the bitrate of the algorithm would be calculated by 1600 - 2c = r. However, with C being 1024, one would get a negative value, which I assume would mean the algorithm will not work for that capacity.

Am I wrong in my assumption? Are there any workarounds that would allow for a capacity this high?

Again, this is just a theoretical question to sate my curiosity. I am well aware that such a level of security is considered unnecessary.