Security enhance: Encoding-encrypt to Prevent trojans from stealing papers.

[Lyeebn]

Background Problem

Researchers value their papers, Security is very imortant.
For the security of my papers, I may run some software within a virtual machine (I have seen professors doing similar things), but it is too heavy.

Nowadays, many software programs exhibit trojan behavior (uploading users' private files). .tex files stored in plaintext on local hard drive are susceptible to data theft by local backdoor programs.

I have an idea

• ⓪ We knows that app's data in RAM are protect by OS, it is more safe than local disk.
• ① file saved in disk may be encode with a user custom password/token/program.
• ② Problem and solution:
  pdflatex(or xe, lua) accesss files in hdd instead of data in TeXstudio's runtime RAM.
  Solution: 【pass tex code to pdflatex via OS pipe(from ts)】 instead of local file.
  (Further problems: This solution is easy to implement for the scenario of a single encrypted file; but when papers are organised in multifiles(laoded via \include/\input), I have no idea, It's not my situlation.)

Is there a easy way to decode the file encode as above in pdflatex?
Can we define a private encoding like ascii/UTF8/GBK?

[sunderme]

There are better solutions for this.
a) OS can encrypt
b) use a container like gocryptfs, etc

The specialized software is preferable, because they special on cryptography and are way better at doing that stuff.

I would recommend looking at gocryptfs: https://github.com/rfjakob/gocryptfs

[Lyeebn]

Thanks for the suggestion, sunderme. I looked into gocryptfs, and I can see why it's a solid tool for the "data at rest" problem—encrypted files on disk, transparent decryption when mounted, good crypto. But I think there's a mismatch with the threat model I'm trying to address.

The core issue: gocryptfs doesn't discriminate between processes.

Once you mount a gocryptfs vault, the decrypted files become accessible to any process running under your user account. It doesn't matter whether it's texstudio.exe, pdflatex.exe, or some random background updater that came bundled with a PDF reader. The FUSE layer sees a file read request and serves it—it has no way to know which executable is asking-1. The kernel's access control is user-level, not process-level.

So if the threat is "local trojan scans the disk and uploads documents," gocryptfs helps only while the vault is unmounted. The moment you mount it to work on a paper, the plaintext is exposed to every process with your user privileges. That's the exact window where the trojan operates.

The usability problem is real, too.

Even if someone wanted to build a process whitelist on top of gocryptfs, they'd need to know which executables to allow. For a typical TeXstudio workflow, that's not just texstudio.exe and pdflatex.exe—it's also kpsewhich, bibtex or biber, possibly makeglossaries, synctex, and the list goes on. An average user who just wants to write a paper has no way to enumerate that set correctly. A whitelist that's wrong is either useless (too permissive) or breaks compilation (too restrictive).

What I'm actually proposing is narrower.

I'm not trying to replace a general-purpose encrypted filesystem. I'm proposing that the editor itself hold the key and control the I/O boundary:

• Files on disk are stored encrypted (custom encoding or standard AEAD).
• TeXstudio decrypts into its own process memory for editing.
• When compilation is needed, it feeds the TeX source to pdflatex through a pipe or a controlled temporary channel, rather than writing a plaintext .tex file that sits on disk for any process to grab.

This keeps the plaintext lifespan as short as possible and keeps the editor in charge of who gets to see it. It's not perfect—a kernel-level attacker with ReadProcessMemory can still get the plaintext out of TeXstudio's memory—but it raises the bar for the common case: a background process that scans files on disk.

I understand that maintaining crypto inside an editor is a maintenance burden, and I'm not asking TeXstudio to become a security product. But gocryptfs solves a different problem: protecting data at rest. It doesn't solve the problem of protecting data while you're working on it from other processes on the same machine.

Would you be open to discussing a narrower integration point—say, a pluggable I/O layer or a documented pipe-based compilation path—rather than full crypto inside TeXstudio? I'd be happy to prototype it on my side if the architecture allows.

Allow me to share my solution:

I build a local MathJax page to do some simple render, write a d/encrypt function in chrome developers snip tool, save encyrpted data in localStorage. In this physical machine I can write in pieces/summary, and assemble them in a safety visual machine.

[sunderme]

In the end, this is nothing I want to follow.
If your system is compromised, in the end nothing txs does, really makes a difference.
The solution for this is using a hardened OS.
Look at

• apparmor
• Qube OS
• Fedora Silverblue

[Lyeebn]

Thank you, I am really a atypia strange guy, haha.