Omnia Crypta is a free, open collection of cryptographic tools that run entirely in your browser. No accounts. No servers. No tracking. Everything happens locally on your device, and nothing you generate here is ever transmitted anywhere.
For most of history, strong cryptography belonged to governments, military institutions, and large organizations. The tools to create unbreakable ciphers, generate secure keys, and protect private communications were simply out of reach for ordinary people. That has changed. The mathematics behind public-key encryption, one-time pads, and high-entropy password generation are now publicly understood and freely implementable. The goal of this site is to make those tools as easy to reach as a calculator.
Owning your keys means owning your secrets. When you generate a key pair here, the private key never leaves your machine. When you create a one-time pad, only you hold it. When you build a passphrase, no service ever sees it. There is no intermediary to compel, no account to breach, no company to comply with a request for your data. Your security belongs entirely to you.
This kind of access is not something to take for granted. Tools that run locally, require no account, and keep you in full control are rare because they do not generate revenue or harvest data. They exist because people believe that cryptographic self-sufficiency matters. Use these tools, understand how they work, and share them. The power they give you is real.
Click Generate to create a pad…
A one-time pad (OTP) is the only encryption method that has been mathematically proven to be completely unbreakable: not just difficult to crack, but impossible, even with unlimited computing power. In 1949, mathematician Claude Shannon proved this in a landmark paper on information theory.[1] The concept is older than that: Gilbert Vernam patented the basic mechanism in 1919,[2] and spy agencies worldwide used physical OTP pads throughout the Cold War.
The idea is simple. You and your correspondent each carry identical copies of a "pad": a long list of truly random characters that only the two of you possess. To send a secret message, you use the next unused row of the pad to scramble it. The recipient unscrambles it using the same row. Both of you then destroy that row. It is never used again, hence the name "one-time."
The math: modular addition (clock arithmetic)For letter pads (A–Z), assign each letter a number: A=0, B=1, C=2 … Z=25. Encryption works like a clock: once you pass Z, you wrap around back to A.
To encrypt one letter: Add the plaintext number and the key number. If the result is 26 or more, subtract 26.
Example: Plaintext = H (7), Key = K (10) → 7 + 10 = 17 → R
To decrypt: Subtract the key number from the ciphertext number. If the result is negative, add 26.
Example: Ciphertext = R (17), Key = K (10) → 17 − 10 = 7 → H
For hex pads, the operation is XOR (exclusive-or). XOR works at the binary level: a bit XOR'd with itself is always 0, a bit XOR'd with 0 is unchanged. This makes XOR its own inverse: encrypting and decrypting use the exact same operation. Just XOR with the key to encrypt; XOR with the key again to decrypt.
Why it is theoretically unbreakable: Shannon's perfect secrecyImagine an attacker intercepts your ciphertext but has no copy of the pad. They want to figure out the original message. Here is the crucial insight: for every possible plaintext message of the right length, there exists exactly one key that would produce the observed ciphertext from that message. Since the key was chosen with perfect randomness, every plaintext is equally likely. The ciphertext gives the attacker zero useful information: mathematically, learning the ciphertext does not change the probability of any plaintext at all. Shannon called this perfect secrecy.[1]
This is a far stronger guarantee than any other cipher in existence. Modern ciphers like AES are believed to be unbreakable, but their security rests on unproven mathematical assumptions: that certain problems are computationally hard. The one-time pad's security needs no such assumptions. It is an absolute mathematical proof. No computer, no algorithm, no mathematical breakthrough can ever break a correctly used OTP, because there is no information to extract. This includes quantum computers: Shor's algorithm and its relatives attack the mathematical structure of ciphers like RSA,[22] and the one-time pad has no mathematical structure to attack. A correctly used pad is exactly as unbreakable in a world with quantum computers as in one without them.
The two-time pad: why reuse is catastrophicPerfect secrecy holds only if each key row is used exactly once. Reusing a row destroys security completely. Here is why:
If C₁ = P₁ XOR K and C₂ = P₂ XOR K, then C₁ XOR C₂ = P₁ XOR P₂. The key cancels out entirely. An attacker who XORs both ciphertexts together gets the XOR of both plaintexts. Because natural language has predictable patterns (common words, letter frequencies, grammatical structures), a technique called crib-dragging (guessing known short phrases and sliding them across the combined output) can recover both original messages in minutes, with no key at all.
This is not a theoretical concern. In the 1940s, Soviet intelligence reused one-time pad pages under wartime production pressure. U.S. and British intelligence launched a secret program called VENONA that exploited exactly this mistake.[3] Over the following decades, VENONA analysts decrypted thousands of Soviet intelligence cables. The program identified dozens of Soviet spies operating in the United States and United Kingdom, including Julius Rosenberg. That single operational error (using a key twice) eventually unraveled years of intelligence work and cost lives. This is why the rule is absolute: one row, one message, no exceptions.
Step-by-step usagecrypto.getRandomValues(), the W3C Web Cryptography API's standardized interface[18] to your operating system's cryptographic entropy pool and the same source used by TLS and every serious cryptographic application, drawing from hardware timing events, CPU randomness instructions, and other unpredictable physical sources. A pad produced by flipping coins, rolling dice carelessly, or having a human "pick random numbers" is almost certainly biased and unsafe. Human beings are terrible random number generators; we instinctively avoid long runs of the same character, favor certain numbers, and create subtle patterns we are not even aware of. Any such pattern in the key partially exposes the plaintext.Type a message using letters A–Z. Spaces and punctuation are stripped automatically, because the letter-based OTP cipher only operates on the 26-letter alphabet. Then generate a random key or paste one in. When you click Encrypt, the demo shows you every character pairing side by side: the plaintext letter on top, the key letter in the middle, and the resulting ciphertext letter on the bottom. Each column is one letter of encryption. To produce it: convert both letters to numbers (A=0, Z=25), add them, and if the sum reaches 26 wrap it back to 0, the same way a clock wraps from 12 back to 1. The number you land on is the ciphertext letter. Notice that the output looks completely random even when the input is a recognizable word. That is the point. No pattern from the plaintext survives into the ciphertext as long as the key is random.
Paste the encrypted message and the exact same key that was used to encrypt it; the key must match letter for letter, in the same order. Click Decrypt to reverse the mod-26 addition: for each pair, subtract the key letter's number from the encrypted letter's number. If the result goes below zero, add 26 to wrap it back around. The visualization shows each step so you can verify the arithmetic yourself. One important thing to understand: if you use the wrong key, you will not get an error message. The math will still run and produce output; it will just be meaningless letters. A one-time pad has no way to tell a correct decryption from an incorrect one, because every possible plaintext is equally valid without the key. This is actually part of what makes it unbreakable: an attacker cannot tell when they have found the right answer.
Password strength comes down to one thing: how hard it is to guess. The measure used is entropy, counted in bits. Each additional bit of entropy doubles the number of possible passwords an attacker must try. A password with 40 bits of entropy has about one trillion possible values. One with 80 bits has over a septillion, a trillion times more. One with 128 bits has about 3.4 × 10³⁸ possible values, a number that dwarfs every grain of sand on Earth and every star in the observable universe combined.
Entropy is not about whether a password "looks" random to a human. It is purely a count of possibilities. A password of all lowercase letters is weaker than one mixing cases and digits; this is not because lowercase looks simpler, but because the smaller alphabet means fewer possible passwords of the same length.
How entropy is calculatedThe formula is: entropy (bits) = length × log₂(charset size). The charset is the pool of characters the generator draws from:
A 16-character alphanumeric password has 16 × 5.95 ≈ 95 bits of entropy. Adding symbols gains about 1 bit per character. Adding more length gains about 6 bits per character. This is why length matters more than complexity. Going from 16 to 24 characters adds 48 bits of entropy. Switching from alphanumeric to full symbols on a 16-character password adds only about 10 bits. If you can only do one thing, make the password longer.
Why picking characters randomly is harder than it soundsChoosing characters uniformly at random from a list seems simple, but there is a hidden trap called modulo bias. A computer's random number generator typically produces integers from 0 to 2³²−1 (about 4.3 billion possible values). If your alphabet has 62 characters, dividing 4.3 billion by 62 leaves a remainder of 4. This means the first four characters of the alphabet are very slightly more likely to appear than the others, creating a tiny but real statistical leak.
This generator eliminates modulo bias entirely using rejection sampling. It generates random values and throws away any that fall in the leftover range (values above the largest exact multiple of 62 that fits in a 32-bit number). The remaining values map perfectly and evenly onto the alphabet. Every character has an exactly equal probability. No character is even fractionally favored. This is the same technique used in professional cryptographic libraries like libsodium and OpenSSL. The random values themselves come from crypto.getRandomValues(), the W3C Web Cryptography API's standardized cryptographic random source,[18] backed by the operating system's entropy pool on every platform.
The strength bar and crack time shown beneath your password assume an attacker is trying one trillion guesses per second (10¹²/s). This is a realistic worst-case benchmark for a well-funded attacker with specialized GPU hardware against a weakly hashed password. Modern password-cracking rigs can exceed 100 billion guesses per second against old MD5 hashes. Against a properly designed slow hash like bcrypt or Argon2 (what reputable services use), the real rate drops to thousands or millions per second, making the crack time far longer in practice. The one-trillion benchmark is a deliberately conservative floor.
At 10¹² guesses per second, exhausting the whole keyspace takes about 13 days for a 60-bit password and about 38,000 years for an 80-bit one; a 128-bit password would take hundreds of millions of times the current age of the universe. An attacker finds the password on average halfway through the search, so the expected time is roughly half of each figure. The readout beneath the generator reports that expected time (about 7 days at 60 bits, about 19,000 years at 80), because it is the more honest number to plan against. Even so, the margin grows astronomically with every added bit.
Diceware and the EFF word listThe Diceware passphrase generator uses the EFF large word list,[6] a set of exactly 7,776 common English words. The number 7,776 is not a coincidence: it equals 6⁵, because the original Diceware method (created by Arnold Reinhold in 1995[5]) was designed for physical dice. You roll five standard six-sided dice, read the five digits as a number like 24151, look it up in the word list, and that is your word. No computer required.
Each word chosen from a 7,776-word list contributes exactly log₂(7,776) ≈ 12.9 bits of entropy. Six words gives about 77.5 bits, comparable in strength to a fully random 12-character password drawn from the complete printable ASCII set. But a six-word passphrase like vessel-ranch-fading-comet-plank-orbit is far easier to memorize and type correctly than j#8Kw!mQ2&vP. Memorability is not a security weakness here; the security comes from the size of the word list and the randomness of the selection, not from the words being hard to remember.
The EFF specifically selected words that are: common enough to be recognizable, unambiguous to spell out loud, free of homophones (words that sound identical, like "two" and "too"), and not offensive. Short words and words with tricky alternate spellings were removed. The goal was a list a person could use in the field with a printed copy and physical dice, with no memorization of rules required.
A critical note: when people choose words they think are random, they are not. Studies consistently show that human-selected passphrases contain far less entropy than their length suggests. People favor short common words, avoid unusual words, unconsciously follow grammatical patterns, and rarely pick the same word twice even when repetition would be statistically normal. All of these patterns reduce the actual search space an attacker needs to explore. This generator solves the problem with crypto.getRandomValues() and rejection sampling, ensuring every word on the list has an exactly equal probability of appearing, every time, regardless of what words came before.
Every number system in this converter shares the same underlying mechanism: positional notation. The value of a digit depends not just on what symbol it is, but on where it appears in the number. In base 10, the rightmost position is worth 10⁰ = 1, the next position to the left is worth 10¹ = 10, then 10² = 100, and so on. The number 347 means (3 × 100) + (4 × 10) + (7 × 1). Switch the base and the same logic applies exactly. In base 2, positions are worth 1, 2, 4, 8, 16… In base 16, they are worth 1, 16, 256, 4,096… In any base b, a digit string dn…d1d0 represents the value dn × bn + … + d1 × b + d0. Every field in this converter is a different way of writing the same underlying number.
Base 10: ten fingers and an anatomical accidentHumans count in base 10 for the same reason fingers exist: we have ten of them. Finger counting appears in virtually every pre-literate culture, and when you count on fingers, the natural stopping point (one complete set of hands) becomes the base. The very word digit comes from the Latin digitus, meaning finger. Roman numerals V and X are thought to depict an open hand and two hands crossed.
Base 10 has one mathematical convenience: 10 = 2 × 5, so it divides cleanly by 2 (giving 5) and by 5 (giving 2). But it is not particularly special. Base 12 is mathematically superior for everyday arithmetic: 12 divides evenly into halves, thirds, quarters, and sixths (divisors: 1, 2, 3, 4, 6, 12). This is why the Babylonians counted the three finger segments on each of four fingers to reach 12, and why that number embedded itself in our measurement systems: 12 inches in a foot, 12 months, 12 hours on a clock face. Base 60 (the Babylonian positional system for mathematics and astronomy) is even richer: 60 is divisible by 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, and 30. It survives today in 60 minutes to an hour, 60 seconds to a minute, and 360 degrees in a circle. Base 10 is not a mathematical ideal. It is an anatomical coincidence that became a global convention.
Base 2 (binary): the language of transistorsA transistor is a switch. It can be open or closed, conducting or not conducting. Two states. A single transistor cannot represent the digit 7, because there is no seventh state in the physics. This is why every computer ever built operates in binary. Not because base 2 is mathematically elegant (it produces very long digit strings), but because the hardware is two-state by design. Billions of transistors, each signaling 0 or 1, combine to represent everything from a spreadsheet cell to a video frame.
Claude Shannon formalized the mathematics of this in his 1948 paper A Mathematical Theory of Communication,[4] coining the term bit (binary digit) as the fundamental unit of information. Shannon proved that log₂(N) bits are needed to distinguish among N equally likely possibilities. A coin flip is 1 bit. A standard six-sided die roll is log₂(6) ≈ 2.58 bits. A byte (eight bits) can hold 2⁸ = 256 distinct values, enough to represent any integer from 0 to 255. This tool internally represents all data as sequences of bytes, then converts those byte sequences between different bases for display.
Base 16 (hexadecimal): compact binary for humansBinary is truthful but verbose. The letter H has the ASCII code 72. Written in binary, that's 01001000, which is eight digits for a number that fits in two decimal digits. Hexadecimal exists as a shorthand. The key insight: 16 = 2⁴, so each hex digit represents exactly four bits, a unit called a nibble. One byte (eight bits) becomes exactly two hex digits. The value 72 is 0x48 in hex: 4 × 16 + 8 = 72. The word "Hello" is the hex string 48 65 6c 6c 6f (five bytes, ten hex characters). Converting between binary and hex requires no arithmetic; you simply substitute four-bit groups for hex digits and back.
Hexadecimal uses the digits 0–9 for values 0–9 and the letters A–F for values 10–15. Once you know to look, you see it everywhere: web colors (#FF5733 is three bytes of red, green, and blue: 255, 87, 51); memory addresses (0x7FFF0000); cryptographic hashes (sha256: 2cf24dba…); and network hardware identifiers (a MAC address like A4:C3:F0:85:12:3B). Hex is binary wearing a costume that humans can read and write without counting individual zeros and ones.
Early internet protocols (SMTP for email, HTTP for the web) were designed to carry 7-bit ASCII text. They were not built to safely transport arbitrary binary data: encrypted blobs, image files, compiled programs. Routers and mail relays of the era would corrupt or silently strip bytes with the high bit set. Base64 was the workaround: represent any binary data using only safe printable ASCII characters, so it can travel over any text-oriented channel without damage.
The Base64 alphabet has 64 symbols: A–Z (values 0–25), a–z (26–51), 0–9 (52–61), + (62), and / (63). Since 2⁶ = 64, each Base64 character encodes exactly 6 bits. The encoding algorithm takes three input bytes (24 bits) at a time and splits them into four 6-bit groups, each producing one output character. Three bytes in, four characters out: a 33% size overhead. If the input length isn't a multiple of three, one or two = padding characters are appended to make the output length a multiple of four.
You encounter Base64 constantly: the data:image/png;base64,… strings embedded in web pages; the -----BEGIN RSA PRIVATE KEY----- blocks in this tool (PEM format is just Base64 wrapped in header lines); the tokens in HTTP Authorization: Bearer … headers; email attachments encoded by MIME. Base64 is not encryption; it is purely a transport encoding. Anyone who has the encoded string can decode it trivially. Its only purpose is to make binary data safe to move through text-only systems.
Base64's + and / characters cause problems in URLs, filenames, and database keys, where those symbols carry special meaning. Base62 removes them, using only the 62 alphanumeric characters: 0–9, a–z, and A–Z. The trade-off is mild inefficiency: you need slightly more characters to represent the same data (log₂(62) ≈ 5.95 bits per character, versus 6 bits for Base64). Base62 is the basis of most URL shorteners (the random-looking paths after bit.ly/ are typically Base62-encoded integers), as well as many short unique identifier schemes where a compact, copy-pasteable, universally typeable string matters more than maximum encoding density.
In Andy Weir's 2021 novel Project Hail Mary,[19] the protagonist Ryland Grace encounters Rocky, an alien whose species evolved with six limbs. Just as humans arrived at base 10 through fingers, Rocky's people arrived at base 6 through their anatomy. When the two characters need a common mathematical language (neither speaks the other's tongue, and they share no common reference), they begin by tapping out rhythmic patterns and identifying a shared concept of counting. Base 6 becomes one of the first bridges between their minds, because mathematics is expected to be universal even when everything else differs.
Base 6 uses only the digits 0–5. The number we call "ten" is written as 14 in base 6 (1 × 6 + 4 = 10). The number 36 (six squared) is written as 100. Base 6 has a quiet mathematical virtue: 6 = 2 × 3, so it divides evenly by 2 and by 3, giving it more useful fractions than base 10 for the same number of digits. Weir's use of base 6 reflects a real proposal among SETI researchers: number systems and mathematics are likely universal concepts that any intelligence capable of building a radio telescope or spacecraft would have arrived at independently of biology, geography, or culture.
Base 7: Arrival and the Grammar of an Alien MindIn Ted Chiang's 1998 short story Story of Your Life[20] (and Denis Villeneuve's 2016 film Arrival[21]), the heptapods are seven-limbed beings whose written language is radically non-linear. Their numerical system is base 7, consistent with their seven-fold symmetry. Base 7 uses only the digits 0–6. The number we call "seven" is written as 10 in base 7 (1 × 7 + 0). Unlike base 6, base 7 is mathematically awkward: 7 is prime, so it has no useful divisors other than 1 and itself. Division and fractions that simplify cleanly in base 6 or base 10 do not simplify in base 7.
What makes Chiang's treatment striking is that base 7 is just one surface symptom of a fundamentally different relationship with time and causality. The story is explicitly about the Sapir-Whorf hypothesis, the idea that the language you use shapes how you perceive reality. The heptapods' numerical base, their non-sequential writing system, and their experience of time are all of a piece: not just a different convention for the same underlying reality, but a genuinely different cognitive architecture. Base 7 signals the reader that translation isn't merely a vocabulary problem.
How this converter works: from text to bytes to numbersEvery field in this converter is a different representation of the same underlying data: a sequence of bytes. When you type in the Text field, the browser encodes your characters as UTF-8, a byte encoding in which standard ASCII characters occupy one byte each and characters outside ASCII occupy two to four bytes. The letter H is byte value 72 (hexadecimal 0x48). The word "Hello" produces the five bytes [72, 101, 108, 108, 111].
For the numeric bases (binary, base 6, base 7, decimal, hexadecimal, Base62), those bytes are assembled into a single large integer in big-endian order (most significant byte first). "Hello" becomes: 72 × 256⁴ + 101 × 256³ + 108 × 256² + 108 × 256 + 111 = 310,939,249,775. That integer is then written out in whatever target base you select. Base64 is handled differently: rather than treating the data as one giant integer, it works in three-byte chunks; see the Base64 section above for why.
To convert to a base: repeatedly divide the integer by the base and collect the remainders. The first remainder is the rightmost digit; the last non-zero quotient becomes the leftmost digit. To convert back, multiply each digit by the base raised to the power of its position and sum the results. This converter uses JavaScript's built-in BigInt type for all base conversions, which handles integers of arbitrary size without the rounding errors that would corrupt values in regular floating-point arithmetic.
Leading zero bytes need special handling. If your byte sequence begins with 0x00 (common in cryptographic keys, padding, and some binary protocols), a naive BigInt conversion silently discards them, since leading zeros contribute nothing to an integer's value. This converter preserves them: it counts leading zero bytes before conversion, then prepends the corresponding number of zero-digit characters to the output. Reversing the process works symmetrically: leading zero characters in any numeric field map back to leading 0x00 bytes in the byte sequence.
Hash functions: related to base conversion, but fundamentally differentEvery base converter field above represents the same underlying data. Convert from any one to any other and you can always convert back; information is perfectly preserved. A cryptographic hash function breaks that rule deliberately. Given any input of any length, it produces a fixed-length output called a digest. The same input always produces the same digest. But the function is entirely one-way: you cannot reconstruct the input from the digest, and changing even a single bit of the input completely scrambles the output, a property called the avalanche effect.
Hash functions are defined by three security properties. Preimage resistance: given a digest, it must be computationally infeasible to find any input that produces it. Second preimage resistance: given a specific input, it must be infeasible to find a different input with the same digest. Collision resistance: it must be infeasible to find any two distinct inputs that produce the same digest. A function that fails any of these is considered cryptographically broken, even if it still works as a non-security checksum for detecting accidental corruption.
The hash fields below the converter are read-only outputs. They always reflect the current byte sequence, but you cannot type into them to work backwards; there is no backwards to speak of.
MD5: fast, well-known, and cryptographically brokenMD5 (Message Digest Algorithm 5) was designed by Ron Rivest in 1991.[7] It produces a 128-bit digest written as 32 lowercase hex digits. Like all Merkle-Damgård hash functions, it works by padding the input to a multiple of 512 bits, then processing one 512-bit chunk at a time. Each chunk updates a running 128-bit state, and the final state is the digest.
Each chunk drives 64 rounds of mixing across four 32-bit state variables (A, B, C, D). The 64 rounds are split into four groups of 16, each using a different nonlinear function, designed so that each function targets different bit-level relationships among the state variables:
F(b,c,d) = (b AND c) OR (NOT b AND d): selects c or d based on bG(b,c,d) = (b AND d) OR (c AND NOT d): selects b or c based on dH(b,c,d) = b XOR c XOR d: parity of all threeI(b,c,d) = c XOR (b OR NOT d): a final mixing functionEach of the 64 steps: take the current A, apply the round function plus one 32-bit word from the input chunk plus a per-step constant derived from the sine function (K[i] = ⌊2³² × |sin(i+1)|⌋), rotate left by a fixed shift amount, and add to B. Then rotate the state variables: B→A, C→B, D→C, and the new value → D. After all 64 steps, add the block's output back to its starting state. Repeat for every chunk.
MD5 was broken by Xiaoyun Wang and Hongbo Yu in 2004, who demonstrated practical collision attacks in under an hour.[8] By 2008, attackers had used MD5 collisions to forge fraudulent SSL certificates trusted by all browsers.[9] MD5 is cryptographically dead for any security purpose. It remains useful as a fast non-security checksum (verifying that a file wasn't accidentally corrupted in transit), because accidental corruption is not an adversarial attack.
SHA-256: the modern standardSHA-256 is part of the SHA-2 family, designed by the NSA and standardized by NIST in 2001 (published as FIPS 180-2, now FIPS 180-4).[10] It produces a 256-bit digest written as 64 hex digits. It also uses the Merkle-Damgård construction on 512-bit blocks, but with significantly more internal state and more complex mixing than MD5.
SHA-256 maintains eight 32-bit state variables per block (versus MD5's four) and runs 64 rounds using two more sophisticated auxiliary functions: Ch(e,f,g) = (e AND f) XOR (NOT e AND g), which chooses bits from f or g depending on each bit of e; and Maj(a,b,c) = (a AND b) XOR (a AND c) XOR (b AND c), which takes the majority bit. These are combined with four rotation-based diffusion functions (Σ₀, Σ₁, σ₀, σ₁), each XOR-ing together three different rotations of a word, ensuring that information from every bit position spreads into every other position over successive rounds.
SHA-256's 64 round constants are the first 32 bits of the fractional parts of the cube roots of the first 64 prime numbers. The eight initial state values are the first 32 bits of the fractional parts of the square roots of the first eight primes. These are nothing-up-my-sleeve numbers, generated by a public, deterministic process so that no designer could have secretly chosen constants that create hidden weaknesses. SHA-256 has been subjected to over two decades of intense cryptanalysis without a practical break. It is the backbone of TLS certificates, Git commit hashes, Bitcoin's proof-of-work, HMAC authentication, and most modern code signing systems. This page computes SHA-256 using crypto.subtle.digest(), the W3C Web Cryptography API,[18] running entirely in your browser with no external libraries or server calls.
Split a secret into n shares so that any k of them reconstruct it and any k−1 reveal nothing at all. Use it to survive a lost pad or key without trusting any single person or location.
The One-Time Pad section ends on an uncomfortable note: the cipher is invincible, but the pad is a physical object that can be lost, burned, or stolen. Storing one copy risks losing it; storing several copies multiplies the chance one is stolen. Secret sharing removes that trade-off. Adi Shamir published the scheme in 1979.[34]
You choose two numbers: n, how many shares to create, and k, how many are needed to rebuild the secret. Any k shares reconstruct it exactly. Any k−1 shares reveal nothing whatsoever — not a partial answer, not a narrowed range of guesses. A 3-of-5 split survives losing two shares while tolerating two being stolen.
How it works: a line needs two pointsTwo points determine a unique straight line. One point determines nothing: infinitely many lines pass through it. Shamir's scheme is that observation generalized.
To split a secret with a threshold of k, hide the secret as the constant term of a random polynomial of degree k−1, then hand out points on its curve. With k points you can reconstruct the polynomial (by Lagrange interpolation) and read off the constant term. With k−1 points, every possible secret still has exactly one curve passing through your points, so all of them remain equally likely.
That last property is the same information-theoretic security the one-time pad has.[1] It does not rest on any computation being hard, so no amount of computing power — quantum included — helps an attacker holding k−1 shares.
The arithmetic: GF(2⁸)The math runs in the finite field GF(2⁸), the same field AES uses, treating each byte as an element and processing the secret one byte at a time. A finite field is needed because ordinary arithmetic would leak: with real numbers, the slope of a line between two points constrains where it crosses the axis. In a finite field there is no ordering and no "close" — every wrong guess is as wrong as every other.
Addition is XOR. Multiplication is carry-less multiplication reduced modulo the irreducible polynomial x⁸ + x⁴ + x³ + x + 1 (0x11b). Coefficients come from crypto.getRandomValues(), fresh for every byte of every split.
Each share prints as x-hexdata, where x is the share's index (its x-coordinate, 1–255) and the hex is that share's byte for each byte of the secret. The index is not secret: it is required for reconstruction, which is why it travels in the clear alongside the data.
All traditional encryption has a fundamental problem: both people need to already share a secret key before they can communicate privately. But how do you share a key without a secure channel to share it over? For centuries, this had no good answer. Spies used physical dead drops. Diplomats used diplomatic pouches. Ordinary people just could not communicate privately with strangers at all.
Public-key cryptography, developed in the 1970s by Whitfield Diffie, Martin Hellman,[15] and separately by Rivest, Shamir, and Adleman,[16] solved this with a clever mathematical insight: build a lock that anyone can close but only one person can open. The lock is the public key. The key to open it is the private key. You publish your public key to the world. Anyone can use it to lock a message meant for you. Only you, holding the private key, can unlock it. No secure channel is needed to share the lock; the whole point is that the lock itself is safe to share openly.
The Math Behind RSA: The Factoring TrapdoorRSA security rests on a simple asymmetry in arithmetic: multiplying two numbers is easy; un-multiplying (factoring) is hard.
Take two prime numbers, say 61 and 53. Multiplying them together to get 3,233 takes an instant. But if someone hands you 3,233 and asks you to find the two primes that multiply to make it, you have to search. For small numbers, you can find the answer quickly. For very large numbers (hundreds of digits long), every known algorithm takes longer than the age of the universe, even on the fastest computers ever built.
RSA chooses two enormous secret prime numbers, multiplies them together to form the public modulus, then uses properties of modular arithmetic to construct a matched pair of mathematical operations. Encryption can only be done with the public key. Decryption can only be done by someone who knows the original two prime factors. Those factors are mathematically embedded in the private key. Anyone who could factor the public modulus could reconstruct the private key, but no classical computer can factor a number that large in practice. One important qualifier: in 1994, Peter Shor showed that a large, fault-tolerant quantum computer could factor such numbers efficiently.[22] No machine close to that capability exists today, but the implications are covered in the Post-Quantum Cryptography section below.
What "2048-bit" actually meansThe bit count refers to the size of the public modulus, the large number produced by multiplying the two secret primes. A 2048-bit number contains 2,048 binary digits. Written out in ordinary decimal, it would be about 617 digits long. The total number of possible 2048-bit RSA keys is staggeringly larger than the number of atoms in the observable universe (roughly 10⁸⁰). The best known classical factoring algorithms, run on every computer on Earth working in parallel, would still take far longer than the current age of the universe to crack a 2048-bit key.
RSA has two serious practical problems for encrypting real messages. First, it has a hard size limit: you can only encrypt data smaller than the public modulus. For a 2048-bit key with the OAEP padding this tool uses, that is 190 bytes (the 256-byte modulus minus 66 bytes of padding overhead), barely enough for a couple of sentences. Second, RSA is slow. The mathematical operations involved are thousands of times slower than the symmetric ciphers used inside your phone and browser every day.
The solution is called hybrid encryption, and it is used by HTTPS, Signal, PGP, SSH, and virtually every other secure communication system in existence. The idea is elegant:
RSA only ever touches 32 bytes: the session key. The actual message content never passes through RSA at all. The session key is generated fresh for every single message, so even if one were somehow compromised, no other message is affected.
What AES-256-GCM is and why it is usedAES (Advanced Encryption Standard) is the world's most widely deployed symmetric cipher. Standardized as FIPS 197 by NIST in 2001[11] following a rigorous public international competition, it has been analyzed intensively for over two decades and no practical weakness has been found. Every modern CPU (in phones, laptops, and servers) includes dedicated hardware instructions for AES, making it extraordinarily fast. On modern hardware, AES can encrypt data faster than the computer can read it from memory.
256 is the key size in bits. A 256-bit AES key has 2²⁵⁶ possible values, a number with 77 digits. Exhaustively trying every possible AES-256 key is not physically possible with any technology that exists or could ever exist within the laws of thermodynamics. Even a computer the size of a planet, running since the Big Bang, would not have made a dent. This margin holds even against quantum computers: Grover's algorithm, the best known quantum attack on symmetric ciphers, would reduce AES-256 to an effective 128 bits of security,[23] which is still far beyond any conceivable brute-force attack.
GCM (Galois/Counter Mode, standardized in NIST SP 800-38D[12]) is the mode that controls how AES is applied to the data. GCM does two jobs at once: it encrypts the data (providing confidentiality), and it computes a 128-bit authentication tag (providing integrity). The authentication tag is a cryptographic fingerprint of the entire encrypted message. If even a single byte of the encrypted output is changed, flipped, corrupted, or tampered with (by accident or by an attacker), decryption detects this and fails with an error. You cannot silently receive a modified message. This combined property is called authenticated encryption, and it is why GCM is preferred over older modes that only encrypted but did not detect tampering.
GCM also requires a unique initialization vector (IV), a fresh random 12-byte value, for every encryption operation. Even if you encrypt the same message twice with the same AES key, two different IVs produce two completely different encrypted outputs. An attacker watching the traffic cannot tell when the same message is being sent repeatedly. The IV is not secret and travels alongside the encrypted message.
OAEP Padding: Why Raw RSA Encryption Is Never UsedTextbook RSA encryption (no padding) has a fundamental weakness: it is deterministic. The same input always produces the same output. An attacker who suspects the plaintext is one of a small set of candidates (such as "yes" or "no") can encrypt each candidate with the public key and compare to the captured message. This instantly confirms which it was. Several additional mathematical attacks also work against unpadded RSA.
OAEP (Optimal Asymmetric Encryption Padding) fixes this by mixing random bytes into the input before RSA processes it. The same message encrypted twice produces two completely different RSA outputs, making the candidate-comparison attack impossible. OAEP has a formal security proof, meaning its security against certain attack models can be mathematically demonstrated rather than merely assumed. RSA-OAEP is the mandatory padding scheme for new RSA applications specified in PKCS#1 v2.2 (RFC 8017)[13] and is what NIST requires for compliant implementations. It is the minimum acceptable padding for RSA encryption. This tool uses RSA-OAEP throughout.
Digital Signatures: How RSA-PSS WorksA digital signature lets you prove two things about a message: that it came from you specifically, and that it has not been changed since you signed it. Think of it like a wax seal on a letter: only the person holding the signet ring (the private key) can make the seal, and breaking it to tamper with the letter is immediately obvious.
The signing process has three steps:
PSS (Probabilistic Signature Scheme) adds randomness to the signing process, similar to what OAEP does for encryption. Each signature of the same message looks different, preventing certain mathematical attacks possible against older padding schemes. PSS also has a formal security proof and is specified, alongside OAEP, in PKCS#1 v2.2 (RFC 8017).[13] This tool uses RSA-PSS for all signing operations.
Two Separate Key Pairs and Why They Must Not Be MixedClicking Generate Key Pair produces four PEM-formatted keys: an RSA-OAEP pair for encryption and decryption, and an RSA-PSS pair for signing and verification. These are kept separate deliberately. The mathematical operations for encryption and signing are different, and using the same key for both introduces a class of cross-protocol attacks where a valid signature can be misinterpreted as an encrypted blob (or vice versa), completely undermining security. Keeping the key pairs separate eliminates this entire category of attack.
The exact format of the encrypted outputWhen you encrypt a message, the tool produces a Base64-encoded package that contains, in this exact order:
Everything runs entirely in your browser via crypto.subtle, the W3C Web Cryptography API built into every modern browser. Keys are exported in standard interchange formats: public keys use SPKI encoding and private keys use PKCS#8, the same formats accepted by OpenSSL, Java, and every other standards-compliant cryptographic toolkit, making the keys portable beyond this page. No keys, messages, or signatures are ever sent to any server or leave this page in any form.
Encrypt any file to someone's public key using the same hybrid AES-256-GCM + RSA-OAEP scheme described above. The file never leaves your device: it is read into memory, encrypted, and offered back as a download.
Identical to the hybrid scheme in the RSA section, applied to raw bytes instead of text. A fresh AES-256 key encrypts the file; RSA-OAEP encrypts that key; both travel together. To encrypt, supply the recipient's public key. To decrypt, supply your private key — the tool detects which operation applies from the file itself.
Encrypted files are saved with a .enc extension and carry the original filename inside the encrypted payload, so decryption restores the correct name. The filename is inside the ciphertext, not alongside it: an interceptor cannot see what the file was called.
Byte layout, after a 4-byte OCF1 magic number that identifies the format and version:
GCM authenticates everything: a single altered byte makes decryption fail outright rather than silently returning corrupted data.
Practical limitsThe whole file is held in memory as it is encrypted, so this suits documents, keys, and archives rather than multi-gigabyte video. Files above roughly 100 MB may exhaust the browser tab's memory. There is no streaming mode, because crypto.subtle does not expose incremental AES-GCM.
File metadata beyond the name — size and modification time — is not hidden. Ciphertext length reveals approximate original length.
Elliptic-curve keys do the same jobs as RSA at a fraction of the size: a 32-byte Ed25519 key matches the strength of a 3072-bit RSA key. This is what SSH, Signal, TLS, and code signing actually use today. Signing here; for encryption see the RSA section, whose hybrid scheme applies identically to ECDH.
RSA and elliptic-curve cryptography solve the same problem with different hard math. RSA bets that factoring large numbers is slow. ECC bets on the elliptic curve discrete logarithm problem: given a point on a curve and the result of adding it to itself some secret number of times, recovering that number is infeasible.
The practical difference is size. The best known attack on RSA (the number field sieve) is sub-exponential, so RSA keys must grow quickly to stay ahead of it. The best known attack on a well-chosen curve is fully exponential, so ECC keys grow slowly. The result is a dramatic gap at equivalent strength:
A 32-byte key against RSA-3072's 384-byte modulus is a twelvefold reduction, and key generation is effectively instant where RSA-4096 takes seconds. That is why SSH keys, TLS certificates, Signal, and code signing all moved to curves.
The PEM blocks this tool produces are larger than those raw figures — 44 bytes for an Ed25519 public key — because SPKI wraps the key bytes in an ASN.1 structure identifying the algorithm. That overhead is what makes the key portable to OpenSSL and other tools.
Ed25519 versus the NIST curvesEd25519 (Bernstein, 2006[35]) is generally the better default. It is deterministic: the signature is derived from the message and key alone, with no per-signature random number. This matters, because ECDSA needs a unique random nonce for every signature and catastrophically leaks the private key if one is ever reused — the flaw that exposed Sony's PlayStation 3 signing key in 2010. Ed25519 removes the failure mode by construction. It also avoids several classes of implementation error by design, and its constants were chosen by a public, explained procedure.
The NIST curves P-256 and P-384 (FIPS 186-5[36]) remain correct and are often required for compliance, wider hardware support, or interoperability with older systems. Choose Ed25519 unless something specifically requires otherwise.
What this tool doesKeys are generated with crypto.subtle and exported as standard PEM (SPKI for public, PKCS#8 for private), so they interoperate with OpenSSL and other standard tooling. ECDSA signatures use SHA-256 (P-256) or SHA-384 (P-384); Ed25519 hashes internally with SHA-512 and takes no separate hash parameter.
Ed25519 is not yet available in every browser. If your browser lacks it, the option is disabled automatically and the NIST curves remain available.
The quantum caveatElliptic curves are not a hedge against quantum computing. Shor's algorithm breaks the discrete logarithm problem just as thoroughly as it breaks factoring,[22] and ECC's smaller keys mean a quantum attacker needs fewer qubits than for RSA. ECC is smaller and faster, not more quantum-resistant. See the Post-Quantum Cryptography section.
Every public-key system on this page (RSA encryption, RSA signatures) rests on a mathematical problem that is hard for ordinary computers: factoring enormous numbers. In 1994, Peter Shor showed that a sufficiently large quantum computer could solve that problem, and the related discrete logarithm problem, efficiently.[22] A machine that can run Shor's algorithm at scale breaks RSA, Diffie-Hellman, and elliptic-curve cryptography outright: not by trying keys faster, but by solving the underlying math directly.
No such machine exists today, and building one remains a formidable engineering problem. But the standards to replace RSA are already published, the replacements are already running in major browsers and messaging apps, and one tool on this page (the one-time pad) was never vulnerable in the first place. The details below explain what changes, what does not, and why the migration started decades before the threat becomes real.
Quantum computers are not simply faster computers. They are better than classical machines at a narrow set of problems with special mathematical structure, and it is bad luck for cryptography that integer factoring and discrete logarithms are on that list. Shor's algorithm solves both in polynomial time,[22] which turns the "longer than the age of the universe" security margin of RSA-2048 into hours of quantum computation, once a large enough machine exists.
Symmetric cryptography fares far better. The best known quantum attack on ciphers like AES and hash functions like SHA-256 is Grover's algorithm,[23] which speeds up brute-force search quadratically. In effect it halves the key length: AES-256 falls to roughly 128 bits of security against a quantum attacker, which is still completely out of reach. The same logic applies to a strong passphrase: quantum search can at most halve its effective entropy. Symmetric cryptography survives the quantum era with key sizes already in common use. Public-key cryptography built on factoring and discrete logarithms does not.
How close are real quantum computers?Running Shor's algorithm against a real 2048-bit RSA key requires a large fault-tolerant quantum computer: thousands of stable, error-corrected logical qubits, built from millions of noisy physical qubits. A widely cited 2021 analysis by Gidney and Ekerå estimated that factoring a 2048-bit RSA modulus would take about 8 hours on a hypothetical machine with 20 million noisy qubits.[28] Today's largest quantum processors have on the order of a thousand physical qubits and nowhere near the required error correction. The gap is enormous, but the trend matters: resource estimates have fallen steadily as quantum algorithms and error correction improve, and nobody can say with confidence when, or whether, a cryptographically relevant machine will arrive.
Harvest now, decrypt laterThe threat does not begin when the first big quantum computer boots up. Encrypted traffic can be recorded today, stored cheaply for decades, and decrypted whenever the capability arrives. This strategy is called harvest now, decrypt later, and it means the deadline for switching algorithms is set by how long your secrets must stay secret, not by when the machine is built. A message that must remain confidential for 20 years, sent under RSA today, is already at risk. This is the reason standards bodies began the migration years in advance: NIST's draft transition guidance deprecates RSA, ECDSA, EdDSA, and Diffie-Hellman after 2030 and disallows them entirely after 2035.[27]
The NIST post-quantum standardsIn 2016, NIST opened a public, worldwide competition to find replacement algorithms, receiving 69 complete candidate submissions. Over three rounds of open cryptanalysis, most candidates fell or were set aside; some were broken outright by classical attacks, including the isogeny-based scheme SIKE, which had survived to the fourth round before being cracked in 2022 using a single laptop core.[29] Breaks like that are the process working as intended: better to lose an algorithm in public review than after the world depends on it. The first three standards were published on August 13, 2024:
ML-KEM and ML-DSA are both lattice-based: their security rests on the difficulty of finding short vectors in high-dimensional module lattices, a problem believed hard for classical and quantum computers alike. Like RSA's reliance on factoring, this is a well-studied assumption rather than a proof; among ciphers, only the one-time pad has proven security. As a further hedge, NIST selected a fifth algorithm in March 2025: HQC, a code-based KEM whose security rests on yet another mathematical foundation.[32] The practical costs of the transition are modest but real: an ML-KEM-768 public key is 1,184 bytes versus 32 bytes for the elliptic-curve keys it replaces, and ML-DSA signatures run several kilobytes.
What is deployed todayReal deployments almost all use hybrid constructions: a classical key exchange and a post-quantum one are run together and their outputs are combined, so the connection is secure unless both are broken. This protects against a future quantum computer breaking the classical half, and against an undiscovered flaw in the much younger post-quantum half. Major browsers now negotiate a hybrid of X25519 elliptic-curve key exchange and ML-KEM-768 in TLS 1.3 with servers that support it,[33] so a growing share of everyday HTTPS traffic already has post-quantum protection for its session keys. Signal added a Kyber-based encapsulation step to its initial key agreement (PQXDH) in 2023,[30] and Apple's iMessage PQ3 protocol brought post-quantum protection with ongoing rekeying to iMessage in 2024.[31]
What this means for the tools on this page