It might not be the memory concern it once was, but today it might very well be a power concern. Modern laptop display pipelines can save power if they don't have to redraw any of the screen: constantly updating status bar animations break that.[1]
There's code for it in Darwin's libmalloc, but it's not exposed as API.
reallocarray() has some difficulties as an interface, mostly inherited from realloc(). I'm a bigger fan of reallocarr(), but that's NetBSD only. We (the operating systems community) need to find a consensus here, but I'm not convinced that reallocarray() is that consensus yet.
You give the HSM the pin, it returns the key used to encrypt the data, applying the rules to that interaction with you. Emulating the HSM doesn't help since it is that phone's specific HSM with the key it knows that you need to access.
As far as "modern signal handling" goes: On OS X, you can also just create a dispatch source of type DISPATCH_SOURCE_TYPE_SIGNAL. If your code already uses dispatch, this is much easier than trying to wire up to kqueue directly.
I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern:
If my passphrase gets compromised, I have to retire the keypair.
That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed.
With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.
Thinking aloud: could one build a combination fossil fuel and solar steam-powered turbine? When the sun is out, you use (supercritical) steam as they describe being able to generate. If the sun goes away, you feed the same turbine with steam generated with fossil fuels. You could use same turbine, condenser, etc but just switch the heat source (or use both) as the environmental conditions change.
Amazingly, this sort of use-after-free causes compatibility problems for allocator writers even today. Imagine if you change the implementation of malloc() such that smaller allocations get their own mmap() region rather than being stuffed in with other allocations. Now any use-after-free bugs to allocations affected by the change will segfault instead of reading garbage, since the allocator would munmap the region upon free().
Keep in mind: This class is part of a conservatory-style BFA program. These students are already, or will soon be, custom to public critiques. And learning how to accept public criticism, positive and negative, is explicitly a goal of many such programs.
My two cents: While I would have hated such a thing in an engineering class, I really appreciated public discussion and criticism of my work in the arts. I found that such transparency, even when painful, was hugely valuable to me as I grew as an artist.