seeds.json on sdcard padded to avoid abandoned bytes

[jdlcdl]

Related to issue #299

Description

On an sdcard's FAT filesystem, when a file grows into additional sectors and is later trimmed, bytes will remain abandoned in previously used sectors. For seeds.json, which holds encrypted mnemonics, this is less than ideal because it could result in ciphertext with weak encryption keys remaining on the sdcard media yet hidden from plain sight for the user.

This pr alters krux.encryption.MnemonicStorage's .store_encrypted() and .del_mnemonic methods so that seeds.json gets padded with spaces -- to its original size. That is, it will never be trimmed. Care elsewhere should be taken so that os.remove() is not used for seeds.json, as it abandons all bytes.

CAUTION: This pr may create a false-sense-of-security in the event that it fails to work, and it certainly can do NOTHING to save the user from themself if they choose to edit/remove seeds.json from the microsd outside of krux.

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[odudex]

Another neat improvement! Of course documentation should contain detailed instructions and the warnings you raised, but with this commit do you think it is still necessary to add a message when removing encrypted mnemonics from SD card?

[jdlcdl]

I still like the idea of a message. The user should not be misled into believing that we've mastered the complex layer that is the filesystem, and that it is no longer capable of hiding data storage (which is it's primary job) from the level that krux works with file storage.

A careful user, hopefully via the docs, should know the difference between a verifiably scrubbed sdcard and our "best efforts to trick the filesystem into destructive management.". I almost think that this pr is "treachery"... however it seems to be working so far (when files shrink, as well as when they get fragmented into non-contiguous sectors).

[jdlcdl]

As devils advocate (far from evil... leaning in the opposite direction from this pr, towards "ultra conservative"),

I think a very strong argument can be made for:

We should not imply any functionality of "deleting" a stored encrypted mnemonic. Not on sd, and not on flash. That way, the user has no expectation that it can be removed securely via simple management, and they'll be motivated to find 'wipe spiffs' and/or a verifiably destructive sdcard format tool.

[jdlcdl]

from draft to ready... but before the next release...

WHICH FILES MUST WE BE CAREFUL WITH ???... is it just seeds.json, or is it encrypted seedqr's saved to sdcard too? and what else?