[Dylan16807]

I'm sure someone will multiply anything by n but that doesn't mean their code is right. I can't think of any legitimate use for thousands of incomplete hashes without so much other memory the hash is dwarfed. Can you?

The argument about streamlined vpn or ssl devices is not relevant here: such a device has to calculate hashes, but it doesn't have to keep hash states open. Hash a message, make/check the signature, forward or discard, O(k) memory use where k is the number of cores.

I agree that a per connection overhead of this size for every TCP connection is a terrible thing, but I think marshray forgot we were talking about places where you use hashes, and keep them open.

[marshray]

During the TLS handshake process, there are multiple running hashes kept of the handshake data.

For TLS records, there's a MAC at the end of each record. The MAC is based on HMAC, the most efficient implemenation involves priming two hash states with the MAC secret in advance. So with send and receive, every TLS connection already has four open hash states.

You're right though that most implementations seem to buffer a full record's data too. One could probably avoid this overhead when sending TLS (if you knew a minimum length in advance).