> I've got a hard time imagining they were going for a solution other than you adjusting the base.
I agree that this is probably what they were going for, but it still seems a bit ridiculous that the conversion from numbers to the chosen representation is not subject to the same rules (i.e., you can call `.toString(15)`, and this definitely uses numbers under the hood!). If this is allowed, then you could also encode your numbers as the string "{n % 3}{n % 5}" and be done with it. Or if they wanted a unique encoding, "{n}{n % 3}{n % 5}" would work too!
I'm no cryptographer, but I would say that it is indeed the case that you can assume that two parties can derive a shared key over an untrusted channel. The post Cryptography Right Answers PQ [1], linked in another comment, addresses this in the section "Key Exchange". Rather than thinking about Diffie-Hellman directly, you would turn to a Key Exchange Mechanism (KEM).
Before post-quantum cryptography concerns, KEM were indeed mostly built on top of Diffie-Hellman key agreement, but you could also build one on top of RSA, or on top of some lattice constructs. But you wouldn't build one yourself, there are good constructions to choose from! The OP actually has a 3-part series on KEMs, although I don't think it addresses post-quantum issues [2].
Released today, I've started exploring the first games, and I completely agree with the review so far! No affiliation, just a happy retro gaming fan pleased with the result. I thought it might also scratch an itch for the rest of the HN crowd.
I developed IP-over-OSPF for a networking class four years ago. It continues with the great tradition of IP-over-<FOO> demos, many of which can be found on HN [1].
One neat thing about this version is that it makes it possible for two machines to communicate over IP, _before the network is even done being configured_! Indeed, two machines could be communicating with IP-over-OSPF even before OSPF is done setting up the routing tables.
But the real "aha!" comes from the realization that IP-over-OSPF should really be called tap-over-OSPF or Ethernet-over-OSPF: it gives you an Ethernet link built on top of the OSPF protocol. All the machines connected to the same OSPF "network" (known as an autonomous domain) are conceptually on the same link.
But what if you wanted two machines on _different autonomous domains_ to communicate? If you have an OSPF router present on both autonomous domains, this machine could be forwarding between one "link" to the other. And how do you setup IP addresses across these links then?
You may need to run OSPF over IP-over-OSPF... and you know what you could try next!
Useful? Probably only for a BOFH in need of a quick "network infrastructure upgrade" before the intern takes over.
I agree that this is probably what they were going for, but it still seems a bit ridiculous that the conversion from numbers to the chosen representation is not subject to the same rules (i.e., you can call `.toString(15)`, and this definitely uses numbers under the hood!). If this is allowed, then you could also encode your numbers as the string "{n % 3}{n % 5}" and be done with it. Or if they wanted a unique encoding, "{n}{n % 3}{n % 5}" would work too!