Wind_Mask,technically me.

Reflections on Secret (2): Local


Let's start with a simple scenario, which is to consider our local activities first. This is a type of activity that is not taken seriously (at least for individuals), because individuals rarely face attacks locally unless they are in a dangerous situation (in which case we need a more consistent system design, which naturally exists locally).


What individuals should be more concerned about now is backup and availability - local data failure is common. In this regard, cloud backup and synchronization services are applied. I use fewer commonly used services because I don't use the directory synchronized by OneDrive much; Google Drive is restricted by the GFW, so I have to turn to domestic applications.
I don't use file synchronization services much (but now all software has their own cloud synchronization, and code has Git repositories). For file backup, domestic services are actually available. But here we are talking about small file backup, because that is unlikely to be a secret (of course, if we really have large files that are secrets, that would be a problem, maybe physical backup (for the sake of secrecy, there should even be independent storage - referring to a safe deposit box for hard drives? Of course, there is also full-disk encryption). (Of course, there are paid cloud encryption backup services, but they are not as good as free ones for general needs, and for extreme security needs - paying may even increase the attack surface).
What are small file backups used for? There are not many answers. Personally, I use them for e-books, small program tools (these things are not easy to find), and most importantly, key backups.
Yes, key backups. Whether it's a password library for automatic filling or PGP keys or SSH keys. But remember, there should be no plaintext in secret files in the cloud! Ensure encrypted upload, local processing, and synchronized processing. This involves a dynamic file encryption:


This is indeed a problem.
If you are not doing backups, not archiving for long-term storage, not encrypting files to securely send them to others, and not mounting/unmounting virtual drives for work purposes, then this encryption is not for long-term backups - it may be frequently accessed, not offline, not relying more or less on public key cryptography, not a virtual drive but a file (although I think VeraCrypt is available for this).

So this is indeed a problem, especially for the main PGP key, there will be no plaintext backup. This requires accessibility - although in reality, we use USB drives (and they are encrypted) to solve this, we still need to consider multiple approaches - if the USB drive is lost, we also need to ensure the security and accessibility of the keys, right?

First of all, keys generally have encryption themselves, so they can be directly exposed - but no one would do that. Sign them (to prevent accidental modifications to the keys) and integrate them, the simplest way is undoubtedly an encrypted compressed package. Integrity can be guaranteed by signatures (and encryption tools themselves face questions: how to ensure that the software itself is not a modified malicious version? - this will lead to some of my considerations later, indicating that this issue is indeed unsolvable under strict conditions).

A recommended tool is age, which some people believe achieves the purpose. But gentlemen, this just turns one key problem into two. In general, the question is - what exactly does local encryption defend against?

This is indeed a mystery. If the offline environment is indeed dangerous, then the analysis of the specific situation must consider the threats from physical sources. If it is only for a potential physical threat, then the strength of local defense is not in encryption (because it is physical) - that is for the cloud.

The weakness lies in the local device itself.

This is where the key issue of local security comes in:

Device Security#

Open-source hardware? Unless there is a complete process that can be fully controlled, it is not very useful. Of course, there is no need to assume such extremes. As long as it is not so extreme, normal devices are already sufficient (but not including phones that have not been fully considered).

Operating System#

Linux distributions (such as Debian), or extreme distributions like Qubes (I have to say, I haven't used it) are already more than enough. For scenarios with frequent movement, Tails is one of the choices, but the security of mobile scenario devices depends on occasional anonymity (after all, you can't guarantee that devices everywhere are secure), and it may not be very useful for being tracked. In other words, your own device is ultimately necessary, but if you want to use a phone for portability, you need to seriously consider the risks. iPhones always seem to be good, I don't know why, maybe Apple's market value deserves this trust. But Android actually has a lot of room for operation, this is a technical issue.

Windows is highly suspicious, but it doesn't really matter unless it is extreme, and there is usually more than just that - admittedly, this is a kind of luck, but controlling connections may be more important than system vulnerabilities, and the same goes for Mac.

This is where everyday security lies. Using virtual machines and the aforementioned systems is certainly good, but it is not very practical for everyday use (of course, it seems that everyday use doesn't need any protection, but what about the gray area in between?). Without affecting daily life, we should take more radical measures as much as possible. The scale here is certainly personal, but specific designs can be decoupled and provide considerable security when correctly assembled (of course, the evaluation of products is controversial, but any replaceable ones can be replaced by oneself).

If you use Windows, you need to consider keeping up with security updates and checks. I won't talk much about the details of security details (those recommendations that can be seen everywhere don't need to be repeated by me). One seemingly unrelated issue is file organization - please ensure that you are aware of what you have, letting tools handle it doesn't mean forgetting.


Open-source + portable software is great and almost avoids all kinds of problems. Currently, for me, I use portable open-source products for compression, proxy, text editor, Markdown editor, player, and image viewer/editor. In short, avoiding unnecessary proprietary software is always good, after all, compromises have been made too much now.

For software dedicated to security, I hope they understand (and implement) not to put real-time data into the hard drive - but this is not certain. Virtual machines and external disks may help with this, but it needs to be further investigated.


Considering local metadata in advance is important. Of course, you can consider it after connecting, but why not consider it in advance? Actually, I would recommend using plain text to avoid metadata disasters, after all, metadata issues when online are troublesome enough. But there are always other formats...

Office documents are dangerously frightening, and metadata should be cleared; PDF format metadata may also have problems. All of these need to be considered, of course, you can even use them for camouflage...


Local issues are endless - in extremely dangerous physical situations, all local computing facilities are best disposable and storage should be mobile. But for ordinary people,

Individuals rarely face attacks locally.

Local backups are mainly to prevent loss, but in this regard, they need to be combined with cloud backups, and the security levels of the two are also different.

...To be continued...

Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.