Lesson 3: Cryptography

·

In today's digital world, protecting sensitive data—especially financial information like credit card numbers—is more critical than ever. Cybercriminals are constantly seeking ways to intercept private data transmitted over networks, making encryption a fundamental component of secure communication. This lesson dives into the core principles of cryptography, focusing on how to safeguard credit card information using both symmetric and asymmetric encryption techniques in Java-based applications.

We'll explore a practical example that builds upon earlier lessons in user interface development, adapting it to securely transmit sensitive data. While actual source code is restricted due to U.S. export regulations on cryptographic software, we’ll walk through detailed pseudo code that demonstrates real-world implementation strategies.

Understanding Encryption Basics

Encryption is the process of converting readable plaintext—such as a credit card number—into unreadable ciphertext using a cryptographic key. Only authorized parties possessing the correct decryption key can revert the data back to its original form.

There are two primary types of encryption used together in modern security systems:

👉 Discover how secure encryption powers modern digital transactions today.

This hybrid approach combines speed and security: symmetric encryption protects the bulk data (like credit card numbers), while asymmetric encryption secures the transmission of the symmetric session key.

How the Example Works: Securing Credit Card Data

The application discussed here enhances a standard user interface by adding layers of cryptographic protection before transmitting sensitive data across the network.

When a user enters their credit card number and clicks "Purchase," the system performs the following steps:

  1. Generates a Session Key: A new symmetric key (e.g., DES key) is created each time the button is pressed. This ensures that even if one transaction is compromised, others remain secure.
  2. Encrypts the Credit Card Number: The session key encrypts the plaintext credit card number.
  3. Protects the Session Key: Since the session key must be sent to the server, it is itself encrypted using the recipient’s public key (asymmetric encryption).
  4. Transmits Encrypted Data: Both the encrypted credit card number and the encrypted session key are sent over the network.

Only the intended recipient—with access to the private key—can decrypt the session key and then use it to decrypt the credit card number.

This dual-layer method effectively mitigates risks associated with key interception and unauthorized decryption attempts.

Public and Private Key Generation

A critical part of asymmetric cryptography is generating and managing key pairs securely.

A separate utility program generates the public-private key pair using an asymmetric algorithm such as RSA. These keys are stored in separate files:

The server loads the public key and provides it to clients upon request. Trusted order-processing servers load the private key only when needed, minimizing exposure.

Proper key management is essential. Loss or theft of the private key compromises the entire system.

Pseudo Code Walkthrough

Although real source code cannot be shared due to export restrictions, let’s examine how the logic would be implemented using pseudo code.

Server-Side Interface

The server must support methods for:

Method: getPublicKey()
Method: sendEncryptedCreditCard(data)
Method: getEncryptedCreditCard()
Method: sendEncryptedSessionKey(key)
Method: getEncryptedSessionKey()

Client Encryption (RMIClient1)

private void encrypt(creditCardNumber) {
    Create DES cipher for symmetric encryption
    Generate new session key
    Initialize cipher with session key for encryption
    Encrypt creditCardNumber
    Retrieve server's public key
    Create RSA cipher for asymmetric encryption
    Initialize RSA cipher with public key
    Encrypt session key
    Send encrypted credit card + encrypted session key to server
}

Client Decryption (RMIClient2)

public String decrypt(encryptedKey, encryptedCard) {
    Load private key from secure file
    Create RSA cipher
    Initialize cipher with private key for decryption
    Decrypt session key
    Create DES cipher
    Initialize with decrypted session key
    Decrypt credit card number
    Return plaintext result
}

Why Sealing Isn’t Always Possible with RSA

An alternative method called sealing involves wrapping an object (like a session key) into a SealedObject, which serializes and encrypts it. However, this approach often fails with RSA due to size limitations.

RSA encryption follows the PKCS#1 standard with padding that requires 11 bytes of overhead. For example, a 512-bit RSA key can only encrypt up to 64 bytes minus 11 bytes = 53 bytes of data.

A typical session key may be just 8 bytes, but once serialized during sealing, it can grow to several thousand bytes—far exceeding RSA's capacity. Attempting this results in a javax.crypto.IllegalBlockSizeException.

Thus, direct encryption of small keys (without sealing) is preferred when using RSA.

👉 Learn how advanced encryption standards protect digital assets in finance and tech.

Setting Up Cryptographic Providers

For developers within the U.S. or Canada, Java Cryptography Extension (JCE) libraries can be installed:

  1. Download javax.crypto package and JAR file.
  2. Place it in your JRE’s lib/ext directory.

  3. Update java.security file to include:

    security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.crypto.provider.SunJCE
  4. Add an asymmetric algorithm provider (e.g., RSA) as security.provider.3=....

With these configurations, pseudo code can be translated into working source code.

Core Keywords

Frequently Asked Questions

What is symmetric vs asymmetric encryption?

Symmetric encryption uses one shared secret key for both encryption and decryption, offering speed but requiring secure key exchange. Asymmetric encryption uses a public-private key pair, enabling secure communication without prior key sharing, though slower in performance.

Why generate a new session key for each transaction?

Generating a unique session key per transaction limits damage if a single key is compromised. It ensures forward secrecy—past transactions remain secure even if future keys are exposed.

Can RSA encrypt any size of data?

No. RSA has strict size limits based on key length and padding. For example, a 512-bit RSA key can encrypt only up to 53 bytes after accounting for PKCS#1 padding. Larger data must be handled via hybrid encryption.

What happens if the private key is lost or stolen?

If stolen, attackers can decrypt intercepted communications. If lost, legitimate data may become irrecoverable. Hence, private keys must be stored securely and backed up under strict controls.

Is this method used in real-world applications?

Yes. This hybrid model is foundational in SSL/TLS protocols, online banking, e-commerce platforms, and blockchain technologies where secure data transmission is paramount.

Why can’t we use sealing with RSA?

Sealing involves serializing objects before encryption, significantly increasing their size. Due to RSA’s small payload capacity, sealed objects often exceed allowable limits, triggering runtime exceptions.

👉 See how cutting-edge platforms implement these cryptographic principles at scale.

By combining symmetric efficiency with asymmetric security, developers can build robust systems that protect user data in transit. Understanding these fundamentals not only strengthens application design but also aligns with global best practices in cybersecurity and data privacy.