My only comment is:

Key management is an absolute pain in the butt.

Regarding keys -- When not in use (ie standing somewhere) the half-keys should be encrypted - both on the user side and the system side. Otherwise they are sitting ducks. Largely for internal attacks. Because internal people are less likely to set off security alarms or be seen in scans.

Whenever someone cracks your code for the key encryption algorithm, then they win. Period.

IMO, in this situation you have to affix value as an ROI to an operation. The ROI is the return on investment - your time, money, and effort.

There is always somebody who will claim such and such can be cracked. This is fog.
Unless forward perfect secrecy is mandated take a value-based approach.

And if theoretical cracking may be true: are you providing code where FIPS 140-3 is mandated? FIPS 140-3 - Wikipedia, the free encyclopedia

If not mandated, then what you try to do is make it hard to crack what you have done to encrypt things. Is it worth the costs of getting to perfect? - if it exists.

If you use a decent block cipher, you are good. If somebody can reverse engineer code, or get your source easily, then most things you can do are pointless. Shell coders love source. That is the ROI I'm talking about. Spend resource in several areas for much bigger return.

This is a values call, not something completely subject to theorematic analysis. It ain't black and white.

And. key-keeping and encryption is only 1/20th of security. User hygiene (keep malware off user desktops), least privilege, password quality and ageing, and all sorts of physical security methods are required, i.e., VPN, firewall, DMZ, carefully controlled access to tapes and data centers, locked doors and file cabinets, etc.

Bottomline:
Make it hard enough on the bad guys so they go somewhere else.
If the equivalent of a stuxnet is attacking your system, you are dead. No matter what you do.