1 comments
Thanks for the detailed feedback! Glad you liked the idea.
A lot of these are me not updating the Readme often enough :p I'll be updating it based on your feedback but I'll also address the points here.
1. It used to be the AES key but I switched to storing the pubkey and local private key, its encrypted with a hardcoded credential even in "passwordless" mode and uses the same encryption scheme as 2.
2. Yup its salted. I'll look into Argon2id, should be a trivial change.
3. Pasted strings are sent as a bulk packet (200 chars at a time + overhead), the gif demo is me typing + pasting so it isn't very obvious. I do agree that typed passwords are still susceptible to the length check, sending noise like you mentioned sounds like a good plan.
4,5. Yeah another readme thing, it is indeed AES-256-GCM. I've considered replay protection but for now I think the tradeoff for managing senders easily just based on pubkey is worth because of the next point
6. Readme moment pt.3 :p, the key is generated from the stored ECDH credentials each time along with a session-specific salt (so replay attacks are only possible within the same session).
Let me know if you have any more ideas though, I'm currently working on the FIDO support but I'll definitely work on your suggestions!
A lot of these are me not updating the Readme often enough :p I'll be updating it based on your feedback but I'll also address the points here.
1. It used to be the AES key but I switched to storing the pubkey and local private key, its encrypted with a hardcoded credential even in "passwordless" mode and uses the same encryption scheme as 2.
2. Yup its salted. I'll look into Argon2id, should be a trivial change.
3. Pasted strings are sent as a bulk packet (200 chars at a time + overhead), the gif demo is me typing + pasting so it isn't very obvious. I do agree that typed passwords are still susceptible to the length check, sending noise like you mentioned sounds like a good plan.
4,5. Yeah another readme thing, it is indeed AES-256-GCM. I've considered replay protection but for now I think the tradeoff for managing senders easily just based on pubkey is worth because of the next point
6. Readme moment pt.3 :p, the key is generated from the stored ECDH credentials each time along with a session-specific salt (so replay attacks are only possible within the same session).
Let me know if you have any more ideas though, I'm currently working on the FIDO support but I'll definitely work on your suggestions!
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