Skip to content
Back to blog

The Secret Hidden Across Two Images

5 min read
The Secret Hidden Across Two Images

Two transparent sheets can each look like ordinary black-and-white noise, yet reveal a word or picture when aligned precisely. That is the central idea of visual cryptography: divide a secret into images that are useless separately, while allowing the human eye to recover the combined result without a computer or a cryptographic calculation.

The idea matters not because transparencies are more convenient than digital encryption. Naor and Shamir showed something more fundamental: threshold secret sharing could be designed directly for human vision, with explicit rules for how many shares must meet and what an incomplete set is allowed to reveal.

From EUROCRYPT 1994 to the published construction

Moni Naor and Adi Shamir presented a preliminary version of Visual Cryptography at EUROCRYPT 1994 in Perugia. The paper appeared in 1995 in volume 950 of Lecture Notes in Computer Science, pages 1–12. The authors defined a general K-of-N construction in which any K shares reveal the picture, while K−1 shares disclose nothing about it. Their original paper covers not only the simplest 2-of-2 case, but also higher thresholds, continuous-tone images, and shares that resemble meaningful pictures.

Visual cryptography is often mentioned alongside Shamir's 1979 secret sharing scheme, but the two are not the same construction in different clothing. Shamir's original shares are numbers in a finite field, and polynomial interpolation recovers the secret. Visual cryptography uses transparent subpixel patterns as shares, while optical stacking performs the recovery operation.

Turning one pixel into two shares

In the practical 2-of-2 version, every pixel of a black-and-white secret expands into a 2×2 block. Each block contains two black and two white subpixels, with six possible arrangements. For every source pixel, the encoder chooses one arrangement at random and places it in the first share.

For a white secret pixel, the second share receives the same pattern. Stacking the sheets leaves half of the block white, so the eye sees gray. For a black secret pixel, the second share receives the complementary pattern, making all four positions black when stacked. The contrast between blocks containing two and four black subpixels forms the visible image.

The original paper also describes a construction with two subpixels per source pixel, but a 2×2 block preserves the image's aspect ratio. The tradeoff is easy to see: every pixel now occupies four times the area, white reconstructs as gray, and even a small alignment error can reduce legibility.

For a white secret pixel, two identical 2×2 patterns retain two white subpixels when optically stacked; for a black pixel, complementary patterns produce a fully black block

The boundary of perfect secrecy

A single share looks the same whether the secret pixel is white or black. In either case it contains a random pattern with two black and two white subpixels. Someone holding only one share sees the same distribution over the six possible patterns and cannot infer the original pixel's color, even with unlimited computing power. This is the precise sense in which the classical scheme provides perfect secrecy.

That guarantee applies to pixel content under correct random generation. It does not hide the dimensions or shape of the medium, and reusing a random share for different secrets violates the original security model. A physical implementation adds practical constraints as well: print quality, transparency, and alignment affect the visible result even though they do not change the mathematical shares.

What followed the original paper

Naor and Shamir's paper established a field of its own. Later constructions explored different access thresholds, lower pixel expansion, color and continuous tones, improved contrast, and shares disguised as ordinary images. These objectives interact: improving one parameter often costs share size, reconstructed image quality, or stricter alignment requirements.

Classical transparencies did not become an everyday replacement for encrypted messages, but the model remains useful. It makes the distinction between computational security, which relies on an attack being impractical, and information-theoretic security, where an incomplete set of shares simply contains no information about the secret.

What the browser tool actually does

The Visual Cryptography tool borrows the broader idea of separate visual carriers, but it is not an implementation of Naor and Shamir's optical construction. It first turns text into a digital grid. In Two shares mode it then splits that grid with a bitwise XOR operation. Both images must be given to the decoder to recover the message; physically stacking them will not make the secret appear.

All processing runs locally in the browser. Text is encoded as UTF-8, and a Deflate result is retained only when it makes the payload smaller. If password protection is enabled, the tool encrypts the data with AES-256-GCM and derives the key through PBKDF2-SHA-256 with 200,000 iterations. This does not turn a weak password into a strong one, so sensitive data still requires a good passphrase. Without password protection, a single image is an encoding, not a confidentiality mechanism.

The payload also receives a CRC32 checksum and Reed–Solomon blocks. They serve different purposes: the checksum detects damage, while parity symbols can repair some errors. The header always has eight Reed–Solomon parity bytes, while payload protection depends on the selected profile.

ProfileAdded protection
CompactCRC32 with no Reed–Solomon payload parity
BalancedUp to 32 parity bytes per block
RobustUp to 64 parity bytes per block
MaximumThree interleaved copies of each cell and up to 96 parity bytes per block

Maximum is designed around recovering from roughly 10% random cell damage, but that is not a universal promise for every image. The outcome depends on payload size, profile, damage pattern, and source quality. The built-in simulator therefore does more than display an abstract score: it introduces 1% to 35% random errors or a contiguous scratch, then runs the actual decoder against the damaged grid.

From four levels to Glyph Mosaic

In the standard modes, one cell stores two bits using one of four levels. The grid can be fitted to square, landscape, or wide framing, with unused cells filled by deterministic noise. Fourteen render styles change how those same values look, using flat pixels, halftones, contours, mazes, Truchet arcs, isometric blocks, or topographic lines. Palettes and decorative elements change the presentation, but do not by themselves increase the underlying payload.

Glyph Mosaic, inspired by libcimbar, uses a different alphabet. A value is represented by both an 8×8 symbol template and its ink color. Its modes combine 16 or 32 shapes with 4 or 8 colors to store 6 to 8 bits per cell. The templates maintain substantial Hamming distance, and the decoder probes multiple possible grid sizes, which helps with moderate scaling and blur. The format does not have QR-style finder patterns or perspective correction, however, so an arbitrarily rotated photo, severe crop, or very small cells may fail to decode.

Why two digital shares still need qualifications

In Two shares mode, the tool uses the browser's cryptographic random generator to create a uniformly random grid A, then computes each B cell as the XOR of A and the encoded data cell. With fresh randomness and a fixed grid size, the distribution of either share does not depend on the source cell, so A or B alone cannot recover the grid content.

The files still reveal their dimensions, chosen style, palette, and some settings, and the two shares need matching geometry before they can be combined. This is why the broad statement that an image “reveals nothing” needs a boundary: the cell values are hidden, but external properties of the files remain observable. After recombination, the decoder reads the header, repairs errors within the selected profile's capacity, checks integrity, decrypts when necessary, and returns the original text.

The result is exported as an indexed PNG with a four- or eight-color palette, adaptive per-row filters, and Deflate compression. It can also be copied as a Base64 data URL. The classical idea of two individually useless carriers survives in digital form, but its recovery mechanism and security boundaries are different.

Frequently asked questions

What is visual cryptography?

It is a way to split a secret image into noise-like shares that reveal the picture when stacked. In the classical 2-of-2 construction, either share is statistically independent of the hidden pixel's color, while the combined result can be read by eye without computation.

Who invented visual cryptography?

Moni Naor and Adi Shamir presented a preliminary version of Visual Cryptography at EUROCRYPT 1994. The paper appeared in 1995 in volume 950 of Lecture Notes in Computer Science.

Why does one classical share reveal nothing?

For every pixel, the encoder randomly selects one of six 2×2 patterns containing two black and two white subpixels. A single share has the same distribution for a white or black secret pixel, so its color cannot be inferred. This assumes correct randomness and does not hide the image dimensions or other external properties.

How does the browser tool differ from the classical scheme?

The classical construction uses monochrome transparencies and reveals an image through physical stacking. The browser tool encodes text into a digital grid and can split that grid into two XOR shares that software must recombine. It also offers password encryption, error correction, and artistic render styles.

How secure is Two shares mode?

For a fixed-size grid, the tool generates a uniformly random Share A and computes Share B as A XOR the data. With fresh randomness, either share alone hides the cell values, but dimensions, the selected style, and other image settings remain visible. A single image needs password encryption if confidentiality is required.

Author

Fullstack Engineer

In commercial development since 2011 — over 15 years. Author of two SaaS products, TeleGo.io and LingvoHabit.com. The articles here come out of real client and product work.

About the authorWrite on Telegram

Related Articles