Love the idea! Here are few things that might be worth a closer look:
1) "... if someone can dump the indexdb data stored in your browser they can access your AES Key and impersonate the device ..." - I was surprised to read that index DB stores the AES key. Is that a "Shared Secret Session Key" negotiated via ECDH? If so, it should not be stored. Only the Public Key of the ToothPaste device (obtained during the "Pairing" process) should be stored in the browser's indexdb, preferably HMAC'ed or otherwise authenticated (via password-derived local client-only symmetric key which you already seem to be using)
2) "... ToothPaste allows encrypting this local data, along with saved Macros and Duckyscript scripts, using a Password + Argon2 derived encryption key ..." - make sure you are using random salt here, and deriving from (password+salt), not just (password). The salt should be stored in the plain text in the indexdb. Also, since this derivation runs in the browser (not in the MCU), try using Argon2id flavor of Argon to also make it memory-hard, not just compute-hard
3) from the animated gif demo, it looks like the BLE packets are being sent on every key stroke as you type. At the very least, you may leak your BitLocker password length. I would rather send the whole thing once user finished typing and pressed enter, or took more steps to obfuscate by padding with random dummy data and sending every 0.3 seconds
4) you never mention what MODE of AES are you using. I think you should be fine with GCM mode with random nonce, using "Message Number" as Associated Data (see next point)
5) you probably need a protection from "Replay" attack, i.e. encrypted BLE packet "replayed" by attacker. Could be done by ever increasing Message Number on a sender side, and receiver keeping track of the "last Message Number" and only accepting messages with higher number than "last Message Number" - for both directions you need 2 independent numbers. Also, Message Number is a good thing to put into Associated Data if you use AES GCM mode
6) every session should start from ECDH negotiating a brand new AES key - this way you dont have to deal with a long-living AES key, do not need to store it anywhere, and do not have a risk of using the same AES GCM key for too many messages or too much data
Looks nice - congrats! I've only checked a few components and I liked the fresh look of the Alert Dialog. Here is an observation - for a long time Blazor UI libs (looking at you MudBlazor) were missing Splitter component (a draggable separator for resizing UI panels). I had to make it myself when I needed it for my project's Blazor apps. Interestingly, your lib is also missing a Splitter component. To me that is one of the essential components for apps targeting full-sized desktop screens. Maybe consider putting it on a roadmap? Thanks and good luck with your project!
If you need strong security, then any Google Pixel starting from Pixel 8 (The Pixel 8's chip includes ARMv9 architecture, which supports MTE and Branch Target Indicators (BTI) for enhanced memory safety that provides protection from entire class of exploits). Get one with unlocked bootloader (available starting from $250 on ebay). Flash the Graphene OS - not really "fun" but the most secure option if that is what you need.
The most practical option is probably to get Google Pixel 9/9A and use it as is with the latest Android, Google AI, etc. Also having an option to flash something else (like Graphene OS) if needed
1) "... if someone can dump the indexdb data stored in your browser they can access your AES Key and impersonate the device ..." - I was surprised to read that index DB stores the AES key. Is that a "Shared Secret Session Key" negotiated via ECDH? If so, it should not be stored. Only the Public Key of the ToothPaste device (obtained during the "Pairing" process) should be stored in the browser's indexdb, preferably HMAC'ed or otherwise authenticated (via password-derived local client-only symmetric key which you already seem to be using)
2) "... ToothPaste allows encrypting this local data, along with saved Macros and Duckyscript scripts, using a Password + Argon2 derived encryption key ..." - make sure you are using random salt here, and deriving from (password+salt), not just (password). The salt should be stored in the plain text in the indexdb. Also, since this derivation runs in the browser (not in the MCU), try using Argon2id flavor of Argon to also make it memory-hard, not just compute-hard
3) from the animated gif demo, it looks like the BLE packets are being sent on every key stroke as you type. At the very least, you may leak your BitLocker password length. I would rather send the whole thing once user finished typing and pressed enter, or took more steps to obfuscate by padding with random dummy data and sending every 0.3 seconds
4) you never mention what MODE of AES are you using. I think you should be fine with GCM mode with random nonce, using "Message Number" as Associated Data (see next point)
5) you probably need a protection from "Replay" attack, i.e. encrypted BLE packet "replayed" by attacker. Could be done by ever increasing Message Number on a sender side, and receiver keeping track of the "last Message Number" and only accepting messages with higher number than "last Message Number" - for both directions you need 2 independent numbers. Also, Message Number is a good thing to put into Associated Data if you use AES GCM mode
6) every session should start from ECDH negotiating a brand new AES key - this way you dont have to deal with a long-living AES key, do not need to store it anywhere, and do not have a risk of using the same AES GCM key for too many messages or too much data