KEVOS
ArticlesServicesCase studiesAboutContact
ArticlesServicesCase studiesAboutContact
← ArticlesThe RSA CryptosystemEngineering · Engineering MathematicsLesson 593/883← PrevNext →
GuidePublished 7 Aug 2026Updated 13 Aug 20268 min readBy Kevin Jogin
On this page

Ask about this page

KEVOS AIThe RSA Cryptosystem

KEVOS knowledge first · trusted web sources when needed

Engineering  /  Mathematics  — Probabilistic Algorithms

The RSA Cryptosystem

RSA key generation, encryption, decryption and correctness, together with the assumptions its security depends on.

Page KV-MATH-0365Reading time 4 minReviewed 2026-08-07Author Kevin Jogin

Executive summary

RSA is the archetypal public-key cryptosystem. Its correctness is Euler's theorem and its security rests on the difficulty of factoring, though the two are not known to be equivalent.

The textbook description is a mathematical core that is not by itself a secure encryption scheme, and the gap between the two is where most real failures occur.

Learning objectives

  1. State the key generation, encryption and decryption procedures.
  2. Prove correctness from Euler's theorem.
  3. Distinguish textbook RSA from a deployable scheme.

01The scheme

  1. Key generation

    Choose distinct primes p and q of the target size; set n = pq and compute φ(n) = (p−1)(q−1). Choose e coprime to φ(n) and compute d with ed ≡ 1 mod φ(n).

  2. Public key

    The pair (n, e), published freely.

  3. Private key

    The exponent d, together with p and q for the Chinese remainder speedup.

  4. Encrypt

    c = m^e mod n.

  5. Decrypt

    m = c^d mod n.

Theorem

Correctness

(m^e)^d = m^{ed} = m^{1 + kφ(n)} = m · (m^{φ(n)})^k ≡ m (mod n) by Euler's theorem when gcd(m, n) = 1.

The identity also holds when m shares a factor with n, verified separately modulo p and q and combined by the Chinese remainder theorem.

02What the security rests on

Equivalences around the RSA private key
QuantityConsequence if recoverable
The factorisation of nφ(n) follows, then d; complete break
φ(n)Yields the factorisation via a quadratic; complete break
dYields the factorisation by a randomised algorithm; complete break
A single plaintextThat message only; no key compromise

The first three are computationally equivalent, so knowing any one of them is as good as knowing all. What is not established is the converse direction: breaking RSA encryption for a single ciphertext has never been proved to require factoring, and the RSA problem could in principle be easier.

Caution
This gap is real and worth stating precisely. RSA's security assumes the RSA problem is hard; factoring being hard is necessary for that but has not been proved sufficient.

03Textbook RSA is not an encryption scheme

Caution
The construction above is deterministic, so identical plaintexts produce identical ciphertexts. That alone disqualifies it: an adversary who suspects a message can verify the guess by encrypting it under the public key.
  • Deterministic. No semantic security. Small message spaces are exhaustively searchable.
  • Malleable. Multiplying a ciphertext by r^e multiplies the plaintext by r, permitting meaningful modification without the key.
  • Small exponent weakness. With small e and a short unpadded message, m^e may be below n, so the plaintext is recovered by an integer root with no modular arithmetic at all.
  • Fault sensitivity. With the Chinese remainder speedup, a computational fault in one half exposes a factor of the modulus by a single gcd.

Deployable schemes use randomised padding — OAEP for encryption, PSS for signatures — which removes determinism and malleability and carries a security proof relative to the underlying assumption. Every one of the weaknesses above has appeared in a deployed system.

04Frequently asked questions

Why is e = 65537 the usual choice?

It is prime, so the coprimality check against φ(n) rarely fails, and its binary form has only two set bits, making encryption fast. It is also large enough to avoid the small-exponent attacks that afflict e = 3 with inadequate padding.

Can the same modulus serve several users?

No. Any holder of a valid private exponent for that modulus can factor it and derive everyone else's private key. Each user needs an independently generated modulus.

Is RSA obsolete?

Not yet, but it is being displaced. Elliptic curve systems give equivalent security at far smaller key sizes, and both fall to a sufficiently large quantum computer, which is what motivates post-quantum schemes.

Related pages

  • Euler's Phi Function
  • Factoring and Computing Euler's Phi Function
  • Subexponential Integer Factoring
  • Generating a Random Factored Number

Sources and method

Structural reference: Victor Shoup, A Computational Introduction to Number Theory and Algebra, Version 1, Cambridge University Press, 2005 — book pages 174-179.

This page carries the durable method layer only: definitions, constructions, algorithms, complexity results and selection criteria, authored originally for KEVOS. No text is transcribed or paraphrased from the source, and no numeric tables or benchmark data are reproduced — these are routed to live authoritative sources instead.

Author: Kevin Jogin. Last reviewed 2026-08-07.

Handbook application: from concept to controlled practice

Purpose. This expanded section turns the original page into a practical handbook. It preserves the supplied material and adds a repeatable way to apply, check and review The RSA Cryptosystem. It does not replace a contract, legislation, a controlled standard, competent engineering judgement or specialist advice.

The operating aim is to turn a compact mathematical statement into a usable chain of definitions, claims, examples and checks. Read the original explanation first, then use the workflow and checks below to convert knowledge into evidence.

Treat The RSA Cryptosystem as a network of definitions and implications, not as a list of formulas. The working vocabulary on this page—encryption, security, scheme, cryptosystem, generation—should be made explicit before any proof or computation begins. Record the ambient set or structure, the permitted operations and the equality or equivalence relation in use. A compact theorem often changes meaning when the base field, finiteness condition, commutativity assumption or direction of an action changes.

For a proof, write the hypotheses as a checklist and mark the line at which each one is used. For a computation, state the representation of the input, the arithmetic model, the termination condition and the output invariant. For a classification problem, distinguish existence from uniqueness and distinguish an object from its representation. These separations prevent a correct local calculation from being mistaken for the general result.

A useful worked example should be small enough to inspect completely but rich enough to exercise the main mechanism. Compute the result in two ways where practical: symbolically and by substitution, structurally and numerically, or directly and through a normal form. Then include one near-miss example in which a hypothesis fails. The contrast explains why the theorem is shaped as it is and gives the reader a diagnostic pattern for later problems.

Verification is part of the mathematics. Check domains and codomains, substitute proposed solutions, test identity and zero cases, compare dimensions or cardinalities, and confirm that maps respect the required operations. In numerical work, report precision, conditioning and a residual rather than digits alone. In algorithmic work, separate mathematical correctness from implementation complexity and resource limits.

Step-by-step operating method

  1. Fix the setting. State the objects, ambient structure, notation and assumptions before manipulating symbols.
  2. Separate claims. Distinguish definitions, hypotheses, conclusions, equivalent conditions and consequences.
  3. Choose a method. Select proof, construction, calculation or algorithm according to the question actually asked.
  4. Work a small case. Use the smallest non-trivial example to expose the mechanism and test edge behaviour.
  5. Verify independently. Substitute back, check invariants, test boundary cases or use an alternative derivation.

Worked-example protocol

Illustrative method—not a source theorem. Start with a small admissible input and list the definitions it must satisfy. Carry out each transformation on a separate line, citing the property that permits it. Preserve exact values until approximation is necessary. At the end, verify the output against the original definition and one invariant such as dimension, degree, determinant, order, norm or residual. Then alter one hypothesis and observe which step ceases to be valid. This protocol creates a reusable example without inventing a theorem-specific numerical answer.

StageRecordQuality check
InputObjects, domain, notation, assumptionsEvery symbol is defined
MethodPermitted operation or cited result at each stepAll hypotheses hold
OutputExact result and representationCorrect type, domain and form
VerificationSubstitution, invariant or alternative derivationIndependent agreement
Boundary testZero, identity, degenerate or failed hypothesisScope is understood

Common failure modes and recovery actions

1. Watch for

Using a theorem without checking every hypothesis.

Recovery: Return to the governing definition or requirement and restate the decision in one sentence.

2. Watch for

Treating a suggestive example as a proof of the general case.

Recovery: Separate evidence from assumption, assign an owner and set a date for validation.

3. Watch for

Changing notation or conventions part-way through an argument.

Recovery: Run a small counterexample, boundary test, pilot or independent check before proceeding.

4. Watch for

Hiding a division-by-zero, convergence, finiteness or commutativity assumption.

Recovery: Record the consequence, decision and rationale, then update the controlled baseline.

5. Watch for

Reporting a computed result without a residual, substitution or structural check.

Recovery: Escalate when the issue affects safety, compliance, acceptance, material value or an agreed tolerance.

Review checklist

  • Can every symbol be traced to a definition or prior result?
  • Which hypothesis does each major step use?
  • Does the method cover zero, identity, degenerate and boundary cases?
  • Can the conclusion be checked by a second representation or calculation?
  • Are mandatory requirements distinguished from recommendations and illustrative values?
  • Are sources, assumptions, units, dates and versions recorded closely enough to reproduce the decision?
  • Have safety, legal, ethical, stakeholder and operational consequences been considered at the appropriate level?
  • Is there a named owner and a trigger for review, escalation, change or retirement?

Questions for deeper application

What is the most important distinction a practitioner must preserve when applying The RSA Cryptosystem?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which assumption about encryption would change the result most if it proved false?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What evidence would allow an independent reviewer to reproduce or challenge the conclusion?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Which boundary, exception or failure case has not yet been tested?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

What must be handed over, monitored or reviewed after the immediate work is complete?

Answer with a fact or cited source where available. Where evidence is incomplete, record the assumption, consequence, responsible owner and next validation action.

Authoritative references and use notes

The sources below were selected as institutional or primary guidance for the broader practice. They support the handbook method; they do not imply that every statement or clause in a source applies to every project. Confirm the current edition, jurisdiction, contract and application before treating any requirement as mandatory.

  • MIT OpenCourseWare — Algebra I — Massachusetts Institute of Technology. Used for groups, vector spaces, linear transformations and linear groups. Accessed 2026-08-13.
  • The Stacks Project — table of contents — The Stacks Project. Used for commutative algebra, homological algebra, modules and derived categories. Accessed 2026-08-13.

Continue learning

Generating a Random Factored NumberGuide · Engineering MathematicsNEXT LESSON →Abelian Groups: Definitions, Properties and ExamplesGuide · Engineering MathematicsGenerating a Random Non-Increasing SequenceGuide · Engineering MathematicsThe Order of a Group ElementGuide · Engineering Mathematics
KEVOS · Engineering, manufacturing and project improvement
ArticlesServicesCase studiesAboutContact
© 2026 KEVOS®