[Enhancement] Hidden .seeds.json file for improved obfuscation/deniability/privacy/security

[nervetrip]

Summary

Add fallback support to look for .seeds.json at the root if seeds.json doesn't exist.

Reasoning

• This feature would allow users to obfuscate the purpose of an SD card.
• Casual examinations wouldn't immediately see the seeds.json file at the root.
• Privacy and deniability would be improved.
• Requires minimal changes and additions to the codebase , but privacy and security is greatly improved.

Basic Implementation

• Attempt to load seeds.json just like normal
• If file is missing, attempt to load .seeds.json (hidden file)

Alternative Implementation

• Attempt to load seeds.json just like normal
• Attempt to load .seeds.json
• Combine seeds found in both files for user to pick from

Pros and cons to alternative implementation:

• Less chance of user error - showing all seeds on the SD card reduces the chance that a user will lose or misplace their seeds. If they have an important seed in the hidden file, but Krux isn't showing it because it only shows the seeds in the non-hidden file, a user could get confused and not understand why their seed "disappeared".
• Improved privacy/security - only showing seeds in the non-hidden file and concealing the seeds in the hidden file might protect more important seeds from being seen by someone wanting to confiscate assets
• additional user interaction - loading from multiple seed files would require entering multiple decryption keys

Perhaps both functionalities could be supported via a configuration option to enable loading from all seed files or not.

Use Case

I keep my encrypted seed phrase on an SD card that also contains GoPro videos. The folder structure matches GoPro format and use. I don't keep this SD card with the Krux device. I also store a bunch of other files in the root so that the seeds.json file is less obvious and doesn't immediately jump out when examining the files on the SD card.

All these extra files are not typical for GoPro use. This alone could lead an examiner to inspect the media more closely and not immediately assume it is just GoPro videos. It would be best if the SD card looked exactly like GoPro storage. Upon casual examination, it would only show files that GoPro includes at the root with no extra files. The additional hidden file: .seeds.json would only be seen if the examiner took the time to add extra steps to look for hidden files.

[qlrd]

Interesting concept.

IMO, while it's better to separate SDCards for different purposes, it's a balance between with what's is possible for some users and security.

[tadeubas]

On "alternative implementation": If we "combine seeds found in both files for user to pick from", what about creating new encrypted ones, the user would choose the file to save too?

On "loading from multiple seed files would require entering multiple decryption keys": Is false, the encryption key is related to the encrypted mnemonic not a file that supports hundreds of encrypted mnemonics.

We could think about any filename (ex: .nothing.txt), but if an authority is searching the contents of an SD card I think the computer will be already showing hidden files. Also you can always transform the file to anything, an .jpg with hidden content (called steganography... there are programs for that) and then transform again in seeds.json when in a safe place. I don't see why you would carry a .seeds.json instead of a hidden seeds.json inside a .jpg, for me this doesn't make sense and is a false sensation of security.

[nervetrip]

On "alternative implementation": If we "combine seeds found in both files for user to pick from", what about creating new encrypted ones, the user would choose the file to save too?

Very good point. Honestly, the alternative implementation was intended for brainstorming. I'm not looking to increase the complexity of the UX or the codebase, so it's probably not worth pursuing this.

On "loading from multiple seed files would require entering multiple decryption keys": Is false, the encryption key is related to the encrypted mnemonic not a file that supports hundreds of encrypted mnemonics.

You are right! Disregard that thought.

We could think about any filename (ex: .nothing.txt), but if an authority is searching the contents of an SD card I think the computer will be already showing hidden files. Also you can always transform the file to anything, an .jpg with hidden content (called steganography... there are programs for that) and then transform again in seeds.json when in a safe place. I don't see why you would carry a .seeds.json instead of a hidden seeds.json inside a .jpg,

I completely agree. Supporting .seeds.json is simply for casual observations. I am already using steganography in the way you suggest. But it is a massive PITA to work with, so I tend to only do that when risk is highest.

for me this doesn't make sense and is a false sensation of security.

Maybe so. But I see it as simple low-hanging fruit that would add additional security in certain situations with very little development effort or codebase bloat. It wouldn't deter a determined authority, but someone who has no reason to suspect you might perform a casual check and usher you on your way.

[nervetrip]

IMO, while it's better to separate SDCards for different purposes, it's a balance between with what's is possible for some users and security.

The purpose of this SDCard is exclusively to use with Krux. The GoPro content on it is simply decoy data, to obfuscate the real purpose of the card. I wouldn't actually use the card in my GoPro.