A medical record created this year could still be sensitive decades from now. A government archive might remain classified long after the people who created it have left office. A company's research could remain commercially valuable long after the original project is finished. Even an ordinary family can accumulate legal documents, financial records, photographs, research and personal archives that they have no intention of making public years from now.

Today, those files can be encrypted properly.

But there is a problem that is easy to miss: the information may live longer than the cryptographic assumptions protecting it.

That is the idea at the heart of the post-quantum security problem.

It does not mean that today's encryption has already failed. It does not mean a quantum computer can currently open everyone's encrypted files. And it certainly does not mean ordinary people need to replace every security tool they use.

The problem is more subtle.

A piece of information has a useful and sensitive lifetime. A cryptographic system also has a useful security lifetime. Organizations need time to migrate from one generation of cryptography to another. If those three clocks do not line up, information can remain valuable after the protection around it has become inadequate.

That is why the post-quantum transition is beginning before a cryptographically relevant quantum computer exists.

1. The data can outlive the lock

Think about two pieces of encrypted information.

The first is a temporary login token. If it is exposed next month, its usefulness may already be gone.

The second is a confidential research archive. Its owner might still care deeply about its secrecy twenty or thirty years from now.

Both are "encrypted data." But they have completely different security requirements.

This is why post-quantum protection is not really a story about putting a futuristic lock on everything.

It is a story about how long the lock needs to remain trustworthy.

NIST has repeatedly emphasized that cryptographic migration is a long process. Its current post-quantum migration work says organizations should identify where vulnerable public-key algorithms are being used and begin replacing or updating them; under the transition direction in NIST IR 8547, quantum-vulnerable algorithms are scheduled for deprecation and eventual removal from NIST standards by 2035, with higher-risk systems moving earlier.

That timeline is important for a reason that has little to do with predicting the exact arrival date of a quantum computer.

Large organizations simply cannot change their cryptographic infrastructure overnight.

A bank may have thousands of applications. A government may have decades of legacy systems. A hospital may have archives that need to remain accessible for generations. A manufacturer may have embedded devices that cannot easily be updated.

So the relevant question is not:

"When will the first quantum computer capable of breaking today's cryptography appear?"

Nobody can answer that with precision.

The more useful question is:

"How long will our information remain sensitive, and how long will it take us to replace the cryptography protecting it?"

That is the beginning of the post-quantum problem.

2. What quantum computers actually change

Quantum computers are not simply classical computers that happen to be faster.

They use quantum-mechanical effects to process information in a fundamentally different computational model. What matters for cybersecurity is not the physics itself, but the fact that quantum algorithms can change the difficulty of certain mathematical problems on which modern cryptography depends.

And this is where one of the biggest misconceptions about post-quantum security needs to be corrected.

Quantum computers do not threaten every encryption algorithm in the same way.

Modern cryptography contains several different pieces.

The biggest future problem is therefore not "encryption" in the abstract.

It is certain mathematical foundations used by today's public-key cryptography.

Shor's algorithm

RSA and widely used elliptic-curve systems depend on mathematical problems that are extremely difficult for classical computers.

A sufficiently capable quantum computer could use Shor's algorithm to solve important versions of those problems much more efficiently.

That is why RSA and elliptic-curve cryptography are central to the post-quantum migration effort.

Grover's algorithm

Symmetric cryptography has a different problem.

Grover's algorithm provides a theoretical quadratic speedup for brute-force searching. In an extremely simplified model, searching a 256-bit key space would move from roughly (2^{256}) classical possibilities toward a quantum query complexity on the order of (2^{128}).

But that is not the same thing as saying:

"AES-256 is going to become a 128-bit cipher and therefore is basically broken."

Real quantum attacks require enormous quantum resources, error correction and practical machinery that makes the simple theoretical comparison incomplete. NIST's own guidance continues to distinguish the quantum threat to symmetric cryptography from the much more serious problem posed to current public-key systems.

So if you remember only one thing from this section, remember this:

Shor and Grover do different things.

Shor is the reason today's important public-key systems need a replacement.

Grover changes the security analysis of symmetric cryptography, but does not mean AES-256 suddenly stops being useful.

3. The uncomfortable possibility: Harvest Now, Decrypt Later

This is where the future quantum threat becomes a present-day security consideration.

Imagine an attacker intercepts encrypted information today.

They cannot read it.

So they save it.

Perhaps they save years of encrypted communications, corporate traffic, government records or other valuable information.

Nothing useful happens immediately.

Then, years later, the technology available to the attacker changes.

If sufficiently capable quantum computers become available and the captured information was protected using cryptography vulnerable to quantum attacks, some of those old encrypted records could become much more valuable.

This threat model is commonly called Harvest Now, Decrypt Later.

NIST explicitly identifies it as a reason to begin preparing before a cryptographically relevant quantum computer exists.

The important word is later.

An attacker does not need to break the encryption when the information is transmitted.

They only need to believe that the information will still be worth decrypting when their capabilities improve.

That makes long-lived information particularly interesting.

A temporary authentication token is unlikely to matter twenty years from now.

A diplomatic communication might.

A company's trade secret might.

A medical or genomic dataset might.

A classified research archive might.

A collection of private documents might.

The threat therefore depends heavily on the confidentiality lifetime of the data.

That is why the post-quantum problem cannot be reduced to a countdown clock for quantum computers.

The more important clock is often the one attached to the information itself.

4. Who actually needs to care?

It would be easy to say that everyone needs post-quantum protection.

That would also be wrong.

The need is better understood as a gradient.

Governments have the strongest reason to move early

Governments hold information whose confidentiality can last for decades: intelligence, defense information, diplomatic material, critical infrastructure information and long-lived identity records.

They also operate enormous technology estates containing legacy software, certificates, hardware and systems that cannot simply be replaced when a new algorithm becomes necessary.

That combination—long-lived secrets plus slow migration—makes governments a natural early priority.

NIST's current work is already moving beyond theoretical standards. In June 2026, it published working drafts for updating U.S. Personal Identity Verification standards to support ML-KEM and ML-DSA, including a dual-stack approach that keeps existing classical credentials while introducing post-quantum ones for incremental deployment.

That is what a real cryptographic transition looks like.

It is not one switch.

It is a coexistence period.

Large companies have the same problem at a different scale

A technology company may have source code, intellectual property, customer records, internal communications, certificates, software-signing keys, cloud infrastructure and backups.

The hardest question is often not:

"Which post-quantum algorithm should we choose?"

It is:

"Where are we using cryptography in the first place?"

A large organization may have thousands of certificates and dependencies spread across systems that were built by different teams at different times.

That is why cryptographic inventories and crypto-agility matter.

Crypto-agility means designing systems so cryptographic algorithms can be changed without rebuilding the entire architecture around them.

Healthcare, research and universities have another reason

Their information often has a long memory.

Medical records can remain sensitive for decades. Scientific research may remain commercially or academically valuable long after publication. Pharmaceutical research, genomic datasets, unpublished results and intellectual property can all have unusually long lifetimes.

The same applies to institutional archives.

A university dissertation may outlive its author. A legal record may remain relevant for generations. A government archive may become historically important long after it was created.

The data does not need to be secret forever for long-term cryptographic planning to make sense.

It simply needs to remain valuable or sensitive longer than the expected security lifetime of the cryptography protecting it.

5. But what about an ordinary person?

This is where the discussion should become much less dramatic.

Most people do not need to panic.

You do not need to manually replace every encrypted connection on your phone. You do not need to rebuild your personal digital life around post-quantum algorithms simply because quantum computers are improving.

For many everyday uses, the services and software involved will handle cryptographic migration themselves.

The more interesting question is what happens when an ordinary person has information they genuinely want protected for a very long time.

Imagine someone keeping a private archive containing:

• important legal and property documents;

• sensitive financial records;

• original research;

• intellectual property;

• confidential professional work;

• family records they do not want publicly exposed;

• long-term encrypted backups.

The question is not whether those files need encryption today.

They probably do.

The question is whether the owner cares about their confidentiality twenty or thirty years from now.

That distinction is crucial.

"I need encryption today" is not necessarily the same requirement as "I need this information to remain protected for decades."

For a short-lived piece of information, conventional modern encryption may be entirely sensible.

For information with a long confidentiality lifetime, the future cryptographic environment becomes more relevant.

That does not mean every long-lived archive automatically requires post-quantum encryption either. Security always depends on the threat model, implementation and cost of migration.

But it gives ordinary users a much more rational way to think about the issue.

Instead of asking:

"Do I need quantum protection?"

ask:

"Which information would I still be unwilling to expose decades from now?"

That is a far better question.

6. AI is making the value of data harder to ignore

Quantum computing and artificial intelligence are often mentioned together in discussions about the future of privacy.

They should not be confused.

AI does not break encryption in the way Shor's algorithm threatens public-key cryptography.

The connection is different.

AI is making it increasingly practical to analyze, classify and correlate enormous quantities of information.

A large collection of documents that was difficult for a human to examine manually can be searched, summarized, classified and connected much more efficiently with automated systems.

That increases both the usefulness of legitimate datasets and the potential value of stolen ones.

NIST's current work on AI and privacy discusses risks including re-identification, inference and increasingly sophisticated analysis of personal information. Its AI-security work also treats AI-assisted attacks and data leakage as emerging parts of the security landscape.

The result is an interesting convergence.

Quantum computing can change the assumptions behind some cryptographic mathematics.

AI can change how efficiently information can be understood and exploited.

Neither means privacy is doomed.

But both reinforce a broader idea:

The more valuable information becomes, the more seriously its long-term protection has to be treated.

7. What is actually happening today?

Post-quantum cryptography is no longer purely a research topic.

NIST finalized three major post-quantum standards in 2024:

• ML-KEM, standardized in FIPS 203, for key establishment;

• ML-DSA, standardized in FIPS 204, for digital signatures;

• SLH-DSA, standardized in FIPS 205, another digital-signature family based on hash functions.

NIST's current guidance says these algorithms can and should already be put into use, while the broader migration effort continues. It has also selected HQC as a future backup key-encapsulation algorithm using a different mathematical foundation from ML-KEM.

The ecosystem around those standards is moving too.

OpenSSL 3.5 added support for ML-KEM, ML-DSA and SLH-DSA, making post-quantum cryptography available through a widely used cryptographic software stack rather than requiring every application to implement the mathematics itself.

The Internet standards community is working on hybrid TLS mechanisms such as X25519MLKEM768, which combine a conventional elliptic-curve exchange with ML-KEM during the transition. The active May 2026 IETF draft defines several such hybrid mechanisms for TLS 1.3.

Cloudflare documents deployment of X25519MLKEM768 for key agreement and ML-DSA for signatures in its infrastructure.

And consumer-facing services are beginning to expose the technology too. Proton has introduced post-quantum protection for new encrypted email, illustrating an important point: migration often happens progressively rather than by retroactively rewriting every piece of historical data.

This is what the transition looks like in practice.

Not one giant replacement.

A gradual movement through protocols, libraries, certificates, identity systems, applications and archives.

8. Why hybrid cryptography is becoming important

Replacing every classical cryptographic mechanism immediately would be difficult.

That is one reason hybrid designs are attractive.

A hybrid system can combine a classical mechanism with a post-quantum mechanism.

For example:

X25519 + ML-KEM

The idea is not that one algorithm magically makes the other unnecessary. Rather, the system derives security from both components, providing a migration path while the ecosystem moves away from older public-key assumptions.

The IETF's current TLS work explicitly describes this kind of hybrid construction.

NIST's 2026 PIV work provides another useful illustration of the transition mindset: retain existing classical credentials while introducing post-quantum credentials so systems can migrate incrementally.

This is important because post-quantum cryptography is ultimately a migration problem.

The algorithms are only part of it.

Certificates need to change.

Protocols need to change.

Software libraries need to change.

Hardware may need updates.

Backups need consideration.

Archives need consideration.

And organizations need to know what they are actually running.

9. Where does a personal archive fit into all of this?

Most discussions about post-quantum security focus on the Internet itself: websites, messaging, email, certificates, cloud infrastructure and enterprise systems.

But there is another place where long-term protection matters.

The files sitting on your own computer.

Think about an archive you create once and then keep for years.

It might contain financial records, legal documents, research, business material, family records, photographs, personal projects or backups of information you would rather not become public.

The immediate question is familiar:

“How do I encrypt these files?”

But over a longer period, other questions start appearing.

Can I tell if the archive was modified?

Can I safely keep many files together?

Can I change the way the archive is protected later?

Can I add stronger cryptographic protection without redesigning the whole workflow?

Can I create something today that I can still recover and verify years from now?

That is where the idea of archival security becomes broader than ordinary file encryption.

And it is also where software such as RookDuel Avikal becomes relevant.

RookDuel Avikal: putting long-term protection into a normal desktop workflow

Avikal is an open-source desktop application and command-line tool built around a simple idea:

the user should be able to work with an archive normally, while the security architecture underneath can be considerably more sophisticated.

You select files or folders.

You create an archive.

You choose how much protection you need.

The complicated cryptography does not become a series of commands the user has to understand.

That matters because advanced security has historically had an awkward trade-off: the more sophisticated the protection becomes, the more technical the software often becomes to use.

Avikal is designed to approach that differently.

It can operate as an ordinary archive when encryption is not required, or provide stronger protection when the contents actually matter.

For example, a user may simply want an unencrypted archive for convenient storage. In other situations, the same workflow can be used for password-protected archives, stronger key-management arrangements, archive authentication, optional post-quantum protection or controlled-release scenarios.

The point is not that every archive needs every feature.

The point is that the user gets one archive workflow while the security options can scale with the importance of the data.

That is much closer to how people actually use files.

You do not have one level of importance for everything on your computer.

A downloaded image, a school project, a property document, a private research archive and a ten-year-old backup are not the same security problem.

Why this could matter to ordinary users

Post-quantum security can sound like something that belongs exclusively to governments and banks.

For the most immediate migration work, that is largely true.

But long-term archives create a smaller and more personal version of the same problem.

Consider someone who keeps a digital archive for fifteen or twenty years.

Today, the archive is protected by software and cryptographic assumptions that appear perfectly reasonable.

Ten years from now, the software ecosystem may be different.

Twenty years from now, some cryptographic mechanisms may be considered outdated.

The information itself, however, may still be valuable.

That is why the more useful question for an individual is not:

“Do I need post-quantum cryptography for everything?”

It is:

“What information am I likely to care about protecting for a very long time?”

For some people, the answer may be almost nothing.

For others, it could include important financial records, legal documents, intellectual property, research, confidential professional work, family archives or long-term backups.

Those are the situations in which an archival-security application becomes more interesting than a basic “put a password on this ZIP” workflow.

What makes an archival application different?

The difference is subtle but important.

A conventional archive mainly asks:

How do I package these files?

An encryption tool asks:

How do I keep someone from reading them?

A more complete archival-security system can ask both questions, along with:

How do I know the archive has not changed?

How do I manage access over time?

Can I change its protection later?

Can the archive support stronger cryptographic mechanisms as they become relevant?

Can some archives have a future release condition rather than immediate access?

These are not problems every person has.

But they are real problems.

And they become more relevant as the expected lifetime of the archive increases.

The important part of Avikal is not “more encryption”

Avikal is not interesting simply because it uses AES or post-quantum algorithms. Those technologies exist independently.

What makes the project interesting is the attempt to bring several security properties into a single archive application.

Its current architecture combines authenticated file storage, password and keyphrase protection, archive signing, optional post-quantum key establishment, rekeying and delayed-release capabilities.

That creates a different kind of archive workflow.

A user does not have to manually assemble a collection of cryptographic tools just to protect a long-lived archive.

The application handles that underlying machinery.

For someone who never wants more than a conventional encrypted archive, that extra architecture may be unnecessary.

For someone who wants stronger guarantees around a long-lived archive, it can become useful.

That distinction is important.

Avikal is not trying to make every file complicated. It is trying to make stronger archival security easier to use when the archive actually deserves it.

And that matters more as data becomes more valuable

The value of information does not necessarily disappear with age.

Sometimes it increases.

A personal archive can gradually become a record of someone's identity, finances, property, research, work and relationships.

A company archive can contain years of intellectual property.

A research archive can become more valuable as new discoveries build on it.

And increasingly capable AI systems make large collections of information easier to search, classify, correlate and analyze.

That does not mean AI is going to “break encryption.”

It means that the information hidden behind that encryption can become more valuable to analyze if it is ever exposed.

The longer an archive remains important, the more reason there is to think about what protects it now and what might protect it later.

That is the broader context in which applications like Avikal become interesting.

But no single application solves the entire problem

There is a temptation with new security software to ask whether it is “the best” or whether it replaces everything that came before it.

That is the wrong test.

A mature archive utility with enormous interoperability may be better for someone who simply wants a conventional encrypted archive.

A specialized archival-security application may be more appropriate when the user cares about additional integrity, key-management, post-quantum or controlled-release capabilities.

And no software can compensate for a compromised computer, a stolen password or a badly managed recovery key.

The useful question is therefore not:

“Is Avikal better than every other encryption tool?”

It is:

“Does Avikal solve a problem that matters in my particular archive?”

For long-lived, security-sensitive collections, that can be a meaningful question.

10. What should people actually do today?

The answer is not to panic and start replacing every piece of software on your computer.

For most people, the basics still matter far more.

Use strong authentication.

Keep devices and software updated.

Protect sensitive files.

Protect backups.

Keep recovery information safe.

Do not keep every security factor together in one place.

Then consider one additional question:

How long would I care if this information became public?

That is a surprisingly powerful way to think about security.

For developers, the next step is more technical.

Find where your systems use public-key cryptography. Understand which components handle key establishment, which handle signatures and which depend on long-lived certificates. Start designing systems that can eventually change their cryptographic mechanisms without having to be rebuilt from scratch.

For companies and institutions, start with visibility.

Find the cryptography.

Find the sensitive information.

Find the systems that will be difficult to migrate.

Find the archives that may still matter years after the software around them has changed.

Then prioritize.

For ordinary users, there is no need to treat the quantum threat like an emergency.

But there is value in making better choices today for information that is expected to remain important tomorrow.

And that is where the idea of a long-lived archive becomes relevant.

Conclusion: Security has a lifetime

The post-quantum problem is often presented as a future event.

A quantum computer arrives.

Old encryption breaks.

Everyone rushes to replace it.

Reality is likely to be much less dramatic—and much more difficult.

Information is created today.

Cryptographic systems protect it.

Software gets updated.

Standards evolve.

New algorithms appear.

Organizations take years to migrate.

Meanwhile, the information keeps its value.

That is the real problem.

Information can outlive the cryptography protecting it.

For governments and major organizations, that can mean decades of sensitive data and enormous migration projects.

For ordinary people, it may apply to a much smaller set of information: the files they genuinely expect to keep private for a very long time.

And for archival-security software such as RookDuel Avikal, it raises an increasingly relevant question:

Can advanced security be built into an archive without making the archive itself difficult for an ordinary person to use?

That is a practical question, not a science-fiction one.

Post-quantum security is therefore not simply about finding a new algorithm.

It is about preparing systems for a world in which today's assumptions will eventually change.

The goal is not to predict the exact day that happens.

The goal is to make sure the information we create today still has a reasonable security strategy when that day arrives.

Because security has a lifetime.

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

Project website: https://avikal.rookduel.tech
Source code: https://github.com/RookDuel/Avikal

The problem was never possibility.

It was scalability.

Linear move-based systems rarely exceeded 50–200 bytes before games became suspiciously long. Even AI-assisted approaches for Chinese Chess (2025) averaged just ~51 bytes per game.

The 2026 variation-tree encoding method changes that constraint.

Instead of treating a chess game as a single linear sequence, it treats PGN as what it actually is: a tree structure.

Full technical research and benchmarks:
👉 https://www.rookduel.tech/research/Chess-Steganography-Breakthrough-2026

Why Previous Methods Were Limited

Earlier systems fell into two categories:

1. Multi-Channel Encoding (2004)

Used PGN headers, comments, formatting tricks, and legal moves.
Capacity reached several kilobytes—but at the cost of unnatural annotation patterns and weak encryption (XOR-based).

2. Linear Move Encoding (2009–2019)

Systems like chess-steg encoded bits by selecting from legal moves.

Typical characteristics:

• ~4 bits per ply

• 100–200 bytes practical ceiling

• No encryption or integrity protection

• Encoding ends when the game ends

Even AI filtering improved realism, not capacity. The structure remained linear.

The Shift: Variation-Tree Encoding

PGN natively supports variations:

1.e4 (1.d4 d5 2.c4) e5 2.Nf3 (2.Bc4 Nc6) Nc6

Serious analysis often contains deep nested branches. That structure is legitimate, standardized, and platform-supported.

Traditional Model

Game → Moves → End → Stop encoding

Variation-Tree Model

Game → Mainline + Nested Variations → Continue encoding across branches

Capacity now scales with branching depth, not just move count.

Core Architecture

Encoding Pipeline

Message
→ Brotli Compression
→ AES-256-GCM Encryption
→ Integer Conversion
→ Legal Move Selection
→ Standard PGN Output

Decoding

PGN
→ Move Extraction
→ Integer Reconstruction
→ Authenticated Decryption
→ Decompression
→ Original Message

Security properties:

• AES-256 confidentiality

• GCM authentication (tamper detection)

• Optional PBKDF2 password protection

• Encrypted timestamp + identifier metadata

Measured Capacity

Two representative tests:

Highly Repetitive Text (~86 KB)

• Compressed to ~311 bytes

• Encoded in 555 plies

• ~3.4 KB PGN output

• ~1 second encode time (consumer laptop)

Realistic Text (~88 KB)

• Compressed to ~21.5 KB

• Encoded across ~40,000 plies (mainline + 1,000+ variations)

• ~259 KB PGN

• ~5–6 minutes encode time (single-threaded laptop)

Effective rate: ~4.3 bits per ply.

Important: Larger payloads increase detectability. Capacity is technically high; operational use should remain conservative.

Practical Capacity Context

Improvement ranges from 10× to over 1000× depending on baseline comparison.

Security Model

This system provides:

✔ Cryptographic confidentiality (AES-256)
✔ Integrity verification (GCM tag)
✔ Standard PGN validity
✔ Legal move compliance
✔ Plausible deniability

It does not guarantee:

✘ Statistical indistinguishability
✘ Resistance to dedicated steganalysis at extreme payload sizes

Risk guidance:

• <5 KB: low detection probability

• 5–20 KB: moderate analysis risk

• 20+ KB: increasingly suspicious

When This Makes Sense

Appropriate use cases:

• Encrypted seed phrase backup

• Secure key distribution

• Covert configuration transfer

• Research demonstration

Not appropriate:

• Large binary files

• High-surveillance adversarial environments

• Payloads exceeding ~100 KB

Broader Insight

The breakthrough is structural:

Rule-constrained symbolic systems (like chess) become high-capacity steganographic channels when their native branching complexity is fully exploited.

The same principle could extend to:

• Go

• Shogi

• Bridge bidding systems

• Structured musical notation

Full Research & Benchmarks

This page is a condensed overview.

Complete methodology, formal discussion, benchmark data, and references are available here:

👉 https://www.rookduel.tech/research/Chess-Steganography-Breakthrough-2026

Author: Atharva Sen Barai
Published: February 2026
Live Demo: https://encode.rookduel.tech

This work explores an alternative direction: symbolic, rule-constrained steganography using legal chess notation (PGN). By combining deterministic chess move generation with AES-256-GCM authenticated encryption, the system produces standard, valid chess games that can securely encode encrypted messages while remaining compatible with existing chess tools and PGN validators.

The full technical design and evaluation are presented in my research paper. This article explains the motivation, design decisions, and practical implications of the project.

Why Chess PGN Is a Viable Steganographic Medium

Chess PGN is a structured, globally standardized textual format used to represent games and analysis. It offers several properties that make it particularly suitable for steganography:

• Every move is constrained by formal chess rules

• Long games and deep analysis trees are common and expected

• PGN files are widely shared, archived, and parsed across platforms

• Variations are a native feature of the format

Unlike media-based carriers, PGN does not degrade under copying or reformatting, and its validity can be mechanically verified. A syntactically correct PGN that follows chess rules does not appear anomalous simply because it is long or complex.

This project leverages those properties to create a rule-validated carrier, where illegal or malformed outputs are structurally impossible.

System Overview

The system operates as a deterministic pipeline:

Plaintext → Authenticated Encryption → Integer Conversion → Chess Encoding → PGN Output

1. The input message is optionally protected with a password.

2. The message is encrypted using AES-256-GCM, providing confidentiality and built-in integrity verification.

3. The encrypted payload is converted into a large integer.

4. That integer is encoded into chess moves by selecting legal moves based on its value.

5. When linear encoding capacity is exhausted, chess variations are introduced to extend capacity.

Decoding reverses the process. Any modification to the PGN—whether accidental or intentional—results in authentication failure during decryption.

Cryptographic Design and Security Model

The security of the system is grounded in established cryptographic primitives rather than obscurity.

Authenticated Encryption

• AES-256-GCM is used to ensure both confidentiality and integrity.

• Any alteration to the encoded data results in authentication failure.

• No separate checksum or signature is required.

Optional Password Protection

• Password-based encryption uses PBKDF2-HMAC-SHA256 with a high iteration count.

• This adds resistance against offline brute-force attacks.

• A truncated password hash allows fast rejection of incorrect passwords without full decryption.

The system does not claim information-theoretic steganographic security. Indistinguishability claims are empirical and based on observed behavior, not formal proofs. This limitation is explicitly acknowledged in the research.

Deterministic Encoding Using Legal Chess Moves

At the core of the system is a deterministic mapping between integers and legal chess moves.

For any given board position:

• All legal moves are generated

• Moves are sorted deterministically

• The encrypted integer selects a move using modular arithmetic

• The remaining value continues into the next position

Each position effectively acts as a base-N encoding system, where N equals the number of legal moves available in that position. On average, this yields approximately 4.3 bits per chess ply, consistent with experimental results.

Because the data is encrypted before encoding, the move selection appears statistically similar to arbitrary play rather than reflecting properties of the original message.

Capacity Expansion Through Variations

A defining contribution of this work is the systematic use of chess variations to expand encoding capacity.

Earlier symbolic or text-based steganography approaches typically encode data along a single linear structure. Once exhausted, encoding must stop. Chess PGN naturally avoids this limitation.

When the mainline game can no longer encode additional data:

• Variations are added at positions with multiple legal alternatives

• Each variation becomes an additional encoding path

• Encoding proceeds across the resulting move tree

This approach provides theoretically unbounded capacity, constrained primarily by practical PGN size limits rather than the encoding model itself. Importantly, such variation-heavy PGNs are common in real chess analysis, making this expansion method structurally consistent with legitimate content.

Integrity and Tamper Detection

Because encryption uses AES-GCM:

• Any modification to moves, order, or structure is detected

• Insertions, deletions, or reordering of moves break authentication

• Tampering cannot silently alter the decoded message

This makes the system tamper-evident by design, a property that many traditional steganographic techniques lack.

Comparison With Prior Research

Compared to traditional image or audio steganography:

• No manipulation of pixel or frequency distributions

• No vulnerability to compression or transcoding

• No fixed carrier size limits

Compared to text-based steganography:

• No synonym substitution or linguistic artifacts

• No dependence on natural language generation

• No semantic distortion

Compared to earlier game-based ideas:

• Uses standard PGN rather than custom formats

• Integrates authenticated encryption, not just concealment

• Introduces structured variation-based capacity scaling

The system is compatible with existing chess tooling while providing stronger integrity guarantees than most steganographic methods.

Live Implementation and Demo

A public demo of the project is available at:

https://encode.rookduel.tech

For demonstration purposes:

• A 10,000-character input limit is currently enforced

• This limit applies only to the demo environment

• The underlying system supports significantly larger payloads

The demo also includes optional password protection, allowing users to observe authenticated encryption behavior in practice.

Practical Limitations

The system is not intended to hide arbitrarily large datasets without scrutiny. Extremely long PGNs with excessive branching may attract attention, and encoding time increases linearly with message size.

The design prioritizes correctness, verifiability, and security over maximal concealment.

Closing Remarks

This project demonstrates that rule-constrained symbolic systems, such as chess, can serve as reliable steganographic channels when combined with modern cryptography. By respecting both cryptographic and domain-specific constraints, the system produces outputs that are valid, portable, and tamper-evident.

Rather than replacing existing steganographic approaches, this work introduces a complementary direction—one where structure, rules, and determinism form the foundation of secure hidden communication.

Note: The header image for this article is AI-generated and is used solely for visual illustration.

This post breaks down their strengths and weaknesses based on real developer experiences and early community feedback, giving you a clear, honest comparison to help your team choose the right tool.

Overview

Google Antigravity

Antigravity is Google’s bold entry into agentic development. It aims to be fast, fluid, and deeply capable—powered by the Gemini 3 model and built around a dedicated Agent Manager surface. Antigravity feels modern and ambitious, with agents capable of planning, executing, and validating multi-step tasks that span the editor, terminal, and browser.

Amazon Kiro

Kiro, on the other hand, is designed with a stability-first mindset. It’s built on Code OSS and takes a spec-driven approach where developers define intent through specs, hooks, and steering files. Instead of chasing maximal autonomy, Kiro focuses on predictability, safety, and giving developers full control—even if that means being slower or less “magical.”

Feature Comparison Table

Strengths and Weaknesses

Antigravity Strengths

• Fast and fluid experience — its speed is consistently praised.

• Advanced agent autonomy — agents can plan multi-step tasks across tools.

• Powerful for prototyping — quick to experiment and build features end-to-end.

• Impressive newness — despite being early, the capability is already strong.

• Artifacts — screenshots, recordings, and task plans help with verification.

Antigravity Weaknesses

• Trust issues — developers report agents taking unexpected actions.

• Unpredictability — sometimes fails to respect project structure or context.

• Security concerns — autonomy may feel risky for critical environments.

• Early-stage roughness — bugs, instability, and inconsistent behavior.

• Not ideal for IaC or production-sensitive tasks — too much autonomy.

Kiro Strengths

• Highly reliable and predictable — developers highlight its consistency.

• Feels safe — less autonomy means fewer surprises during execution.

• Great for critical workflows — especially infrastructure and backend work.

• Spec-driven governance — specs, hooks, and steering ensure intent is clear.

• Team-friendly — reproducible output reduces ambiguity and mistakes.

Kiro Weaknesses

• Slower compared to Antigravity — feels more bureaucratic.

• Less “magical” — fewer surprising leaps or big wins.

• Not as fluid or futuristic — prioritizes control over creativity.

• AI is less advanced — capabilities feel more limited compared to Gemini.

Decision Guide

Choose Antigravity if you:

• Want high-speed development

• Need advanced AI capabilities

• Work in early-stage product development

• Value autonomous agents handling multi-step tasks

• Don’t mind occasional unpredictability for the sake of velocity

Choose Kiro if you:

• Prioritize stability and safety

• Build infrastructure or mission-critical systems

• Need predictable, reproducible agent behavior

• Want stricter control over AI interactions

• Prefer tools that behave consistently across team environments

Realistic Conclusion (Not Hype, Just Truth)

The truth is simple: neither Antigravity nor Kiro is objectively “better.”
They are built for different priorities and different types of engineering teams.

• Antigravity is the future-facing option—fast, ambitious, and incredibly capable, but with early-stage unpredictability that makes it better suited for experimentation and rapid development than safety-critical work.

• Kiro is the stability-first option—consistent, controlled, and predictable, ideal for teams who need reliability above all else, even if that means sacrificing speed and autonomy.

For most startups and product-focused teams, Antigravity feels exciting and can dramatically accelerate iteration.
For teams building infrastructure, large distributed systems, or environments with strict operational requirements, Kiro is still the safer, more responsible choice.

Both tools are pushing the industry forward, but for now, each one serves a different reality.

Disclaimer: Portions of the image were generated using AI. Google Antigravity and Kiro logos are used for informational comparison only and may not depict their exact official designs. No affiliation or endorsement is implied.