Skip to main content
DataRidge
Category: Cryptography and Encryption

RSA

Also known as: RSA, Rivest–Shamir–Adleman, RSA cryptosystem, RSA algorithm
Simply put

RSA is a widely used public-key cryptography method named after its inventors, Ron Rivest, Adi Shamir, and Leonard Adleman. It uses a pair of mathematically related keys, one public and one private, so that data can be protected or digitally signed without both parties sharing a single secret key in advance. It is one of the oldest public-key systems and remains common in identity and security systems, though this entry does not address key length recommendations, implementation weaknesses, or migration to post-quantum alternatives.

Formal definition

RSA is an asymmetric (public-key) cryptosystem whose security rests on the presumed computational difficulty of factoring large integers. It supports key establishment (secure key exchange) and the generation and verification of digital signatures, and can be applied to encryption of data. Operationally, RSA distinguishes a public key (used for encryption or signature verification) from a private key (used for decryption or signature generation), and this key separation determines which party performs which function. This definition is scoped to the algorithm's role and mathematical basis as described in the cited sources; it does not cover parameter selection, padding schemes, side-channel or implementation vulnerabilities, or comparative strength against other algorithms.

Why it matters

RSA is one of the oldest and most widely deployed public-key cryptosystems, and it underpins many of the identity and security systems that data protection and governance professionals rely on. Because it enables two parties to protect data or verify digital signatures without first sharing a single secret key, it plays a foundational role in secure data transmission, secure key exchange, and the authentication mechanisms embedded in everyday security infrastructure. Understanding what RSA does, and does not, do is important when reasoning about how personal data is safeguarded in transit and how the integrity and authenticity of communications are established.

For practitioners, RSA typically appears as one technical control among many rather than a standalone assurance of compliance. Its use as an encryption or signature mechanism can support security obligations, but the presence of RSA alone does not determine whether processing is lawful, whether data remains personal, or whether accountability requirements are met. In particular, applying encryption to personal data does not by itself render that data non-personal, and governance teams should treat cryptographic controls as part of a broader control set rather than a substitute for policy, lawful basis, or demonstrable accountability.

This entry is scoped to RSA's role and mathematical basis as described in the cited sources. It does not address key length recommendations, parameter selection, padding schemes, side-channel or other implementation vulnerabilities, comparative strength against other algorithms, or migration to post-quantum alternatives. Decisions about the adequacy of RSA in any specific deployment depend on context, implementation, and current guidance beyond the scope of this definition.

Who it's relevant to

Privacy engineers
Privacy engineers implementing controls that protect personal data in transit or that establish authenticity of communications may encounter RSA in key exchange and digital signature workflows. They should treat it as one component of a broader control set and note that encryption alone does not make personal data non-personal.
Security professionals
Those responsible for confidentiality, integrity, and availability controls use public-key algorithms such as RSA for secure key exchange and signature verification across identity and security systems. This entry does not address key length, implementation weaknesses, or comparative algorithm strength, which are typically central to their design decisions.
Data protection officers and compliance officers
DPOs and compliance officers should understand RSA at a conceptual level when assessing whether technical security measures are in place, while recognizing that a cryptographic control supports but does not by itself demonstrate compliance or accountability, which generally require documented, demonstrable evidence.
Information governance leads
Governance leads cataloging systems and policies may reference cryptographic controls like RSA in their control inventories. Governance concerns, ownership, stewardship, and policy, remain distinct from the security function of the algorithm itself, even where the two overlap.

Inside RSA

Asymmetric key pair
RSA operates on a mathematically linked pair consisting of a public key, which may be distributed openly, and a private key, which must remain confidential to its holder. Data encrypted with one key of the pair is decryptable only with the other.
Public-key encryption
RSA can be used to encrypt data using a recipient's public key so that only the holder of the corresponding private key can decrypt it. In practice, RSA is often used to protect a symmetric session key rather than bulk data, given performance characteristics.
Digital signature capability
RSA supports signing operations in which a private key produces a signature that any party with the public key can verify, generally supporting integrity and origin authentication of the signed content.
Key length and parameters
The security posture of an RSA deployment depends on chosen key length and configuration. Larger key sizes generally offer stronger resistance to attack, subject to prevailing cryptographic guidance and implementation choices.
Role within security controls
RSA is a technical mechanism supporting the confidentiality, integrity, and authentication objectives of information security. It is an implementation detail of a control, not itself a governance policy, and its use should be documented within broader security and governance frameworks.

Common questions

Answers to the questions practitioners most commonly ask about RSA.

Does encrypting personal data with RSA mean the data is no longer personal data?
No. Encryption, including RSA, is a security control that protects confidentiality, but it does not remove data from scope. In most jurisdictions, and generally under the EU GDPR and UK GDPR, encrypted personal data remains personal data because the party holding or able to obtain the decryption key can still re-identify individuals. Encryption is more accurately treated as a form of pseudonymization or a protective measure rather than anonymization. Only irreversible anonymization typically takes data out of regulatory scope, and RSA encryption is by design reversible for authorized key holders. This entry does not address whether any specific implementation would satisfy a given regulator's expectations.
Is RSA a data governance measure or an information security measure?
RSA is an information security mechanism, supporting confidentiality and, through digital signatures, integrity and authenticity. It is not itself a data governance measure. Data governance concerns ownership, stewardship, data quality, lineage, catalogs, and policy. The two areas overlap where governance policy specifies that certain data classes must be protected using cryptographic controls, but deploying RSA does not by itself establish stewardship, lineage, or accountability. Keeping the distinction clear helps avoid treating a technical control as evidence of governance maturity.
Where does RSA typically fit in an organization's use of cryptography?
RSA is an asymmetric (public-key) algorithm, so it is generally used for tasks suited to key pairs, such as establishing or exchanging keys, and for digital signatures. In many implementations, symmetric algorithms handle bulk data encryption for performance reasons, while RSA is used to protect or exchange the symmetric keys. The appropriate role for RSA depends on the specific architecture, threat model, and applicable standards, which are outside the scope of this entry.
How does the choice of RSA key size relate to protecting personal data?
Key size affects the strength of the protection RSA provides, and guidance on acceptable sizes evolves as computing capability and cryptanalysis advance. Because recommendations change over time, organizations generally align key sizes with current recognized cryptographic guidance rather than a fixed value, and revisit those choices periodically. This entry does not specify particular key lengths, migration timelines, or the point at which a given size should be considered deprecated; consult current authoritative cryptographic standards for those figures.
Can using RSA be cited as evidence of accountability or compliance?
Not on its own. Accountability under governance and data protection frameworks generally requires demonstrable evidence, such as documented policies, records of how controls are applied, and justification for the measures chosen, rather than the mere presence of a technology. RSA may form part of the technical and organizational measures an organization can point to, but whether those measures are appropriate depends on context, the data involved, and the applicable regime. This entry does not assert that any control guarantees compliance.
What operational practices matter when relying on RSA to protect data?
Key management is typically central: how private keys are generated, stored, access-controlled, rotated, and retired materially affects whether the protection is meaningful, since a compromised or poorly protected private key can undermine the control. Organizations generally also consider how RSA fits within their broader cryptographic strategy and how it will be maintained as guidance evolves. Detailed key lifecycle procedures, cross-border transfer implications, and retention rules are outside the scope of this entry.

Common misconceptions

Encrypting personal data with RSA makes the data no longer personal data.
Encryption, including RSA, is a security measure that reduces risk but does not by itself render data non-personal. Where the data can be restored to identifiable form by a party holding the corresponding key, it generally remains personal data and continues to fall within applicable data protection obligations. This treatment is consistent with the distinction between pseudonymization (reversible, still personal data) and anonymization (irreversible).
Using RSA guarantees compliance with data protection or security requirements.
No single cryptographic algorithm or control guarantees compliance. Compliance depends on context, jurisdiction, implementation, key management practices, and the overall control environment. RSA can support technical and organizational measures but must be assessed and evidenced as part of a wider program.
The RSA public and private keys are interchangeable and equally sensitive.
The keys serve distinct roles. The public key is intended for open distribution, while the private key must be protected from disclosure. Compromise or poor management of the private key undermines the security properties the algorithm is intended to provide.

Best practices

Select key lengths and configurations in line with current recognized cryptographic guidance rather than legacy defaults, and revisit these choices periodically as guidance evolves.
Protect private keys through robust key management, including controlled storage, restricted access, and defined lifecycle procedures for generation, rotation, and revocation.
Do not rely on RSA encryption alone to remove personal data from regulatory scope; document whether the data remains reversible to identifiable form and treat it accordingly.
Use RSA appropriately for its intended functions, such as protecting symmetric session keys or producing digital signatures, rather than for bulk data encryption where performance and design considerations apply.
Record the use of RSA and associated key management within security documentation so that the control can be demonstrated as evidence, consistent with accountability expectations under governance frameworks.
Coordinate cryptographic decisions between information security and data governance functions so that the mechanism supports, and is reflected in, documented policy and control objectives.