Listen to this Post
Introduction:
Cryptography is not magic; it is deterministic mathematics that underpins every secure transaction, authentication, and data integrity check in modern IT. The famous narrative of Alice and Bob illustrates asymmetric encryption, hashing, and salting—core controls that prevent credential theft, man‑in‑the‑middle attacks, and data tampering. Understanding these primitives at a command‑line level allows engineers to move beyond theory and implement verifiable security controls across Linux, Windows, and cloud environments.
Learning Objectives:
- Differentiate between encoding, hashing, encryption, and salting using hands‑on command examples.
- Generate and manage asymmetric key pairs for secure file transfer and API authentication.
- Apply password hashing with salts in application configurations and database hardening.
- Simulate basic cryptographic attacks to understand real‑world exploitation paths.
You Should Know:
1. Hashing: Irreversible Integrity, Not Confidentiality
Hashing transforms arbitrary data into a fixed‑length digest. It is one‑way; you cannot “decrypt” a hash. This is used for password verification, file integrity, and digital signatures.
Step‑by‑step guide – Generating and verifying file hashes:
Linux (CLI):
Create a test file echo "Bob's secret" > secret.txt Generate SHA-256 hash sha256sum secret.txt Output: 2c74fd... secret.txt Verify integrity after transfer sha256sum -c <(echo "2c74fd... secret.txt")
Windows (PowerShell):
Generate SHA-256 hash Get-FileHash .\secret.txt -Algorithm SHA256 Output: 2C74FD... Verify later – recompute and compare manually
Application Context:
Storing passwords as raw SHA‑256 is still insecure without salting. Modern applications use adaptive functions like bcrypt, Argon2, or PBKDF2. Example configuration in a `.env` file:
PASSWORD_HASH_ALGO=bcrypt BCRYPT_ROUNDS=12
2. Salting: Defeating Rainbow Tables and Identical Passwords
Salting adds a unique, random string to each password before hashing. Even if two users choose “Love2024!”, their stored hashes will differ.
Step‑by‑step guide – Simulating salted hashes with OpenSSL:
Linux:
Generate a 16‑byte random salt (hex) salt=$(openssl rand -hex 16) echo "Salt: $salt" Hash password "ILoveAlice" with the salt echo -n "ILoveAlice$salt" | sha256sum
Windows (PowerShell):
Generate random salt
$salt = -join ((65..90) + (97..122) | Get-Random -Count 16 | % {[bash]$_})
$password = "ILoveAlice"
$salted = $password + $salt
Compute hash
$hashAlgo = [System.Security.Cryptography.SHA256]::Create()
$hashBytes = $hashAlgo.ComputeHash([System.Text.Encoding]::UTF8.GetBytes($salted))
$hashHex = [System.BitConverter]::ToString($hashBytes) -replace '-'
Write-Output "Salted Hash: $hashHex"
Database Hardening Tip:
Never write your own salt logic. Use library defaults. For MySQL 8.0, password hashing is automatic with caching_sha2_password. Verify:
SELECT plugin, authentication_string FROM mysql.user WHERE user='bob';
- Private Key: The Crown Jewel That Never Leaves
A private key must remain on the originating system, encrypted at rest, and accessible only to the owning process or user. Exposure equals total compromise.
Step‑by‑step guide – Creating and securing an RSA private key:
Linux (OpenSSL):
Generate 4096‑bit RSA private key openssl genrsa -aes256 -out bob_private.pem 4096 Protect file permissions chmod 600 bob_private.pem View key metadata (not the raw key) openssl rsa -in bob_private.pem -text -noout
Windows (PowerShell + OpenSSL or certreq):
Generate self‑signed certificate with private key (Windows native) $cert = New-SelfSignedCertificate -Subject "CN=Bob" -KeyAlgorithm RSA -KeyLength 4096 -KeyExportPolicy NonExportable -KeyProtection None Private key is stored in the machine store, marked non‑exportable
Cloud Hardening (AWS KMS):
Private keys for applications should never be hardcoded. Use a key management service:
aws kms create-key --description "Bob-Encryption-Key" --key-usage ENCRYPT_DECRYPT --origin AWS_KMS
4. Public Key: The Open Invitation
The public key is derived from the private key and can be freely distributed. It encrypts data that only the corresponding private key can decrypt.
Step‑by‑step guide – Extracting and using a public key:
Linux:
Extract public key from private key openssl rsa -in bob_private.pem -pubout -out bob_public.pem Alice encrypts a message for Bob echo "Meet at dawn" > message.txt openssl pkeyutl -encrypt -in message.txt -pubin -inkey bob_public.pem -out encrypted.enc Bob decrypts openssl pkeyutl -decrypt -in encrypted.enc -inkey bob_private.pem -out decrypted.txt
Windows (PowerShell):
No native RSA encryption tool exists; use .NET classes or third‑party tools like openssl.exe. For API security, public keys are embedded in JWT validation:
// C example for JWT validation
var validationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
IssuerSigningKey = new RsaSecurityKey(publicRsaParameters)
};
- Exploitation and Mitigation: When Bob’s Key Is Compromised
Attackers who obtain a private key can decrypt past sessions (if forward secrecy is absent) and impersonate the owner.
Simulating an attack and applying mitigation:
Linux – Capturing and decrypting TLS traffic (lab use only):
Export server private key (misconfiguration) Attacker captures pcap and uses Wireshark + private key to decrypt tshark -r capture.pcap -o "tls.keys_list:10.0.0.1,443,http,/path/bob_private.pem"
Mitigation – Perfect Forward Secrecy (PFS):
Enforce ciphers that use ephemeral Diffie‑Hellman (ECDHE). Test your server:
nmap --script ssl-enum-ciphers -p 443 example.com
Apache config:
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 SSLProtocol -all +TLSv1.2 +TLSv1.3
6. API Security: Cryptography in Transit
Modern APIs rely on asymmetric crypto for mutual TLS (mTLS) or JWT signing.
Step‑by‑step guide – Create mTLS certificates for service‑to‑service auth:
Linux (CFSSL or OpenSSL):
Generate CA openssl req -new -x509 -days 365 -keyout ca-key.pem -out ca.pem -subj "/CN=Internal-CA" Bob (server) cert openssl req -newkey rsa:2048 -nodes -keyout bob-server-key.pem -out bob-server.csr -subj "/CN=bob.internal" openssl x509 -req -in bob-server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out bob-server.pem -days 365 Alice (client) cert – same process Configure Nginx to require client cert
Vulnerability – Weak Key Generation:
Predictable random number generators break everything. Check for weak SSH host keys:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub Should show 2048 or 4096, not 1024
7. Cloud Hardening: Secrets Management
No private key should ever be copied into a Docker image or GitHub repository.
Step‑by‑step – Use HashiCorp Vault for dynamic secrets:
Enable transit engine vault secrets enable transit Create encryption key vault write -f transit/keys/bob-key Encrypt data via API vault write transit/encrypt/bob-key plaintext=$(base64 <<< "ILoveAlice") Decrypt vault write transit/decrypt/bob-key ciphertext=<returned-text>
Azure Key Vault equivalent:
$key = Add-AzKeyVaultKey -VaultName 'bobVault' -Name 'bobEncryptionKey' -Destination 'Software'
What Undercode Say:
- Key Takeaway 1: Cryptographic primitives are not optional; they are the only reliable method to enforce digital trust. Understanding the difference between hashing, salting, and asymmetric encryption at the command line eliminates cargo‑cult security.
- Key Takeaway 2: Key management is the single most critical control. A perfect algorithm is useless if a private key is stored in world‑readable plaintext or committed to source control.
Analysis: The Alice‑and‑Bob analogy endures because it strips away the complexity of implementations and exposes the pure logic of trust. Yet in practice, organisations fail not because they lack encryption, but because they mismanage keys, use outdated hashing algorithms, or ignore salting. The commands shown—from OpenSSL to Vault—are not academic; they are the daily toolkit for securing pipelines, databases, and APIs. Engineers must move beyond “it uses HTTPS” and verify cipher suites, key lengths, and storage mechanisms. The month of love is a reminder that digital relationships require the same care: mutual authentication, non‑repudiation, and secrecy.
Prediction:
The rise of quantum computing will force a migration from RSA and ECC to post‑quantum cryptography (PQC). In the next five years, we will see NIST‑standardised PQC algorithms replace traditional key exchanges. Organisations that today harden their cryptographic agility—by abstracting key algorithms and maintaining inventory of all crypto assets—will transition with minimal friction. Those still hardcoding RSA‑2048 will face a rupture of trust similar to the move from MD5 to SHA‑2. Alice and Bob will soon need new mathematics, but the protocol of trust they represent will remain unchanged.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Temitope Mustapha – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
