You could also make your "additional data" the IP address of the person sending the message. This would have a similar effect. (Of course, you'd have to worry about proxies and NAT. Using a TLS channel ID is so much cleaner.)

For example, if you use the TLS channel ID of the connection you're transmitting over as "additional data", the recipient will only successfully validate the message if they provide the same "additional data" during the decryption. Since the recipient gets the TLS channel ID not from the message but from their own TLS stack, transmitting the same (otherwise-valid) message over the wrong channel, as in a replay attack, will result in the recipient's validation failing.

Authenticated encryption modes verify that the message is valid as well as encrypting it. AEAD modes do that, but also verify "additional data" that is not part of the encrypted message. Essentially, whatever you choose to use for the additional dat gets hashed into the MAC component by the AEAD mode.

Nope. (Thermal considerations notwithstanding). There will be an even greater threat though: malware in binary blobs on a chip with no storage cannot save state across power cycles. Built-in flash would make the blobs go away, but increase the capabilities of any malware.

While I'd argue that a meaningfully malicious FPGA would be really hard-or impossible-to produce, that doesn't change my point that using binary blobs is no more dangerous than trusting your CPU vendor in the first place.

To be truly safe, you need to use an open hardware processor. (Of course, those are much less powerful than ordinary CPUs.)

Every modern CPU uses a form of microcode. Whether it is stored in the chip or delivered by software at each power on (via binary blobs) makes no difference to whether it can be malicious. Binary blobs represent no extra threat.

@schroeder I have seen many examples of even self-professed power users who either think that MAC filtering is sufficient security alone or that it enhances security enough to allow them to choose easy-to-remember passwords. In these cases, turning on the MAC filter actively reduces security. Even if it is practically good enough - or even better than an easily-sharable password - for access control purposes in these scenarios, the resulting poor choice of PSK guts your expected confidentiality protection.

Also important to note that RADIUS-as-a-service is a thing that exists, if you prefer throwing money at the problem to rolling your own.

One bit of good news with these schemes is that they discard a lot of output bits. That means that the attacker will (probably) get a lot of false positives.

@PeterGreen Ah, you caught that! I'm kind of splitting hairs, to make it possible to give a unified description of both the traditional RSA key exchange as well as the ephemeral DH/ECDH protocols. In both, the generation of the session key does indeed require no private key; even in traditional RSA it's still generated on the client, without any private key. The server doesn't know it yet, but it has been established. I then said that the server must decrypt "an essential part of the session key exchange process," which in this case refers to the message telling it what the key is.

@AndrewPhilips I was perhaps a bit overzealous in my use of hyperbole :) I've made an edit to clarify the situation.