Hacker News Reader

Comment by linuxandrew | Hacker News Reader

I always though the 16 bit port was too little.

GNUNet CADET (admittedly a very experimental and non-production system) uses a 512 bit port number. A port can be a string, like "https" or "my-secret-port" which is hashed with SHA-512 to produce the port number. I like this idea very much and dream of it becoming a reality on the web.

View on HN

Why 512 bits? Even 128 bits is probably overkill unless you're intentionally trying to mine for collisions.

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.

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).

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.

> 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.

Is there no compression on that sort of data?

If you start thinking about birthday attack scenarios 128 bits might start to feel uncomfortably small.

I like the idea, but if we can extend or change the protocols why use ports at all? Use IPv6 but assign the last two or more octets to individual services routed on the hosts.

Reply on news.ycombinator.com