> 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!
The toString wasn't used in the solution. It was used in creating the solution. Encoding the numbers as your given string exceeds the max length of an encoded character per the rules.
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].
Just want to point out that the article specifically says to use an authenticated KEM (AKEM). A normal, unauthenticated KEM would not work as it provides no authentication. There are no post-quantum authenticated KEMs as yet.
There are post quantum KEMs though that authenticate with a classical mechanism, which limits quantum attacks to interactive from the previous total breakage of recorded ciphertext exchanges (e.g. Wireshark capture at a router encountered in both directions of the traffic flow).
Google's post-quantum TLS experiments that were done in public via Android Chrome are such; basically you just do normal TLS handshake but stack the key derivation from the traditional DH-type perfect-forward-secrecy exchange with a post-quantum-perfect-forward-secrecy exchange that you all seal under the same handshake authentication, and where you make sure to only use post quantum symmetric primitives to fuse the traditional session key material with the PQ session key material such that you don't rely on either one's resistance to keep your secrets secret.
Sorry I don't have a link quite on hand right now.
OK, sure. As far as I’m aware, nobody’s actually made that into an actual AKEM proposal though. (I wish they would, as I think many applications would be fine with pre-quantum authentication and post-quantum confidentiality).
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.
In one of the first couple of games (looks like Loderunner), start the game, go to the first screen to the left. While in that screen, open the Terminal. You'll see uh something in the hex code. Try typing it into the terminal :).
The number "50" is not so accurate.
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 think the limitation you are describing is one of the two aspects of the expression problem[0]:
- with objects you can easily add new types, but it's difficult to add functions (methods) dealing with these types
- with sum types you can easily add new functions, but it's hard to add new variants in the sum type
Is it possible to overcome these limitations? I first read about the expression problem in the excellent post "The Expression Problem and its solutions"[1] on Eli Bendersky's blog (discussed here[2] on HN); as the title suggests it does present interesting ways to "solve" the expression problem.
However he also points out that the chosen solution in a a typical programming language (visitor pattern) quickly becomes unwieldy. The second solution (multimethods) is much nicer to deal with, but requires support from the language.
It seems like these treatments tend not to get to the heart of the expression problem as seen in actual language tools, which is migration between language versions. Let's say you're on version 5 of a language and you want to migrate all your tools to support version 6 where there is a new expression type. Can your codebase clearly represent a situation where some tools have been migrated to support version 6 and others aren't done yet? Can you easily figure out what remains to be done? And once the migration is done, can we remove any traces of the previous version that we don't want anymore?
And how do we approach this if the AST is published as a library and each tool is a package written by a different team?
There might be other usages of sum types that are simpler, though.
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!