tanvir-mahamood/security-and-privacy

1. Repository shape

- This is an educational, algorithm-by-algorithm cryptography repo rather than a single integrated application.

- Each algorithm lives in its own top-level folder and is mostly self-contained, with no shared runtime package or common service layer.

2. Primary architectural boundary: per-algorithm sandboxes

- The main boundary is the directory per algorithm: CryptoBasics, DES, Triple DES, AES, RSA, Diffie-Hellman, Man in the Middle Attack, SHA1, and Digital Signature variants.

- Each sandbox has its own script entrypoint and its own text files, so data does not appear to flow across algorithm folders.

3. Common execution model

- Most cryptography modules use encription_main.py as the entry script.

- SHA1 uses main.py, and the signature demos use main.py plus helper modules.

- The repo is organized around running a script, reading an input text file, producing an output file, and then optionally writing a decrypted or verified result back to another file.

4. File-based data flow

- The standard pattern is:

- sender-side plaintext input

- ciphertext output

- receiver-side plaintext output

- This pattern appears repeatedly in plaintext_sender.txt, ciphertext.txt, and plaintext_receiver.txt.

- The file system is the main integration point, not APIs, network sockets, or databases.

5. Classical cryptography subsystem

- CryptoBasics contains the simpler instructional ciphers: Caesar, monoalphabetic substitution, and columnar transposition.

- This module is likely the entry point for demonstrating reversible text transformations before moving to modern encryption schemes.

- Its outputs follow the same sender/ciphertext/receiver file loop as the other symmetric encryption demos.

6. Symmetric encryption subsystem

- DES Data Encryption Standard, Triple DES, and AES Advanced Encryption Standard form a symmetric-key cluster.

- These modules each accept plaintext, apply block encryption, and emit ciphertext, then show the reverse path back to plaintext.

- AES additionally includes aes_debug_log.txt, which suggests internal tracing or step-level visibility for educational/debug use.

- The README documents pycryptodome as the external dependency, which is the only notable third-party library mentioned.

7. Public-key and key-exchange subsystem

- RSA demonstrates asymmetric encryption with separate sender/receiver plaintext and ciphertext files.

- Diffie Hellman Algorithm models shared-secret establishment rather than message encryption alone, but it uses the same file-based workflow to show exchanged values and resulting ciphertext-like artifacts.

- These folders represent the shift from shared-key encryption to public-key and key-agreement concepts.

8. Security attack demonstration

- Man in the Middle Attack is a separate scenario module built around Alice, Bob, and Darth.

- The inbox files (Alice_Inbox.txt, Bob_Inbox.txt, Darth_Receiving.txt, Darth_Sending.txt) indicate a three-party message relay rather than a standard encrypt/decrypt pipeline.

- Architecturally, this folder is a vulnerability simulation layered on top of the Diffie-Hellman concept.

9. Hashing subsystem

- SHA1 is the non-reversible hashing branch of the repo.

- It uses message.txt as input and hash.txt as the output digest artifact, with test.py likely used to validate the implementation.

- Unlike the encryption folders, this module does not have a receiver-plaintext restoration step because hashing is one-way.

10. Digital signature subsystem

- Digital Signature Scratch and Digital Signature form a separate authenticity/integrity flow.

- The scratch version includes rsa.py and sha1.py, showing that signatures are composed from hashing plus RSA-style asymmetric operations.

- The inbox files (sender_inbox.txt, receiver_inbox.txt) indicate signed message exchange and verification rather than raw encryption.

11. Overall data relationship

- The repo’s core pattern is: input text or message file → algorithm script → output artifact file.

- Depending on the algorithm, the output is either ciphertext, hash, or signed/verified message content.

- There is no evidence of persistent storage, user interfaces, or networked services; all state is represented by files.

12. How to diagram it

- A clear architecture diagram would show one top-level “educational cryptography collection” box containing independent algorithm modules.

- Inside each module, show a local file input, a single script entrypoint, and a file output.

- Highlight three conceptual branches: symmetric encryption, public-key/key exchange, and hashing/signatures, with the MITM folder as an attack demo on the key-exchange branch.