Avikal did not begin as an archival security tool.

It began with a question: can data be hidden inside chess?

Today, RookDuel Avikal is an open-source archival security system built around the .avk format. It is designed for long-term private storage, layered access control and future-governed release workflows. The project combines conventional cryptographic protection with chess-rooted metadata transport, a Devanagari keyphrase path, optional post-quantum protection and TimeCapsule-based delayed access.

But the journey did not start from cryptography or archive software. It started from curiosity.

How the idea began

The idea started in 2024, when I became deeply interested in steganography — the technique of hiding data inside another medium. Since chess has been a major part of my life, one question naturally came to my mind: can data be hidden inside chess?

That question became the starting point of Avikal.

At first, my focus was not on building a secure archive system. I was mainly exploring chess steganography and trying to understand how much data could be hidden inside chess games, moves, notation and variations. I worked on ideas such as recursive variations in chess steganography, where chess variations could be used to represent more hidden information.

For some time, this looked like a very interesting direction. But while researching and testing the idea, I reached a practical and mathematical limitation. There was only so much data that could be meaningfully hidden through that method. Beyond a point, the structure became difficult, inefficient and not practical for the kind of system I wanted to build.

That was one of the first major walls in the project.

I did not want to give up on the idea completely, because the connection between chess and hidden data still felt powerful. So instead of forcing chess steganography to do everything, I continued researching how files, archives and secure containers are normally created.

From ZIP files to Avikal

During this time, I started studying how ZIP files are built and shipped. That changed the direction of the project.

A normal archive file is basically a container. It takes one or more files and stores them together inside a single package. A ZIP file can hold documents, images, folders or other files in one place. It can also compress them so they take less space and become easier to share.

This idea is everywhere.

Many people think a .docx file is only a Word document, but modern Office files also use ZIP-based packaging. If someone opens a .docx file as a ZIP package, they can find internal files and folders that describe the document, its content, formatting and relationships.

That idea became important for me.

I realised that instead of trying to hide large amounts of data only inside chess, I could build my own archival tool where the archive itself becomes a structured container. But unlike a normal ZIP-style package, Avikal would not just package files together. It would have its own identity, its own metadata structure and its own access model.

That is when Avikal slowly started becoming a real archival security project.

What Avikal is

RookDuel Avikal is best understood as a composed archival security system, not just a simple encrypted file wrapper.

In simple words, Avikal is designed to seal files into a protected archive while keeping the archive structure clear, layered and future-aware. It separates the larger encrypted file data from the smaller control information that explains how the archive should be opened, verified or governed.

In the current implementation, an Avikal archive contains two main parts:

• keychain.pgn
• payload.enc

The payload.enc file carries the encrypted archive payload. This is where the protected file data is stored.

The keychain.pgn file carries protected archive metadata using chess-rooted PGN transport. In simple terms, this means Avikal uses chess notation as a structured carrier for archive control information, while the actual security still comes from established cryptographic methods.

So the basic idea is simple:

A normal archive stores files together.

A protected archive encrypts files.

Avikal goes further by separating the archive into a data plane and a control plane.

The data plane is the encrypted payload.

The control plane is the metadata layer, and in Avikal that layer is represented through chess-rooted PGN.

How Avikal works in simple terms

Avikal uses established cryptographic components for protection. According to the current whitepaper, Avikal uses AES-256-GCM for authenticated payload protection, Argon2id for password and keyphrase hardening, HKDF for key separation, and an OpenSSL 3.5+ provider-backed path for optional post-quantum operation.

In simple terms:

• AES-256-GCM protects the file data and helps detect tampering.
• Argon2id makes passwords and keyphrases harder to attack through guessing.
• HKDF helps separate keys so that one key is not reused for too many purposes.
• The optional post-quantum path exists for users who want an additional future-aware protection route.

Avikal is not trying to invent new cryptographic primitives. Its contribution is in how it brings multiple parts together into one archive architecture: file protection, metadata transport, keyphrase access, future release and optional post-quantum assistance.

The chess layer

The chess layer is the most distinctive part of Avikal, but it is also the easiest to misunderstand.

Avikal does not use chess as a replacement for encryption. It uses chess as a metadata transport and archive-identity layer.

The chess-rooted metadata system carries protected archive metadata through PGN form. The whitepaper describes this as a steganographic transport built from legal move selection, recursive PGN variation trees and authenticated preprocessing of the metadata payload.

In simpler words, Avikal can represent protected archive metadata inside chess notation in a structured way. The file can look like a chess PGN structure, while the actual protected data remains handled through cryptographic methods.

This is where my earlier research into chess steganography became part of the archive system.

The idea that began as “can data be hidden inside chess?” later became a practical metadata layer inside Avikal.

Chess is not a gimmick here, but it is also not a magic cipher. It is a structural layer that gives Avikal a unique identity while keeping the security foundation separate.

The Devanagari keyphrase path

Another important part of Avikal is its Devanagari keyphrase system.

This idea also came from something I was personally exploring.

For some time, I had been interested in cryptocurrency and crypto wallets. One thing that caught my attention was the way many wallets use recovery phrases or seed phrases. A user receives a set of words, and those words can later help recover access to the wallet.

That idea felt powerful because it made a complex security process more human-readable.

But most of these systems are heavily English-centric. That made me think: can a serious archive system support an Indian-language keyphrase path?

That question slowly became Avikal’s Devanagari keyphrase system.

In crypto wallets, a recovery phrase usually works like a human-readable backup. Instead of asking the user to remember a random-looking secret, the wallet gives a sequence of words. Those words represent underlying secret material in a structured way, often with validation so mistakes can be detected.

Avikal is not a crypto wallet, and its keyphrase system is not the same thing as a wallet recovery phrase. But the inspiration came from that idea: using words as a structured access path.

In Avikal, the Devanagari keyphrase path is treated as a real access mechanism. According to the whitepaper, it uses fixed vocabularies, checksum validation, canonical normalization and integration into the archive key-derivation process.

The current system supports:

• password-only protection,
• keyphrase-only protection,
• password and keyphrase together.

The default keyphrase path uses 21 words, and the canonical secret remains the normalized Devanagari phrase. Romanized input may help users type or select words, but the canonical form remains Devanagari.

For me, this part of Avikal was important because archival security should not always be imagined only through English-first systems.

TimeCapsule

Another idea that came during this process was the TimeCapsule feature.

I wanted Avikal to support files that could be sealed for a future time, instead of being opened immediately through a normal password flow. The idea was to make it useful for situations like personal records, institutional submissions, legal disclosures, future notes or any file that should be protected until a later release time.

In Avikal, TimeCapsule is not only a user-interface timestamp. It is part of the archive-level release model.

The whitepaper describes two current TimeCapsule provider directions:

• drand, for a public future-unlock path,
• Aavrit, for a signed authority-backed path.

The reason I focused on drand is because drand provides public, verifiable randomness. In simple terms, it is a public randomness network that releases random values over time. For a delayed-access system, this is useful because an archive can be connected to a future public release event instead of depending only on a private person manually releasing a password.

The basic idea is simple:

Before the chosen time, the required public value is not available.

After the chosen time, the value becomes publicly available and verifiable.

This makes drand useful for a public future-unlock path. It helps Avikal represent delayed access at the archive level, instead of leaving everything only to trust, memory or manual procedure.

Aavrit is different. It represents a signed authority-backed direction, where delayed access can depend on a controlled release workflow. In the current implementation, the desktop application is the principal Aavrit surface, while the CLI does not yet expose full Aavrit workflow parity.

So TimeCapsule is Avikal’s way of making delayed access part of the archive design. It is not only “hide the password until later.” It is a more structured attempt to make time-governed access part of the archive itself.

The post-quantum direction

The direction became even clearer when I came across the concept of “Harvest Now, Decrypt Later.”

This idea genuinely caught my attention and worried me.

The concern is simple but serious: encrypted data can be collected today and stored for the future. Even if attackers cannot decrypt it now, they may try to decrypt it later when quantum computers become powerful enough to break parts of today’s public-key cryptography.

For short-term data, this may not always feel urgent. But for archival data, it becomes much more serious.

Some files need to remain private for years or decades. These can include legal records, institutional documents, research files, private archives, personal records, business documents and other long-term data.

That is why the threat feels real.

It is not only about what quantum computers can do today. It is about data being collected today for a future where today’s protection may not be enough.

That was the point where I started connecting Avikal with post-quantum cryptography.

I began researching how post-quantum protection could be implemented in a practical way. The best option I found for my project direction was to work with OpenSSL-supported cryptographic methods, because OpenSSL is widely used, actively maintained and trusted in real-world security infrastructure.

Implementing this direction properly took around five months of focused work inside Avikal.

According to the current Avikal whitepaper, the optional PQC-assisted mode uses an OpenSSL provider boundary. The implemented suite includes:

• ML-KEM-1024
• X25519
• ML-DSA-87
• SLH-DSA-SHA2-256s

In simple terms, this optional path is meant to add a future-aware protection layer using post-quantum cryptographic methods. It does not mean Avikal claims to be “quantum-proof forever.” It means Avikal includes an optional design path that aligns with the growing need to prepare for quantum-era risks.

Building with AI, but not depending blindly on AI

During the development process, one of the biggest lessons I learned was that security is not only about writing code. It is about design.

The design of cryptographic modules, the source of the cryptographic methods, how keys are handled, how data is sealed, how metadata is structured, and how different parts of the system connect — all of these matter deeply. I spent a lot of my personal time studying these areas because I did not want Avikal to become just a random experimental tool with unsafe design decisions.

AI helped me during development, especially in coding, debugging and exploring implementation ideas. But one important thing I understood clearly is that AI does not automatically give the best security architecture by default. It can suggest code, but it does not always know the best design choice for a serious cryptographic system unless the developer already knows what to ask, what to reject and what to verify.

That is why I had to keep researching independently, comparing approaches, reading about industry practices and checking whether the implementation direction made sense. AI was useful as an assistant, but the responsibility of design, judgement and final implementation choices remained mine.

While designing Avikal, my goal was to follow the best practical security practices I could implement at my current stage. I wanted the project to combine established cryptographic methods, optional post-quantum protection, chess-based metadata encoding, and an Indian-language keyphrase path in a way that is transparent and open for review.

Desktop, CLI and shared core

Avikal currently exists in two operational surfaces.

The desktop application uses Electron as the application shell, a React frontend, a local FastAPI backend and the shared archive core. This is the richer interactive environment for users.

The Python CLI is distributed as the avikal command through the Python package. It provides scriptable access to the same archive engine for operations such as encode, decode, inspect, contents, validate, rekey and doctor.

The important part is that both surfaces are built around the same archive core.

This matters because many tools slowly become inconsistent between GUI and CLI versions. Avikal’s design tries to reduce that problem by keeping one shared archive engine behind both surfaces.

Rekey support

Avikal also includes rekey support for supported archives.

In simple terms, rekey means changing archive credentials without rewriting the entire encrypted payload.

The whitepaper explains that rekey works by opening the protected metadata with old credentials, recovering the wrapped payload key, re-wrapping the same payload key with new credentials, rewriting the control-plane state and keeping payload.enc unchanged.

This makes credential rotation cleaner because the system does not need to rebuild the whole encrypted payload stream in supported cases.

There are limits. Rekey currently applies only to regular rekey-capable archives. PQC archive rekey and provider TimeCapsule rekey are not currently supported.

Current status

Today, Avikal includes regular archive encode and decode, multi-file archive support, Devanagari keyphrase support, password-only, keyphrase-only and combined access paths, chess-rooted metadata transport through PGN, optional post-quantum archive logic, TimeCapsule support, rekey support for regular rekey-capable archives, a Windows-focused desktop application, a Python CLI and one shared archive core across desktop and CLI.

Avikal is currently in beta.

I do not consider it a final product yet. It is still under review and active development. There are many things pending, including fuller CLI feature availability, Linux support, macOS support, wider testing, bug fixing, better documentation and independent security review.

At present, the desktop version is mainly focused on Windows users. Even on Windows, Avikal is still being tested across different situations so that bugs, errors and practical issues can be found and improved.

What Avikal does not claim

It is important to clearly say what Avikal does not claim.

Avikal does not claim that chess itself provides encryption strength. The security of the archive comes from established cryptographic methods. Chess is used as a metadata transport and structural encoding layer, giving the archive format a unique identity inspired by the game that started the idea.

Avikal also does not claim to be unbreakable, quantum-proof forever, or a replacement for fully audited enterprise security products.

The system does not claim to solve host compromise, malware, keylogging, memory scraping on an already compromised machine, weak user-selected credentials, loss of required credentials or .avkkey, provider outages or external service failures.

I am releasing Avikal openly because I want developers, cryptography researchers, security reviewers and open-source contributors to examine it, test it, challenge it and help improve it.

Why Avikal is open-source

After nearly two years of exploration, failed directions, research, redesign and development, Avikal finally became a working open-source project.

For me, open source is important because a security-related project should be visible, reviewable and open to criticism. Avikal is still early, and it needs more review, testing and improvement. Making it public is part of that process.

This project began with a question about hiding data in chess. Over time, it became a much larger project about archival security, post-quantum protection, Indian-language keyphrases and the role of chess as a structural idea in technology. It is still early. It is still developing. But after two years of work, Avikal is now public, open-source and ready for review.

Project links

Website / White Paper: https://avikal.rookduel.tech
Source code: https://github.com/RookDuel/Avikal