Impact of Stealing a Private Key in TLS

If an attacker steals the private key of a website that uses Transport Layer Security (TLS) and remains undetected, several serious security threats can occur.

• Decryption of Encrypted Traffic: The attacker can decrypt past and future TLS sessions (if Perfect Forward Secrecy is not used).
• Impersonation: The attacker can impersonate the legitimate website and perform Man-in-the-Middle (MITM) attacks.
• Data Theft: Sensitive data such as usernames, passwords, cookies, and credit card details can be stolen.
• Malware Injection: Malicious content can be injected while appearing as a trusted website.

Mitigation Steps:

• Immediately revoke the compromised certificate.
• Generate a new key pair and install a new certificate.
• Enable Perfect Forward Secrecy (PFS).
• Monitor logs and notify users if required.

Reasonable Security Policy for Cross-Origin Frame Navigation

Consider two browser frames A and B loaded from different origins. Allowing frame A to navigate frame B to another origin is considered a reasonable security policy only when the display area of A contains part of B and A has control over that area.

Reasons:

• User Awareness: Since frame A visibly contains part of frame B, the user can see the interaction and is less likely to be tricked by hidden or invisible actions.
• UI Control: If A controls the display area of B, it implies an explicit embedding relationship, making navigation intent clearer and more legitimate.
• Clickjacking Prevention: This restriction prevents malicious frames from silently redirecting other frames that are not visually or structurally related.
• Least Privilege Principle: A is granted limited control (navigation only), not full access to B’s content, maintaining origin isolation.
• Maintains Same-Origin Security: While navigation is allowed, reading or modifying B’s data remains restricted, preserving the same-origin policy.

Allowing navigation under these controlled and visible conditions balances usability with security and prevents abuse across origins.

Adjacency List vs Adjacency Matrix: When Each is More Efficient

The choice between adjacency list and adjacency matrix depends on the graph’s density and the specific operation being performed. Neither is universally better; each has scenarios where it dominates.

Problems Solved More Efficiently in Adjacency List

Adjacency list stores only the edges that actually exist, making it ideal for sparse graphs where the number of edges is much less than the square of the number of vertices.

• Memory efficiency: Space is O(V + E) instead of O(V²). For a graph with 10,000 nodes and 20,000 edges, the list uses ~30,000 units while the matrix wastes 100,000,000 units.
• Faster traversal of neighbors: To visit all neighbors of a node, the list iterates only through actual edges. The matrix scans an entire row of V entries regardless of how few edges exist.
• Better for DFS and BFS: These algorithms repeatedly ask “what are the neighbors of this node?” The list answers in O(degree) time versus O(V) for the matrix.
• Dynamic graphs: Adding or removing edges is simpler when only existing connections are tracked.

Example: Social networks where most users have hundreds of friends among millions of users. Finding all friends of one user is fast with a list but wasteful with a matrix.

Problems Solved More Effectively in Adjacency Matrix

Adjacency matrix stores a complete V × V table, making it superior for dense graphs and operations that need instant edge existence checks.

• O(1) edge lookup: Checking if an edge exists between two specific nodes takes constant time. In a list, this requires scanning all neighbors of one node, taking O(V) in the worst case.
• Matrix operations: Graph algorithms using linear algebra like Floyd-Warshall (all-pairs shortest path), transitive closure, and eigenvalue computations require the matrix structure.
• Dense graphs: When E is close to V², the matrix uses less overhead than pointer-based lists and benefits from CPU cache locality since data is contiguous.
• Simple implementation: No linked lists or dynamic arrays to manage; a 2D array is straightforward.

Example: A fully connected network topology where every router connects to every other router. Checking direct connectivity between any two routers is instant with a matrix.

Comparison Table:

Key Insight: Use adjacency list when the graph is large and sparse, or when neighbor traversal dominates. Use adjacency matrix when the graph is small and dense, or when edge existence queries and matrix math operations are frequent.