-
@ mleku
2025-05-10 21:07:43
been idling outside of fiat mining programming with Kingdom Two Crowns the last week, putting my work on bunk on hold, but this evening i'm getting back into it again
just trying to get the architecture right before i move to the actual bunker part of it, especially the cryptography... learning how to use memguard to protect the secrets, and how to properly encrypt the keys for storage in the database
i'm not using a "conventional" encryption scheme... it uses argon2 with fairly decent recommended memory/process/thread settings, but it's just 32 bytes, i'm just XORing the salted password with the secret, this is pretty much anyway what any block cypher does to a 32 byte byte string anyway, so i don't see why to complicate this by using AES or chacha... you can't access the key without the right password, and this operation is reversible in a simpler way because it doesn't need a HMAC, it's not a long message, idk, i just prefer simple and i know this is secure, the salt doesn't give you anything without the correct password
and then after it's decrypted it goes straight into the enclave and it wipes all the intermediate data from memory of the actual secret. hmm, probably also need to zap the password string as well, i have some code in there somewhere already that does this to the nsec input, should also do that to the password, once it's entered, it decrypts the secrets and the password isn't needed after that, so it definitely should be disposed of so it isn't also vulnerable to being sniffed at by malicious processes.
i'm not sure why i'm going so slow with it, but on the other hand, i do need to warm up a bit with this stuff because i've been pointing out the security model for my fiatmine job, one of the endpoints that could be abused to harass users is vulnerable unless the front end uses asymmetric cryptography to prevent unauthorized messages being sent, and i'll have to come to grips with some new unfamiliar cryptosystem used by the Move language family of blockchains. it will be most likely some kind of ed25519 thing with blake2 hashes probably, all the hipsters love that combo
anyway, once all the database storage is encrypted correctly and i've handled all the memory cleaning i can move to the last phase of the app, integrating the refactored bunker library i adapted from go-nostr, opening the connection to the relay to subscribe to signing requests and returning the data, and making a widget that displays the logs, and writing the log to the database so it can be searched... not gonna make it encrypted though, it's just gonna be event json and timestamps, i think it's good anyway to have the signer store a record of these, in case for whatever reason the user needs to rebroadcast them, it will be simple to make that possible in a future feature.