The RSA Share Project

If you build software today, you are also building security whether you want to or not. Games store player identities, manage digital currencies, process payments, and operate persistent online worlds. Web apps store private user data. Mobile apps talk to cloud APIs. All of this depends on one simple assumption: the communication between systems can be trusted. That trust usually comes from cryptography. One of the most influential cryptographic systems ever created is RSA cryptosystem, developed in the late 1970s and still widely used today. In 2009, the company RSA Security launched an interesting initiative called the RSA Share Project. The goal was simple but ambitious: give developers free access to enterprise-grade encryption tools and encourage them to build security directly into their software. For developers and game studios, this was a big deal. It meant the same cryptographic tools used by banks, governments, and large enterprises were suddenly available to anyone writing code. Let’s look at how this happened.

The origins of RSA: From academic theory to industry standard

The story starts in 1977 at MIT. Three researchers, Ron Rivest, Adi Shamir, and Leonard Adleman, published a breakthrough cryptographic method that solved a major problem in computer security: how to exchange secrets over an insecure network. Their solution became known as the RSA cryptosystem, named after the initials of the three inventors. In 1982, they founded RSA Security to commercialize the technology. Over the following decades the company built encryption libraries and authentication technologies used across the internet. RSA technology eventually ended up everywhere:

web browsers
routers
enterprise software
financial systems
gaming platforms

By the early 2000s, RSA’s BSAFE cryptographic toolkit had become a widely used building block for secure software.

What RSA actually is: A quick technical explanation

At its core, RSA is a public-key cryptography system. Instead of using one shared secret key, RSA uses two keys:

public key → used for encryption
private key → used for decryption

The public key can be shared with anyone. The private key stays secret. In simplified terms:

A user publishes their public key.
Another system encrypts data with that public key.
Only the owner of the private key can decrypt it.

The security comes from a mathematical property: factoring very large numbers into prime factors is computationally extremely difficult. Developers rarely implement RSA themselves. Instead they rely on tested libraries that provide:

encryption
digital signatures
certificate validation
secure random number generation

This is exactly where RSA’s BSAFE toolkit came in.

The cybersecurity landscape around 2009

Around 2009 the internet was changing fast. Cloud computing was starting to grow. Virtualization was becoming common. Web services were replacing monolithic software systems. At the same time, cyber attacks were increasing dramatically. Malware, botnets, and credential theft were becoming everyday threats. During the RSA Conference in 2009, RSA executives described the situation as a “pandemic increase” in cyber attacks. The problem was not only the attacks themselves. It was the architecture of software. For many companies security was still something that was added later:

Build the application
Launch it
Patch security holes afterwards

This approach clearly wasn’t working anymore. This is where the RSA Share Project came in. In 2009, RSA Security announced that parts of its BSAFE cryptographic toolkit would be made available for free to developers. Instead of selling the library exclusively to enterprise customers, the company released a “Share” version of the toolkit. Developers could download SDKs and integrate strong encryption directly into their applications. The project focused on a few core ideas:

make enterprise cryptography accessible
encourage security-first architecture
build a developer community around security tools

This shift was important because it lowered the barrier to using professional cryptography.

The bsafe toolkit and the sdk architecture

The RSA Share Project distributed the BSAFE Share SDK in two main development environments:

C / C++
Java

This covered the majority of enterprise and server software at the time. The toolkit provided several core features developers needed: Encryption Secure data transmission between clients and servers. Digital signatures Verify that messages or files were not modified. Authentication support Enable identity verification systems. Protocol support Integrate encryption into existing communication standards. One of the most important aspects was compatibility. Many existing systems already used BSAFE internally. By using the same toolkit, new applications could communicate securely with those systems.

The $10,000 developer challenge

To encourage experimentation, RSA launched a developer competition. The challenge was simple: build a creative web application using the BSAFE Share toolkit. The prize? $10,000 for the most interesting and practical implementation. This might sound small by today’s startup standards, but the real goal wasn’t the prize money. It was about attracting developers into the ecosystem and discovering new ways encryption could be used in modern applications. The RSA Share Project represented a philosophical shift. Traditionally, high-grade security tools were:

expensive
licensed
restricted to enterprise customers

The Share Project treated cryptography more like an open infrastructure layer. Instead of hiding security inside enterprise products, RSA encouraged developers to embed it directly in their code. For many developers this was their first exposure to professional cryptographic libraries.

How game developers and studios could use RSA

Game developers might not immediately think about cryptography, but modern games depend heavily on secure systems. Here are a few ways RSA-style encryption can be useful.

Secure player authentication

Online games need secure login systems. RSA can help protect:

password exchange
authentication tokens
session keys

This reduces the risk of account theft.

Protecting in-game economies

Games with trading systems or digital currencies must prevent manipulation. Cryptographic signatures can help verify:

transactions
marketplace activity
item ownership

Anti-Cheat and client verification

Many cheats involve modifying client data. Digital signatures can help verify that:

the game client is legitimate
updates are authentic
files are not modified

Secure server communication

Multiplayer games constantly exchange data between client and server. Encryption ensures that:

data packets cannot be intercepted
player actions cannot be spoofed
session data remains private

Protecting game assets

Studios may also want to protect intellectual property:

game updates
downloadable content
server binaries

Digital signatures allow systems to verify that software comes from a trusted source.

Challenges and controversies around rsa and bsafe

Not everything in the RSA story is positive. Years after the Share Project launched, researchers discovered that a pseudorandom number generator used in BSAFE called Dual_EC_DRBG might contain a backdoor. This algorithm had been standardized by National Institute of Standards and Technology but was later suspected of being influenced by the National Security Agency. The controversy damaged the reputation of RSA Security and sparked widespread debate about trust in cryptographic standards. It also reinforced an important lesson for developers: cryptography must always be transparent and peer-reviewed. Even though the Share Project itself was a short-lived initiative, its philosophy had lasting impact. The idea that security should be built into software from the start is now standard practice. Modern developers rely on:

open cryptographic libraries
community security tools
built-in platform security features

The Share Project helped push the industry toward this mindset.

Lessons for modern developers and studios

For developers today, the biggest lessons are still relevant. 1. security should be architecture, not a feature If you add security later, you already lost. 2. use trusted cryptographic libraries Never implement your own encryption unless you are a cryptographer. 3. design for hostile environments Assume attackers can inspect clients, intercept traffic, and modify data. 4. build secure ecosystems Security is not just about algorithms. It’s about how systems interact.

Conclusion: Democratizing security foundations

The RSA Share Project was an early attempt to democratize cryptographic infrastructure. By making enterprise encryption tools accessible to developers, RSA Security encouraged a generation of engineers to think about security earlier in the development process. For game developers and software engineers alike, the message still holds: the most secure systems are not the ones with the most patches, but the ones designed with security at their core. Cryptography is not just a security feature. It is part of the foundation of modern software. And the earlier you start using it, the better your systems will be.