3 ms·

They use SHA-2-512 everywhere else already, presumably for post-quantum resistance. I guess it gives them a smaller cipher footprint? They use the same data typ

They use SHA-2-512 everywhere else already, presumably for post-quantum resistance. I guess it gives them a smaller cipher footprint? They use the same data type in their codebase for hashes? 512 bits is sufficiently future proof? Future use cases that haven't been thought of yet, that require a secure hash? 64 bytes isn't that much overhead? But I'm really just guessing, I'm not sure what their reasons are. I agree in principle - SHA-2-256 could be a reasonable hash function whilst maintaining the properties of a secure hash function - or less than that if collision resistance isn't needed.

vlovich123 5y ago
Post quantum resilience feels like overkill for port numbers since they’re not secret (if it was you wouldn’t be able to connect). 32bit or even 64bit would be more than enough in terms of extending our current scheme. If you wanted to use a resistant collision hash of an arbitrary service string, 128 bits would also be enough and even 64 bits might be too (again - these aren’t secret so you’re only trying to avoid collisions and to resist port enumeration attacks).
- staticassertion 5y ago
  Post quantum resilience absolutely is overkill even if they are secret, since they're not the type of secret you'd care about that for imo. But I suspect "we have a 512bit port space" is intended to make them secrets ie: impossible for an attacker to bruteforce, at which point you run into birthday attacks, so you're talking about the square of the space. Even still 512bit is too high imo, 192bit should be fine.
bajsejohannes 5y ago
> 64 bytes isn't that much overhead? On the contrary, 64 bytes is a huge overhead. The standard maximum transfer unit (MTU) is 1500 bytes. So 64 bytes is 4.2% of the packet (at best!). Add the fact that you need a source and destination address, that's 128 bytes, or 8.5% of the MTU. Or, if you will, 8.5% (or more) of internet traffic, just in port numbers. Maybe I'm misunderstanding the suggestion, but it would be a terrible idea to have 512 bit port numbers in TCP/UDP packets.
- staticassertion 5y ago
  Is there no compression on that sort of data?

vlovich123 5y ago

Post quantum resilience feels like overkill for port numbers since they’re not secret (if it was you wouldn’t be able to connect). 32bit or even 64bit would be more than enough in terms of extending our current scheme. If you wanted to use a resistant collision hash of an arbitrary service string, 128 bits would also be enough and even 64 bits might be too (again - these aren’t secret so you’re only trying to avoid collisions and to resist port enumeration attacks).

staticassertion 5y ago
Post quantum resilience absolutely is overkill even if they are secret, since they're not the type of secret you'd care about that for imo. But I suspect "we have a 512bit port space" is intended to make them secrets ie: impossible for an attacker to bruteforce, at which point you run into birthday attacks, so you're talking about the square of the space. Even still 512bit is too high imo, 192bit should be fine.

bajsejohannes 5y ago

> 64 bytes isn't that much overhead? On the contrary, 64 bytes is a huge overhead. The standard maximum transfer unit (MTU) is 1500 bytes. So 64 bytes is 4.2% of the packet (at best!). Add the fact that you need a source and destination address, that's 128 bytes, or 8.5% of the MTU. Or, if you will, 8.5% (or more) of internet traffic, just in port numbers. Maybe I'm misunderstanding the suggestion, but it would be a terrible idea to have 512 bit port numbers in TCP/UDP packets.

staticassertion 5y ago
Is there no compression on that sort of data?