Header Wallpaper

🛡️ An extremely powerful tool for file security 🔒

Avatarչ∂αяквℓσω5 min to read

Hello everyone, dear Zevist family!

(I preferred to include this project in the Art section since it is an art form, even software is an artistic expression of human ingenuity and therefore a type of art!)

I want to share a personal project I've been working on independently: BastetCipher, a tool that does two distinct but integrated things — it deterministically strengthens passwords and manages encrypted file archives with an in-memory viewer that never writes anything to disk.

This isn't a commercial project, there's no data collection, no telemetry. It's a single HTML file that runs entirely offline in the browser (In fact, it is recommended to do everything offline without an internet connection; this is the best practice for HoS subscribers.).

WHAT IT ACTUALLY DOES

1. Deterministic cipher generator

You enter a secret phrase + a PIM (a number that acts as a second factor) and, optionally, an "amplifier" (0-9999) that extends the length of the output. The system runs a 9-step pipeline — SHA-256/384/512, a proprietary 4-stage transformation, PBKDF2-HMAC-SHA512 with iteration counts ranging from 50,000 to 600,000 depending on the PIM — and always produces the exact same output for the same input. Change even a single digit of the PIM and you get a completely different cipher.

It's designed for people who want extremely strong, reproducible passwords without having to store them anywhere. You remember phrase + PIM, and you regenerate the same password every time.

2. Sacred Vault — encrypted file archive

You can pack up to 1,024 files into a .bca archive (a proprietary binary format), encrypted with AES-256-GCM and then AES-256-CBC in cascade, with the key derived via PBKDF2-HMAC-SHA512 at 200,000 iterations. The archive can be extracted as a standard .zip, or opened in memory: files can be browsed and viewed inside a sandboxed iframe, without ever writing the decrypted content to disk.

THE HONEST COMPARISON WITH 7-ZIP AND VERACRYPT:

- 7-Zip (encrypted): when you open a file inside it with an external program, that file is often decompressed into a temporary system folder before being opened. It's a plaintext file on disk, even if only briefly.

- VeraCrypt: mounts an encrypted volume as an actual filesystem. Excellent security for the volume itself, but as soon as you open a file inside it with an external app (PDF reader, video player...), that file passes through the entire operating system stack — application caches, indexing, thumbnails, antivirus scanning.

- BastetCipher: the built-in viewer keeps everything inside a single iframe on the same page — no external program involved, no explicit disk writes. This removes an entire category of risk compared to the "mount volume → open with external app" workflow.

That said, this is NOT "impossible" in an absolute sense — the operating system can still page RAM to disk (swap) under memory pressure, regardless of what the browser does. That's why the app includes an in-app operational security guide on how to disable hibernation/swap, or alternatively encrypt the entire disk. This is a real limitation of the browser environment, not a hidden flaw — and I'd rather state it clearly than sell it to you as magic.

WHY IT'S MORE CONVENIENT THAN USING VERACRYPT OR 7-ZIP FROM THE COMMAND LINE:

- Zero installation: a single HTML file, just open it, even from a USB drive.

- Zero dependencies: no external libraries, no network requests (the CSP explicitly blocks every outbound connection).

- An interface anyone can understand, even without cryptography background: you don't need to know what a mounted volume or a LUKS header is — you just drag your files in.

- Full portability: the same file works identically on any system with a modern browser.

- Multi OS: Windows/Linux/MacOS/Solaris/BSD etc..

TECHNICAL TRANSPARENCY (for those who want to verify it themselves)

The project is open source, MIT licensed. You can read every single line:

The repo's README documents the entire cryptographic pipeline step by step, including the .bca binary format, so anyone with the skills can independently verify what the code does instead of just taking my word for it.

AN HONEST DISCLOSURE, NOT A BOILERPLATE DISCLAIMER:

Some design choices in this project are conscious trade-offs, not hidden flaws:

- The salt is deterministic (not random) in order to guarantee password reproducibility — this means the entire security burden falls on the quality of the chosen phrase + PIM, not on the algorithm itself.

- The double-layer encryption (GCM + CBC) is defense-in-depth, not a mathematical security multiplier.

Feedback, technical criticism, and bug reports are all welcome — that's how a project like this improves.

Oh, and one last note:

Have you noticed how incredibly lightweight the file is? And that's the beauty of using an interpreted language. 😎

🐈‍⬛ Honor to the Goddess Bastet! ⚕️

Attachments

0
#1

Here's a video example of how it works and how it should be used. I obviously used a test password. It can be used, for example, to store rituals purchased in PDF, video, audio, txt format, etc.

1
Avatar
ZammelH
This is the targeted reply.

Wonderful project! brother! Can the Gods,bless you!

#2

Thank you for your project, Brother.

Apollo's Astrology: https://www.astroapollo.org

1
Avatar
չ∂αяквℓσω

I'm really glad you liked the tool, as soon as possible I'll try to publish another extremely useful tool like this one!

#3

This is really cool! Will certainly be of good use for us.. Nice job and thank you.

Glorious Eternal Zevist Victory!

1
Avatar
չ∂αяквℓσω

Thanks for your feedback, I'll be releasing a very important update soon!

#4

Really useful and much needed. Thank you for making this brother!

1
Avatar
չ∂αяквℓσω

Thank you so much for your kind words! 🥰

#5

🆕 Extremely important update! 🔃

Repository link:

After a long time of work, I've finally completed the project. BastetCypher is no longer just a simple web app; a desktop version has also been created, compatible with Windows, Linux, and MacOS.

Previously, the browser could be attacked by malicious extensions, etc., but the desktop version is highly resistant to code injection attacks or other types of attacks. The interface has been completely redesigned and a button has been added to prevent traces from being saved on the clipboard. The first time you copy, but once the .bca archive has been created, there's no need to copy to the clipboard. Simply press the button that switches the generated key and automatically places it in the form where the secret archive is decrypted. It also contains commands to try not to be saved in swap. It's always recommended to disable swap.

From now on, there will no longer be any need to install Veracrypt, 7zip, or follow tutorials to try to encrypt rituals purchased with less secure and more difficult to configure programs. Soon, we will be able to enjoy our own official ritual encryption and archiving software.

I am extremely happy with this milestone. I thank everyone who supported me during the development of this project, and may the Gods bless you!

0
#6

You did a great job. Thank you so much, brother!🙏

"I am ever present to help all who trust in me and call upon me in time of need."- Al-Jilwah
About Zeus: Father Zeus
Account X: @Asphodelium_
Zeus is God, believe in Him

1
Avatar
չ∂αяквℓσω

Thanks for your feedback, and I also recommend scrolling up and checking out my new desktop version, which I finished developing yesterday! 😊

#7

Great project. Thanks for taking the time to put this together.

Let us uphold the Temple of Zeus as the bastion of ascent!

0
#8

⚱️ Massive update to the graphical interface (GUI) 🔺

After weeks of work, the definitive update should finally be here. All tests have been run, across the various operating systems too, and the executables are ready for use — the app is complete!
I decided to fully modernize the GUI, making it unique and custom, much nicer than the previous one. It used to run on Tkinter, now it runs on PySide6, which is far more modern, fast, and stable!
I also carried out obsessive checks for stability and performance, added advanced garbage collection logic to prevent memory leaks, and ran checks to prevent buffer overflows. On top of that, I added code to protect the app against recording devices (at least on Windows it works), even though this feature isn't strictly necessary — it's just an extra layer of help, since nothing can stop someone from recording the screen with a phone. Final security always comes down to the person sitting between the desk and the computer.
Now that the app is finished, I also want to list the main advantages ToZ could get out of it!

🥇 [Main advantage] – Encrypted data is opened directly in RAM (unlike Axcrypt/Veracrypt/7z/Peazip/WinRAR, etc.):

Basically, if I open a vault encrypted with Veracrypt, part of the decrypted data ends up in the system cache, and that cache is never overwritten — and on SSDs it's even harder to remove traces because of wear leveling. So an attacker could use recovery software like Recuva or EaseUS Data Recovery (on Windows) or PhotoRec (on Linux) to recover critical data that was supposed to be encrypted, effectively undoing all the encryption. With my app, on the other hand, decrypted data only ever exists in RAM and is explicitly overwritten as soon as the vault is closed or the app is terminated, without ever touching temporary files on disk (now let's move to the next advantage).

💾 Reduced exposure to the swap system (if RAM runs out, the data that was supposed to stay in RAM gets written to the hard drive in plain form).

The swap memory system is an emergency mechanism: when a computer runs out of volatile memory (RAM), it uses non-volatile memory (the hard drive [HDD/SSD]) as temporary storage for information. The problem is that to do this, the operating system can write that data to disk without encrypting it — and again, going back to the earlier example, using data recovery software and reading through disk sectors, it's possible to recover data we thought was safe. In the app, I've put in place the infrastructure for memory locking (mlock/VirtualLock) and for explicitly wiping sensitive buffers right after use, in order to reduce the time window during which critical data stays exposed in RAM. That said, this is a mitigation, not an absolute guarantee, since the operating system ultimately decides on its own how to manage memory under pressure. Because of this, it's still good practice to manually disable swap and hibernation on systems where particularly sensitive data is stored ⚠️ (hibernation is even worse in this respect: no program can prevent itself from ending up in the hibernation image if the user enables hibernation).

🎬🛡 Removes the need for external software (for example, you don't need Okular to read PDFs, or VLC for audio/video, etc.).

That's right — with this system, the app already integrates video players, image viewers, PDF readers, audio players, and text readers. There's nothing to install, and the app itself doesn't even need installing — it's portable and compatible with all three operating systems (Windows/macOS/Linux) 🪟🍎🐧. It's a sophisticated standalone tool, purpose-built to safeguard the sacred rituals within the Hall of Osiris 𓂀. (I also implemented a clever workaround here: since in-RAM video playback is only possible on Linux, on Mac and Windows the videos that get played are cached and then immediately overwritten in multiple passes, automatically cycling back through that sector to prevent recovery. It also attempts to send a TRIM-like command to SSDs, instructing them to rewrite that sector multiple times.)

✨ Ease of use and accessibility for less experienced users!

The app is ready to go exactly as it is — there's no need to configure any external software. It has a beautiful GUI (fully redesigned and animated) and includes an additional key-generation system with PIM support, a system for creating protected archives (.bca), and a system for extracting them, in case for any emergency or reason you need to recover a ritual and decrypt it in order to move it or change its password (recommended to do this at least on an encrypted system, or on a live USB distro with no persistence, if we really want to follow best practices).

Conclusions:
First of all, I'd like to thank everyone who supported me during the software's development, especially @Daemontech [NG] and @Chandra [TG]
But also all of you on the forum, thanks to our wonderful family. We're growing steadily, and I'm proud of that. I'm confident this software will be of great help on the long journey of Zevism, and that it will ensure the safe storage of your rituals.
I hope that one day I can witness a world completely different from what it is now, with divine influence on earth, and where things will be vastly different from how they are now, in a very positive way.
0
#9

I’m writing this to announce a small software update and various annoying bug fixes; here is the changelog:

  • - Changed the background—it looks even better now!

  • - Added full protection to prevent data from ending up in the swap partition (on Linux, this might sometimes require increasing limits); if you are prompted to run as root to modify swap settings, you can increase user limits using the command sudo nano /etc/security/limits.conf, scrolling to the very bottom, and adding:

<username> hard memlock unlimited
<username> soft memlock unlimited
(Fortunately, many Linux distros don't require this, so it depends on the specific distribution.)

  • Added a hidden feature: clicking the sun icon at the top opens a security suite that lets you test the app's security effectiveness (intended for power users/developers; I even gave it an "engineer-style" UI).

  • Added a much more secure key derivation system: Argon2id. However, I’ve kept PBKDF2 for backward compatibility. NOTE: Argon2id is now the default; if you have existing archives, you must use PBKDF2. If you want to switch to the new algorithm, simply decrypt the archive, save the files externally, and recreate the archive using Argon2id (which is recommended for better security).

  • Fixed an annoying visual bug in the Windows layout and widened the layout for the "unlocked content" section. - Added the option to delete files from the archive and add files to it, just like a standard .zip file.

  • Fixed some minor memory leaks.

  • Greatly expanded file extension compatibility; it now supports .m4a, .wma, .wmv, etc.

  • Added a simple visual emulator for .html file previews (protected against XSS, of course).

  • Fixed an annoying bug that occurred when the audio/video player went past 85% of the playback duration.

  • Updated the README.md in the official repository.

  • Changed the file format to .bstarc; while it still supports the old .bca format, updating is recommended (I made this change because the previous extension was already in use elsewhere, and I wanted to avoid confusing users).

  • Added an anti-exploit system to strengthen the sandbox; it filters out strange characters, PDF macros, image or video anomalies, and other irregularities. If a malicious user attempts to send a file to another user running the app, they will be unable to exploit it to execute arbitrary code or perform other dangerous actions (user security is a top priority for me, and I work hard every day to ensure it).
    I will conclude by noting that the encryption algorithms used are standard ones available online—specifically, the most secure options; I did not create a custom encryption algorithm, as that would have been risky and created a massive attack surface. As a fifth-year university student specializing in cybersecurity, I conducted numerous personal tests—both in isolation and involving multiple AI agents—and the results were exactly as I had hoped: it is absolutely impossible to open the archive without knowing the password. This was precisely the outcome I sought; even if a bug were to be discovered in my app in the future, the mathematics of encryption ensures that, without the key, recovering the files inside remains impossible. I would also like to take this opportunity to thank the High Priest for his helpfulness; I purchased my first ritual and performed it for the first time, and it is now safely stored in my app's encrypted archive, far from prying eyes!

I almost forgot: if you wish, you can also use this program in conjunction with VeraCrypt. You could create an initial virtual archive protected by a password—containing the program itself and the .bstarc/.bca file—and use a separate password to access the section containing purchased rituals. This offers colossal protection—bordering on "paranoid," perhaps—but in my personal opinion, such best practices are fully justified, given that we are safeguarding the most sacred rituals to have ever existed on our planet.

1
Avatar
չ∂αяквℓσω

I also forgot to include one final note.

Expert users with access to the source code can create their own custom key derivation system—a system known as "PEPPER." By default, it is set to this string:

PEPPER = "Bastet_Secret_Temple_Key_\U00013060"

You can use a word of your own choosing—including Unicode characters if you wish. The same applies to the amplification algorithm; here are the strings to modify:

+ ".,\u00A7Sacrum\U000104CF"

+ "Amplificatorsky\U00013060\U0001F4AB,."

These are the default "PEPPER" values ​​found in both the source code and the compiled executables. Users familiar with Python can simply install the dependencies from requirements.txt and PyInstaller, modify the PEPPER values ​​as they see fit, and recompile the app using pyinstaller --onefile appname.py.

A brief explanation of the PEPPER's purpose:

It serves to make the generated deterministic password even more unique to the user—and thus harder to crack. To illustrate with a real-world scenario: using the app with a custom PEPPER is like using a custom USB security key. The app functions like an onion with multiple layers of security; we can visualize it this way: "PIM = OTP Code (2FA)" | "PEPPER = USB Secure Key". Once we have our modified binary—a unique executable not found elsewhere on the network—a hacker attempting to compromise your app would have to resort to a brute-force attack. While this is nearly impossible with a strong password (especially given the key generation algorithms involved—which are already slowed down thousands of times by PBKDF2, and even more so by the now-default Argon2id), is there still a remote chance of cracking the key? Honestly, the security is already enterprise-grade; I don't believe anyone could crack the key unless the password was something like "Cat1234."

However, let's imagine a scenario where someone actually used such a weak password (which, to be clear, should never happen, especially when storing these "rituals"). This is where the "pepper"—acting as a final layer of defense—provides a massive advantage. Even if the hacker correctly guesses the password, the PIM, and the amplification number, the victim has recompiled the app with their own custom pepper. (This pepper can be an extremely long string of special characters—in fact, the longer and more complex, the better; the same applies to the amplification pepper, creating a double sub-layer of defense within the main layer—like a Matryoshka doll effect). The hacker would never be able to generate the valid key needed to decrypt the rituals, as doing so requires the specific, unique executable that generates that key. Of course, as a last resort, the hacker could try to steal that executable using Trojans or similar malware, but that is extremely difficult; most modern antivirus programs detect the vast majority of malicious software in circulation. WARNING: You must not rely solely on the "pepper"; to safeguard these rituals, it is mandatory to ALWAYS follow security best practices:

  • - Use an extremely long password (minimum 8 characters—fortunately, a minimum password length is now the default); I would recommend 16 or even 32 characters, including uppercase and lowercase letters, numbers, and special symbols (naturally, train your mind to remember it; do not write it down anywhere—apply a zero-trust policy here).

  • - Do not use the same password you use for other services; this must be a UNIQUE password used ONLY for the sacred rituals and nothing else.

  • - Use a very long and complex PIN—not your date of birth. You need to train yourself to remember this, too; to train my memory, I wrote the password and PIN on a piece of paper, read it daily (like learning a poem), and then burned it in my incense burner (you should only do this if you are certain no one else will read the paper).

  • - Use an uncommon amplification number; I reached the thousands range. Avoid numbers like 6666 or 9999, as they are too common.

  • - Change the default "PEPPER" and the amplification "PEPPER" (this is intended for developers, but also recommended for average users if they have some time to study how the app works).

  • - If the pepper is changed, keep the app binaries secure; if uploading to the cloud, encrypt the binaries with a separate password to ensure no one else can read them.
    If you follow all the best practices to the letter, you can be certain that the password will not be cracked within a reasonable timeframe—even if every computer in the world were used. To wrap up, here is a summary and various calculations regarding password crackability!

↓↓↓

Attachments