I think the point most people are trying to tell you is rolling your own crypto is doomed for failure. Near peer nation states fail at this routinely. And that other
free, open source sofrware does exactly what you want. If you have read the the vaultwarden source and dont know if it has redundency then layer it over ZFS.
1 Like
It seems you don’t really need a filesystem. You can use the SD cards as any other (non-volatile) memory block, keeping in mind typical flash limitations (like page erase).
As a crypto-specialist myself I (personally) disagree with the “do not roll your own crypto” principle, but fully agree with “do not roll your own crypto unless you fully know what you’re doing”. There is a lot of room for error and unless you can prove your solution is secure, you should probably not use it in production/for sensitive data.
That said, repeating encryption is usually not the way to go. With 3DES the idea was to increase key space without changing the hardware (as DES was designed primarily for hardware implementation). Even then, there are reasons 3DES uses EDE (encrypt-decrypt-encrypt) scheme and not EEE (encrypt-encrypt-encrypt), and backward compatibility is not the only one.
This depends on the threat model. Usually you want/need a method of detecting whether the decryption was successful. And you usually get an oracle from any encrypted metadata.
You can design a password manager in such a way that you don’t know if a retrieved/derived password is correct unless you try to use it, but then it’s limited to only store PM-generated passwords (and tbf, you don’t even have to store them then, only metadata required to re-generate them via a KDF and master password/key).
@walterbleach I’d suggest writing the PM on Linux (or your OS of choice) first and then porting the sensitive parts to your μC of choice. For crypto library use something portable, like mbedtls or wolfssl/wolfcrypt (don’t be scared of the SSL/TLS in their names, they are mostly just crypto libraries). For storage first just use regular files abstracted away, and then replace that abstraction with your SD card access once you port to μC.
Regarding checksumming/replication across SD cards, for simply detecting corruption, you can safely use per-block checksums. There are also nice polynomial-based solutions that e.g. require having k out of n shares to recover a secret, and detecting corruption with k+1 shares. E.g. if you have 4 cards with 2 duplicates per card (n=8) and set k=3, even if you lose 2-out-of-4 cards, and 1 of the duplicates on one of the remaining cards is damaged, you can still recover the secret (up to 2/3 “blocks” size btw, depending on security level), BUT having only 2 shares (e.g. a single card) makes it impossible to ever recover the secret.
2 Likes
This is the sort of thing that Qubes OS solves. Security via hyper-compartmentalization.
File systems are hard. Crypto is hard. This stuff really isn’t for the faint of heart.
Keep in mind that these areas have the cream-of-the-crop folks working on them, and taking time on the order of decades to develop and put into production. In recent memory: bcachefs and post-quantum cryptography algorithms.
1 Like
Reminds me of Linux disk encryption, albeit a different arrangement but the same handy feature:
The master key is checksummed, so a correct master key can be detected.
– https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
That’s true, but only after hundreds of thousands of rounds of PBKDF2 - which is the expensive bit, and even then it can collide.
Hehe, depends how old your install is. Used to be 10 iterations.
It isn’t broken at 10, but it did convey a slight feeling of uneasiness.