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
Delphi was so ahead of its time (a mandatory remark)... I've used Delphi 1 to 4 then moved on to other things. Using .NET since 1.0 beta, and it still remains my favorite stack. The project I am currently building is a software infra for building E2EE applications, and it requires a little bit of everything - mobile apps for key management, desktop/cli apps/client libraries for actually encrypting data, sometimes a web based app, and a zero trust backend. Using Xamarin/MAUI for mobile apps, Blazor WASM for Web, Blazor Hybrid / MAUI / Avalonia UI for Desktop. All of the frameworks have their quirks, so it may take a bit of time to learn your patterns, build your base classes, but after that you pretty much enjoy the productivity of a modern high level language.
- What programming languages and frameworks are popular for desktop apps?
- for me - Blazor Hybrid / MAUI / Avalonia UI / WinForms
- Are there any go-to IDEs, build tools, or libraries that make development easier?
- I use MSVS 2022, VSCode for .NET, IntelliJ for $$$ at work. There are of course UI control libraries, I am using MudBlazor for Blazor WASM / Hybrid, other than that I use built-in controls that come with each framework. I try to use as little as possible of 3rd party libraries b/c my apps are security-sensitive.
- Do the above answers change if you care about code performance or efficiency (whatever that means to you)?
- in my case no, I am able to find what I need in .NET ecosystem. Modern .NET supports ahead-of-time compilation compiling to native code, and that helps to reduce start-up time which is important for Desktop / CLI. Ironically, for a long running processes, like a web service, the just-in-time compilation sometimes produces code running faster than ahead-of-time compilation, b/c it learns most common execution paths at runtime, and is able to recompile on the fly, optimizing for most frequent execution paths, giving a non-trivial performance boost in some cases
- Is native desktop app development still viable as a career, or are most greenfield projects shifting to web-based alternatives
- depends on the app/use case. For my project, desktop is the first class citizen, but I am building E2EE apps, i.e. end-to-end-encryption apps, aka client-side encryption, and native / Desktop / CLI is a better fit for E2EE in most of the cases compared to web apps. For those Web apps that I have it is still E2EE but in the browser (still client side encryption)
Congrats! Nicely done! Conway's Game of Life was my first attempt at assembly programing for a self-soldered ZX Spectrum's Z-80 CPU clocked at 3.5 Mhz. Compiled to 383-byte long binary, managed to do about 100 generations per second for a 3-cell blinker oscillator. My friend did a naive BASIC version brute forcing every single pixel on the screen, doing about 1 generation per 2 minutes. I started from BASIC version doing about 1 generation per 3 seconds. The main algo optimization was to have a list of active cells and only processing directly adjacent cells, and ignoring the majority of unpopulated white space. The next optimization was moving cells processing to assembly (the 383 bytes module). It was also toroid-shaped field, exactly like in your implementation. We had a lot of fun watching all those oscillators and guns producing gliders.
Encryption is only mentioned 4 times. Also this is just wrong: Do not accept serialized objects from untrusted sources, and if you must send one yourself across a network, encrypt it first with a private key, then decrypt it on the other end to ensure its integrity before deserializing it
Congrats to AvaloniaUI team! I’ve done both MAUI and Blazor Hybrid desktop apps development recently. MAUI is ok for mobile and simple desktop, but lacks Linux support. Blazor Hybrid is ok for all platforms but it is a bit too heavy, ui controls lifecycle is weird and takes time to get used to, and some security critical apps could be better off without WebView2 . So I am looking forward to redevelop some of my apps with Avalonia UI in the coming weeks! Thanks guys you are doing a great job!
I am working on QRID.com - encrypt your data via QR code.
Build E2EE applications that encrypt data on the client-side without using passwords. Instead of entering passwords, use QRID app to scan QR code displayed by the E2EE application. Got mobile apps for both iOS and Android. Also developed some cross-platform E2EE applications like Password Manager, E2EE Notes, Vault (encrypts files and directories into .vault file), and some command line tools to encrypt/decrypt files, environment variables. Few other things I am really excited about are in the works.
I've recently built "native" Windows / macOS Password/Secret Manager application using Blazor Hybrid with MudBlazor UI library (.NET8). That Password Manager application must be used together with the accompanying IOS/Android mobile app (Xamarin now migrated to MAUI) that manages master keys (KEKs) and wraps/unwraps data encryption keys (DEKs) used by the Password Manager application.
To be honest, Blazor UI controls / object model / lifecycle takes some time to get used to. However, MudBlazor library does help here, as well as finding your own patterns and just building on top of your own base classes.
With the same stack i.e. Blazor Hybrid / Blazor WASM / MudBlazor, I've also build Secure Mail Client, Notes, File Encryption application, and also a number of CLI utilities related to encryption via QR codes.
Overall, I do recommend Blazor Hybrid for a cross platform desktop application with simple to medium UI complexity.
I would strongly recommend joining all technical meetups in Toronto, like TechTO and others. Go to meetup dot com website and see what is available in Toronto area. Another events website worth checking might be eventbrite dot com. Go to those events, meet people, strike conversations. It is a lot of fun, sometimes free drinks and pizza, and it will definitely put you face-to-face with people who are IT professionals, and some may be hiring. Also, do not ignore recruiting agencies. Randstad.ca used to be one of the best for IT talent. Good luck in your job search!
Hey I like your project, earned a star from me! When time allows, will take it on a test drive to see how exactly it works with Roslyn/C# data. My C# solution has grown to about 80 projects so it would be good test.
I've spot-checked few logos that I need at the moment, and most of them are already there. However, I've noticed that there is no IndieHackers logo in the database.
I wonder if it is possible to come up with the tool where you would enter the Home Page Url and the tool would then output an SVG file of round or square shape that could be used as an SVG icon to represent links to that site (from my site).
The tool could try to detect the logo image on the home page of the target site, vectorize and normalize it into square or circle. Or it could try to locate a Favicon in SVG format, if present. Or, if nothing else works, it could fall into some default case when the SVG icon would be created from the most dominant color (of the target site) and 1 or 2 letters of the site name.
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