Cryptography and Digital Security Technologies: Encryption, Hashes, Signatures and Mobile Security

Encryption hides data, while hashes, MACs, signatures, certificates and secure wireless links protect different properties. Confusing those properties leads to wrong exam answers and fragile systems. The same mobile payment can require link protection, end-to-end authentication, replay defence and secure endpoint keys, while RSA demonstrates one public-key operation. Map each threat to a property, primitive, key holder and verification step before choosing an algorithm.

1. Start with the security goal, not the algorithm name

Phone P1 sends PAY=2500|TO=RAVI|SEQ=1042 through wireless access point AP1 to server S1. Confidentiality hides it, integrity exposes alteration, origin authentication gives creator evidence, freshness rejects replays, and availability keeps the service usable. Non-repudiation also needs evidence and key custody, not merely a signature.

Without endpoint keys, M1 can listen, copy, modify, inject and replay. Judge controls against these actions.

2. Encryption, hashing, MACs and signatures solve different jobs

Shared-secret symmetric systems protect bulk data efficiently. Public/private pairs support key establishment, suitable encryption and signatures. Public keys still need identity binding.

Base64 and hexadecimal reversibly encode bytes. Compression removes redundancy, encryption uses a key, and hashing creates a fixed-length digest. Base64 of ciphertext is encoding, not extra encryption.

3. Why real systems combine symmetric and public-key cryptography

In a hybrid design, P1 authenticates S1's public-key identity and establishes fresh Ksession. Authenticated symmetric encryption protects bulk records. Without an authenticated exchange, M1 may intercept it.

Fresh session inputs are Nc = 0x7A31, Ns = 0xB204, SID = 1042 and first record PAY=2500|TO=RAVI|SEQ=1042. Transcript authentication must cover the nonces, session identifier and first-record context; the sequence value lets the server reject a replay.

Generate keys suitably, bind identities, limit scope and lifetime, protect storage, rotate or revoke, and erase obsolete secrets where supported. Algorithms cannot rescue exposed keys, predictable randomness or missed validation.

4. Worked RSA example: generate keys, encrypt 9 and recover it

Raw RSA with tiny primes is unsuitable for deployment; production implementations require large generated primes, approved padding or encoding, and vetted libraries.

Choose p = 11, q = 13. Then n = pq = 143 and phi(n) = (p - 1)(q - 1) = 10 x 12 = 120. Choose e = 7 as gcd(7, 120) = 1. Since 7 x 103 = 721 = 6 x 120 + 1, d = 103 and ed mod 120 = 1. Public key: (e, n) = (7, 143); private exponent: d = 103.

Encrypt m = 9 by repeated squaring:

• 9^2 mod 143 = 81.

• 9^4 mod 143 = 6561 mod 143 = 126.

• 9^7 mod 143 = 126 x 81 x 9 mod 143.

• 126 x 81 = 10206 mod 143 = 53, then 53 x 9 = 477 mod 143 = 48.

Thus c = 48. Audit both primes. 103 mod 10 = 3, so 48^103 mod 11 = 4^3 mod 11 = 9. 103 mod 12 = 7, so 48^103 mod 13 = 9^7 mod 13 = 9. The unique value modulo 143 with both residues is 9; hence m = c^d mod 143 = 9.

5. Hashes, MACs, signatures and passwords without category errors

A hash of update-v3.bin exposes change only if its expected digest is trusted. A MAC over PAY=2500|TO=RAVI|SEQ=1042 detects changes and authenticates origin within its shared-secret group. A signature is publicly verifiable but does not hide data.

Changing 2500 to 9500 breaks the MAC or signature. Replaying it unchanged may still verify, so S1 must remember accepted SEQ=1042, or apply another freshness rule. Authenticity is not freshness.

For passwords, store a unique salt and adaptive password-hash; verify by recomputation. Never store reversible plaintext or a fast general-purpose hash alone. Hashing and Collision Resolution covers hash-table collisions, not cryptographic collision resistance. They share a word, not a problem.

6. Mobile and wireless security needs protection at several layers

On P1 -> AP1 -> S1, wireless protection covers its radio hop, not the end-to-end application channel. That channel cannot fix stolen credentials, malware, an unlocked phone or an over-privileged app.

Wireless and transport protections cover different boundaries. TCP vs UDP: Transport Layer Explained separates delivery properties from cryptographic protection. Neither transport is inherently secure; end-to-end security depends on the protocol, endpoints, key validation and replay handling.

7. Cryptography traps that cost marks and break systems

RSA traps: using n = 143 instead of phi(n) = 120 for the inverse, choosing e not coprime to 120, skipping reductions, swapping (e, n) and d, or treating p = 11, q = 13 as realistic. Check 7 x 103 mod 120 = 1 and 9 -> 48 -> 9.

Also avoid trusting any public key, reusing uniqueness-required nonces, predictable randomness, one device-wide secret, assumed protection after AP1, and accepted replays. Apply identity validation, freshness, key scope and end-to-end threat modelling.

8. How questions test cryptography and the short next step

Exam-style tasks match goals to primitives, identify key holders, separate encoding from protection, calculate RSA, diagnose replay or choose layered controls. Three drills:

1. With phi=40, e=3 is possible because gcd(3,40)=1; e=10 is not.

2. A changed digest exposes a mismatch, but an unkeyed digest alone does not prove the sender.

3. A valid tag on a repeated SEQ=1042 still requires a freshness check.

Recall: threat, property, primitive, key holder, identity validation, freshness, endpoints. Use the cryptography questions in the practice bank to test each distinction, then return to any rule you cannot explain without looking.

Rebuild the table, reproduce n=143, phi=120, e=7, d=103 and 9 -> 48 -> 9, then explain why authenticity does not stop replayed SEQ=1042. Try NTA-UGC-NET Paper - 2 for structured study, the UGC NET Computer Science and Applications Test Series for practice, or the UGC NET Preparation Courses & Test Series for the catalogue.