Encrypted Drive Manager - Secure Auto-Unlock Plugin & other tools for Encrypted Arrays

Hey everyone! I wanted to share my first ever official plugin. Now I've been working on this on and off for quite a few months and this plug-in solves a problem I think many of us have with encrypted Unraid arrays.

The Problem

So here's the thing a lot of us are using encrypted arrays, which is great for security. But to get auto-unlock working, most people end up storing their LUKS keyfiles right on the server or downloading them from somewhere online. and referencing them in the go file. It works, but there's a huge security hole: if someone steals your server, it'll just unlock itself using that same keyfile. You basically get zero theft protection.

I kept thinking there had to be a better way to get the convenience of auto-unlock without giving up the security benefits of encryption.

The Solution

This plugin creates what I call "hardware-bound" keys. Basically, it takes your motherboard serial number and your router's MAC address, combines them, and generates a unique unlock key from that combo. The cool part is.

- The key is never stored anywhere - it's generated fresh every boot

- It only works in your specific location with your specific hardware

- If someone steals your server and moves it somewhere else, the router MAC will be different and auto-unlock fails

- Your original passphrase/keyfile stays completely untouched

So you get the convenience of auto-unlock at home, but theft protection if your server gets stolen.

How It Works

It's pretty straightforward to set up

1. Install the plugin from Community Applications

2. Enter your current LUKS passphrase or keyfile once during setup

3. The plugin generates a hardware key and adds it to LUKS slot 31 (the last slot)

4. From then on, your server auto-unlocks using the hardware fingerprint

If you ever change hardware or move locations, just regenerate the key - takes about 30 seconds.

Features

The plugin has three main tabs

- Auto Start: Generate hardware keys and enable/disable auto-unlock

- LUKS Headers: Backup your LUKS headers with encryption (always a good idea!)

- Encryption Info: View detailed info about your encrypted drives and key slots

It integrates with Unraid's native event system, so no messy go file modifications.
Fully responsive design and works with both light and dark themes too.

Installation

Just search for "Encrypted Drive Manager" in Community Applications. You'll need Unraid 6.11.0+ and encrypted drives obviously.

The plugin is completely non-destructive - it doesn't touch your existing LUKS setup at all. Your original passphrase/keyfile keeps working exactly like before.

Important note
If you’ve previously set up a script in your go file to download a LUKS key from elsewhere for auto unlocking, make sure you remove it when using this plugin. New users who haven’t done this before don’t need to worry about it.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Security Note
This plugin's auto start feature isn’t as secure as manually entering your passphrase or keyfile every time you start the array. In theory, it’s possible for a determined attacker to brute force the hardware derived key. But that’s not what this feature is aiming for. It’s designed for people who want the convenience of auto unlock while avoiding the much bigger risk of leaving plain keys on the flash drive or pulling them from the internet at boot. It’s a middle ground, not perfect security, but a safer and more practical option than what many users were already doing.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If you want all the technical details and security explanations, I've put together comprehensive documentation here

GitHub

GitHub - SpaceinvaderOne/encrypted-drive-manager

Contribute to SpaceinvaderOne/encrypted-drive-manager development by creating an account on GitHub.

Would love to hear what you think! Any future feature suggestions? Let me know if you have any questions or run into any issues.

Looks cool.

This in the install log

Encrypted Drive Manager version &plugin_version; has been installed.

I would like to use the mac from another device in the network (hidden, not as easy to access as the router).

Edit
Btw, my serial number is MB-1234567890. ;)

Edited September 27, 2025Sep 27 by Niklas

This is a great plugin! Definitely something that should eventually be integrated into Unraid I think, great job.

Agree with Niklas, would be good to have a configuration parameter to give it an IP to get the Mac address and use that. I've been doing something similar where I use a small device in my home that is hidden and go grab the key via SSH, and then delete the key once the array is started.

I don't see a way to export the key. Is it possible? I want to make sure that I will be able to recover the data in the event the server or the router dies.

11 minutes ago, PierreT said:

I don't see a way to export the key. Is it possible? I want to make sure that I will be able to recover the data in the event the server or the router dies.

have this question myself, is it possible to save the generated key somehow to start the array if it is stopped after the auto-start happens?

or does the user's previous key still work in addition to the key generated by this plugin since they're in different slots?

Just now, john_smith said:

or does the user's previous key still work in addition to the key generated by this plugin since they're in different slots?

The original key will work, yes.
It's in the linked docs.

5 hours ago, PierreT said:

I don't see a way to export the key. Is it possible? I want to make sure that I will be able to recover the data in the event the server or the router dies.

The backup is essentially unnecessary, as the original key remains preserved and valid.

LUKS2 has 32 key locations. This means you could create 32 keys and use each of them to unlock the drive.

A self-created key remains fully preserved and valid. The plug-in adds a second, independent key. The drive can be unlocked with either key.

If the plug-in key is ever lost (router/MB defective), you unlock the drive with your first key and simply create a new one for the plug-in.

12 minutes ago, Synoxion said:

The backup is essentially unnecessary, as the original key remains preserved and valid.

LUKS2 has 32 key locations. This means you could create 32 keys and use each of them to unlock the drive.

A self-created key remains fully preserved and valid. The plug-in adds a second, independent key. The drive can be unlocked with either key.

If the plug-in key is ever lost (router/MB defective), you unlock the drive with your first key and simply create a new one for the plug-in.

Yes you dont really ever need the know what the derived key is, as the orginal key is unchanged and works as it always did (it is not replaced). But a backup is actually made in the setup process.
When a hardware derived key is created, the plugin automatically generates a complete backup. All LUKS headers are saved into an encrypted zip file, with each header tagged by its disk UUID. The archive also includes a detailed report showing the hardware derived key, the status of all slots on each drive, and the hardware identifiers used to derive the key, ie the router MAC address and motherboard serial number.

The zip is encrypted for security. If your orginal LUKS encryption uses a passphrase, that same passphrase is used to protect the backup. If a key file is used instead, you will be prompted to set a password for the zip.

Also if either hardware anchor (the router or motherboard) is changed, the plugin detects this and prompts you to generate a new hardware-derived key. The new key is then written into slot 31, replacing the old one.

7 hours ago, Stokkes said:

would be good to have a configuration parameter to give it an IP to get the Mac address and use that. I've been doing something similar where I use a small device in my home that is hidden and go grab the key via SSH, and then delete the key once the array is started.

Thanks for the suggestion  I really appreciate you thinking about ways to improve the plugin.

After looking at it, I think the router MAC method is still the best fit. The MAC address itself isn’t the key, it’s just one part of the hardware fingerprint along with the motherboard serial. Whether the MAC comes from your router or another device, the cryptographic properties are the same. The protection really comes from the fact that if the server is moved to a different location, it will see a different router MAC and the auto unlock will fail.

Routers also have the advantage of being stable and on 24/7 with every network having one. The plugin can detect the default gateway automatically, so there’s nothing to configure and no need to worry about IP addresses or DHCP changes. Using a hidden device with SSH works too, but it adds a few more potential failure points , the device might be offline, its IP could change etc

Part of the design goal was to keep the plugin simple and seamless, only prompting the user when absolutely necessary. Adding IP configuration would mean people need to know more about their network setup, and it would open the door for more issues for beginners. For now at least, the router-based approach feels like the best balance of security, reliability, and simplicity. 

If the server is stolen, I assume an attacker would only need to try different MAC addresses to unlock? Since those are prefixed with vendors numbers and short, it would not take much effort to crack the password.

I haven't looked at the source code, so please correct me if I am wrong.

Did everything, enabled autostart, removed the copy procedure from go file.

Result above.

It unlocked the pool devices tho, not the array (wrong passkey).

?

Edited September 28, 2025Sep 28 by dhstsw

4 hours ago, chripede said:

If the server is stolen, I assume an attacker would only need to try different MAC addresses to unlock? Since those are prefixed with vendors numbers and short, it would not take much effort to crack the password.

I haven't looked at the source code, so please correct me if I am wrong.

Yeah I can see why it might look that way at first glance. But the situation is a bit different in practice.

The plugin doesn’t just use the MAC address by itself. It builds a key from both the motherboard serial and the router’s MAC, then runs that through a SHA-256 hash. For an attacker to try brute forcing, they would need to know not only that this plugin is being used but also that the hardware-derived key is what’s unlocking the drive. From the outside looking at the server, all they would see is the normal Unraid prompt to enter a passphrase/keyfile. They would be able to know the motherboard serial if they steal the server, but guessing the MAC is still a massive problem space. A MAC address is 48bits long that’s over 281 trillion possible values. Yes, the first three bytes are vendor specific, but each vendor has millions of possible device combinations. That quickly becomes unworkable for brute forcing. The plugin isn’t designed to turn Unraid into a maximum security appliance. Its goal is to make auto unlocking practical in the most secure way possible, without having to drop key files onto the flash drive or fetch them from the network etc etc. I think the plugin is also useful just for header backup feature too.

3 hours ago, dhstsw said:

Did everything, enabled autostart, removed the copy procedure from go file.

Result above.

It unlocked the pool devices tho, not the array (wrong passkey).

?

Don’t worry, you haven’t lost any data. What’s happened is that your array drives don’t seem to have the extra key in slot 31. On reboot the server was able to unlock the pool automatically, but because that key isn’t present on the array drives, they stayed locked. That’s why they’re showing as “unmountable :wrong filesystem”.

Before changing anything, could you please grab a diagnostics file and either attach it here or send it to me in a PM? After that, go into the plugin and disable auto-unlock, then restart the server. When it comes back up, enter your original encryption key manually, that will mount all your drives.

Once they’re mounted, open the plugin again, run “Encryption Info” with the “Very Detailed” option, and share the output (either paste it here or PM me). My guess is that slot 31 on the array drives will be empty. The plugin has a safety check that skips adding an extra key if it couldn’t make a header backup, and I think that’s what’s happened in your case.

Several items here --

First, my attempt to configure the plugin on one of my test systems immediately failed, claiming my very simple passphrase (unraid-testing) is incorrect.

Second, and more importantly, claiming that this is "making auto unlocking practical in the most secure way possible" isn't a fair statement, because (as mentioned) it vastly reduces the key strength of the underlying encryption.

The motherboard serial is irrelevant, since if someone stole the server, they have that.

Let's assume that, with the MAC address, there are 2^30 possible combinations (the second half of the MAC address (24 bits), plus 6 bits of possible OUIs, understanding that the more common the router, the faster it is to crack). In comparison, the minimum-acceptable key length for AES is usually considered to be 128 bits.

2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible combinations.

2^30 = 1,073,741,824 possible combinations.

"Millions of combinations" is trivial with modern hardware (even with a pass of SHA256). Fortunately, LUKS uses a key derivation function (KDF) which helps mitigate the impact of insecure passphrases by doing a set of computationally-complex calculations. Modern installations of LUKS use Argon2id with a target to calculate the final key in 2 seconds (in other words, when you initially create the key, it runs enough iterations to take about 2 seconds). This also means, though, that slower hardware gets less secure keys (it can do fewer iterations in 2 seconds). So, if you take the key to a faster system/more cores/etc., you can do those calculations much faster. (To put this in context -- based on some quick calculations I did, I think it would cost about $8000 to break most keys in AWS in one hour.)

That's not to say that this is a bad idea inherently. However, it needs to be clear -- you are giving up a large amount of cryptographic security for convenience with this plugin. It also doesn't appear to remove that insecure key on uninstall -- so if you forget to remove it before uninstalling, your system remains insecure (with no way to see that).

1 hour ago, SpaceInvaderOne said:

Yeah I can see why it might look that way at first glance. But the situation is a bit different in practice.

The plugin doesn’t just use the MAC address by itself. It builds a key from both the motherboard serial and the router’s MAC, then runs that through a SHA-256 hash. For an attacker to try brute forcing, they would need to know not only that this plugin is being used but also that the hardware-derived key is what’s unlocking the drive. From the outside stating the server, all they would see is the normal Unraid prompt to enter a passphrase/keyfile. They would be able to know the motherboard serial if they steal the server, but guessing the MAC is still a massive problem space. A MAC address is 48bits long that’s over 281 trillion possible values. Yes, the first three bytes are vendor specific, but each vendor has millions of possible device combinations. That quickly becomes unworkable for brute forcing. The plugin isn’t designed to turn Unraid into a maximum security appliance. Its goal is to make auto unlocking practical in the most secure way possible, without having to drop key files onto the flash drive or fetch them from the network etc etc. I think the plugin is also useful just for header backup feature too.

1 hour ago, SpaceInvaderOne said:

Yeah I can see why it might look that way at first glance. But the situation is a bit different in practice.

The plugin doesn’t just use the MAC address by itself. It builds a key from both the motherboard serial and the router’s MAC, then runs that through a SHA-256 hash. For an attacker to try brute forcing, they would need to know not only that this plugin is being used but also that the hardware-derived key is what’s unlocking the drive. From the outside looking at the server, all they would see is the normal Unraid prompt to enter a passphrase/keyfile. They would be able to know the motherboard serial if they steal the server, but guessing the MAC is still a massive problem space. A MAC address is 48bits long that’s over 281 trillion possible values. Yes, the first three bytes are vendor specific, but each vendor has millions of possible device combinations. That quickly becomes unworkable for brute forcing. The plugin isn’t designed to turn Unraid into a maximum security appliance. Its goal is to make auto unlocking practical in the most secure way possible, without having to drop key files onto the flash drive or fetch them from the network etc etc. I think the plugin is also useful just for header backup feature too.

Appreciate the info. However, an attacker knowing this would only need to use prefixes from the top producers of consumer network gear. This cuts the number of MAC addresses down by a lot.

I think it needs to be said somewhere in the plugin that this is not a very secure way to decrypt your data.

20 minutes ago, EDACerton said:

Several items here --

First, my attempt to configure the plugin on one of my test systems immediately failed, claiming my very simple passphrase (unraid-testing) is incorrect.

Second, and more importantly, claiming that this is "making auto unlocking practical in the most secure way possible" isn't a fair statement, because (as mentioned) it vastly reduces the key strength of the underlying encryption.

The motherboard serial is irrelevant, since if someone stole the server, they have that.

Let's assume that, with the MAC address, there are 2^30 possible combinations (the second half of the MAC address (24 bits), plus 6 bits of possible OUIs, understanding that the more common the router, the faster it is to crack). In comparison, the minimum-acceptable key length for AES is usually considered to be 128 bits.

2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible combinations.

2^30 = 1,073,741,824 possible combinations.

"Millions of combinations" is trivial with modern hardware (even with a pass of SHA256). Fortunately, LUKS uses a key derivation function (KDF) which helps mitigate the impact of insecure passphrases by doing a set of computationally-complex calculations. Modern installations of LUKS use Argon2id with a target to calculate the final key in 2 seconds (in other words, when you initially create the key, it runs enough iterations to take about 2 seconds). This also means, though, that slower hardware gets less secure keys (it can do fewer iterations in 2 seconds). So, if you take the key to a faster system/more cores/etc., you can do those calculations much faster. (To put this in context -- based on some quick calculations I did, I think it would cost about $8000 to break most keys in AWS in one hour.)

That's not to say that this is a bad idea inherently. However, it needs to be clear -- you are giving up a large amount of cryptographic security for convenience with this plugin. It also doesn't appear to remove that insecure key on uninstall -- so if you forget to remove it before uninstalling, your system remains insecure (with no way to see that).

Hey EDACerton, thanks for taking the time to test the plugin and share your thoughts I really appreciate it.

You’re absolutely right that a hardware derived key isn’t as cryptographically strong as a long random passphrase. That’s by design. The plugin isn’t trying to compete with “enter your passphrase every boot” style security if maximum strength is the goal, then the best option will always be to type in a long, random passphrase at startup.

The problem this plugin tries to solve is a practical one. Before this, people who wanted their array to auto start were either putting the key directly on the flash drive or an external place and calling it from in the gofile. These methods mean the key exists somewhere in plain form. I tried to make this plug-in address that and just so it doesn't have the key stored anywhere on disk or online. Yes You're right, having a hardware drive key that reduces the theoretical cryptographic strength, but in practice it’s still stronger than the approaches many people were actually using before.. And for most Unraid users who encrypt drives for peace of mind (RMA, casual theft etc) rather than nation state level protection 😊 that trade off makes sense.

On uninstall, that’s a really good point. Automatically removing the slot-31 key would mean manipulating LUKS headers at uninstall time I just worry about trying to have the plug in remove the keys on uninstall just adds additional points of failure. What are your thoughts about it? But either way I think I should definitely change the plug in so on uninstall, a message does come up and tells the user that the keys are still on their disks and they haven't been removed. I think that's an excellent point you brought up.

But overall, if someone truly needs maximum cryptographic security, they shouldn’t be using any auto unlock method, whether it’s this plugin or a go file script and should stick with a strong passphrase/keyfile entered manually.

So I agree with you on the crypto maths etc but I think the plugin’s value is in offering a safer, more practical option for auto unlock than what users were already doing, not in aiming for perfect theoretical strength. But I think what I'll do is I'll edit the first post here just to make it clear that it does have its downsides for sure.

35 minutes ago, chripede said:

Appreciate the info. However, an attacker knowing this would only need to use prefixes from the top producers of consumer network gear. This cuts the number of MAC addresses down by a lot.

I think it needs to be said somewhere in the plugin that this is not a very secure way to decrypt your data.

I get where the concerns are coming from, but I think some people are missing the point of the plugin. It’s not meant to give maximum-strength encryption if that’s the goal, the best option will always be to enter a strong passphrase or key file manually at every boot.

This plugin is for people who want their array to auto start and, until now, were doing that by storing raw keys on the flash or even downloading them from the internet. Compared to those methods, this is a safer middle ground no keys sitting around in plain form.

I’ll be pushing out an update later this week that adds a clear note in the Auto Start section to say exactly that: it’s not as secure as manual entry, and yes, in theory brute force is always possible.
But IMO if someone is determined enough to go that far, they’re probably getting your data one way or another.

50 minutes ago, SpaceInvaderOne said:

Don’t worry, you haven’t lost any data. What’s happened is that your array drives don’t seem to have the extra key in slot 31. On reboot the server was able to unlock the pool automatically, but because that key isn’t present on the array drives, they stayed locked. That’s why they’re showing as “unmountable :wrong filesystem”.

Before changing anything, could you please grab a diagnostics file and either attach it here or send it to me in a PM? After that, go into the plugin and disable auto-unlock, then restart the server. When it comes back up, enter your original encryption key manually, that will mount all your drives.

Once they’re mounted, open the plugin again, run “Encryption Info” with the “Very Detailed” option, and share the output (either paste it here or PM me). My guess is that slot 31 on the array drives will be empty. The plugin has a safety check that skips adding an extra key if it couldn’t make a header backup, and I think that’s what’s happened in your case.

Yeah, i ripristinate everything 5 minutes after the event.
So i guess i'll have to re-do everything to produce the diagnostics file :-/

For now i can tell you (after producing the very detailed encryption info that:

-All array disks (4) show: Slot 0: Original encryption key

-One standalone disk (i guess one that is mounted with Unassigned Devices) shows: Slot 0: Original encryption key

-Pool devices (2) show: 🔐 Slot 0: Original encryption key
⭐ Slot 31: ⭐ Hardware-derived (2025-09-28 13:20:42 EEST)

So, only the pool devices got the new key in slot 31.
Also, i have 3 pool devices (Cache on a sata SSD, another one on an M.2 and another final one on a mechanical disk). The detailed info reports only 2 ( /dev/sdh1 and /dev/sdi1).

See attacched report.

I'll try again when i'll be drunk enough not to get scared again like 4 hours ago :-/

Thanks.

luks_analysis_20250928_181429.txt

Edited September 28, 2025Sep 28 by dhstsw

Thank you very much for the info, that's really useful. I'm wondering if if there was a bug when it came to looking at the encrypted unassigned disk. And then for some reason didn't go any further and skipped the rest of your disks. I'm about to travel abroad, but I will try and recreate the same as what's happened to you and then push out a fix.

6 minutes ago, SpaceInvaderOne said:

I get where the concerns are coming from, but I think some people are missing the point of the plugin. It’s not meant to give maximum-strength encryption if that’s the goal, the best option will always be to enter a strong passphrase or key file manually at every boot.

This plugin is for people who want their array to auto start and, until now, were doing that by storing raw keys on the flash or even downloading them from the internet. Compared to those methods, this is a safer middle ground no keys sitting around in plain form.

I’ll be pushing out an update later this week that adds a clear note in the Auto Start section to say exactly that: it’s not as secure as manual entry, and yes, in theory brute force is always possible.
But IMO if someone is determined enough to go that far, they’re probably getting your data one way or another.

I understand the point of the plugin.

My objection is in presentation -- the description in CA claims that "Creates hardware-derived keys tied to your server's location and hardware for secure automatic unlocking". It is fair for folks to interrogate what "secure automatic unlocking" means, especially considering that the approach really isn't "secure". That needs to be clear in more words than "brute force is always possible" -- this makes brute force immensely easy compared to a 128-bit key (20ish characters). That would be 2^98 times more difficult, or to put it another way, that $8000 of AWS would become $2,535,301,200,000,000,000,000,000,000,000,000 (and just to put that in context, the global GDP is $111,000,000,000,000).

I also think the claim that it's more secure than other methods is dubious -- other solutions involve creating a keyfile (which is presumably more than 30 bits) and then providing that from another device on the local network. Yes, if someone stole the server and that device, they could get the keyfile -- but if someone stole the server and the router, they get the gateway MAC, and so have both components to build the key. From a threat perspective, this isn't an improvement -- it's just giving up cryptographic strength. The actual "benefit" to using the MAC address isn't that it's more secure -- it's less secure than using a keyfile retrieved from another device -- but that it doesn't require for that other device to be set up (convenience).

I would also suggest that this plugin should be flagged as a beta, given that I couldn't even get it to configure on my (very basic) test server. That makes me think that it doesn't have the testing/operational maturity to be considered "stable"/"production", especially given its potential impact on the system.

And just to be clear -- I don't expect for Unraid to be super-secure, by design it can't be. It uses a boot volume/configuration that can't be encrypted, and that isn't externally verified (so, for example, someone with physical access could replace the boot images on the flash drive with ones that would steal encryption keys, no matter how secure they were, add a plugin/package to steal keys/data, change credentials, etc.) Everything runs as root, increasing the impact of attacks of running services.

However, while Unraid can't be used as a super-secure OS, I still think it's very important to be clear and unambiguous with users when affecting the behavior of sensitive things such as system encryption. The phrasing that being used in replies here doesn't meet that threshold for me, as it seems to be more focused on saying "this is fine" than being plain and honest about what this does.

Users need to be OK with having a 5 character password for their drives -- that's what they're getting.

An approach that would be more interesting (especially given how many users like to set up things like pi-hole, the -sense's, Unifi) would be something where you would configure a DNS TXT record, then the boot looks that up (from the local DNS server) and uses that.

Edited September 28, 2025Sep 28 by EDACerton

@EDACerton I've been thinking a lot about this over the last month or two, the simplicity of having auto-unlock but with some modest security (understanding that if someone wants to really get in, they will) - doesn't mean I can't make it extremely difficult.

The timing of this plugin was kind of odd, but good as provides additional perspective (and these conversations are golden).

I may build something myself (either for Unraid or maybe bring my unraid server back under proxmox and use proxmox to do the decrypting) and thinking I'll adopt 3-4 different dimensions to derive the key.

Good points. I'll stay with my current solution to fetch the keyfile from another device in the network.

Edited September 28, 2025Sep 28 by Niklas

After testing a few times, i'm still unable to get this plugin to work unfortunately myself. Let me know how i can help troubleshoot, as I'd be interested in helping getting it to work and using it myself.

I must say that I really applaud the initiative from @SpaceInvaderOne on this plugin, and if I were to assume anything on behalf of the Unraid community based on myself, I would think many are welcoming such a plugin. That being said it needs to be as secure as possible - with a clear understanding of what that means.

For my own setup I've tested various solutions, and I've landed on an approach were upon boot a request is placed some where in my Tailscale network. I am notified, and I have the option to approve or deny this request. If approved I am asked for a password (for the lack of a better word), which is used to decrypt the key which unlocks my master key-drive. For my setup to work I have highjacked the cryptsetup command on Unraid which allows me to change the default keylocation path used during boot (if only Unraid could supply a config entry for the keylocation). This means that the master key never leaves the encrypted volume, and when disks are unlocked this disk is closed. A rather secure solution, but it does rely on external factors and solutions (which of course can be hosted locally).

This solves a few things (for me):

1) Nothing gets decrypted without me knowing (as I have to provide the master password)

2) I don't need to be at the Unraid console for a successful boot

3) The master key never leaves its location

What it does not solve (yet) is the temporary storage of the key that unlocks the master key, but I plan to make use of the key programatically.

Maybe we could expand on your plugin @SpaceInvaderOne ?

Edited October 6, 2025Oct 6 by Thomas74