Tripos Worked Solutions: 2025 Paper 2 Question 5

Question: Software and Security Engineering — 20 marks (Q5a: 6, Q5b: 14)

You have joined the team developing a new, rapidly growing social media service. The system is decentralised: anybody can run their own server and interact with users on other servers, e.g. by seeing posts made by users on other servers.

(a) Explain some possible strategies for testing the server software for this social network. [6 marks]

(b) Your server currently authenticates users via a password, but your team is discussing whether to introduce public-key authentication. Discuss how this might work, and its pros and cons compared to passwords. Consider both how a user logs in to their home server, and also how posts on one server are authenticated by another server. [14 marks]

Part (a): Testing Strategies [6 marks]

Model answer:

Unit tests on core server logic (post storage, validation, ranking) in isolation, with the network and federation layer mocked or stubbed. Provides fast feedback, per the Testing Pyramid base.
Integration tests against a real database and a second, locally-hosted server instance to exercise real federation calls. Catches boundary/serialisation bugs of exactly the kind seen in the Mars Climate Orbiter case — two independently-written components can each pass their own unit tests while disagreeing on a shared data format (e.g. date format, encoding).
Protocol conformance / interoperability testing: since other people’s servers are independently implemented and untrusted black boxes, it is not sufficient to test your server against only your own implementation. You must test against the published federation protocol specification directly — your implementation may have made the same assumption as your test fixture.
Fuzzing of message parsers that accept federated input from arbitrary remote servers. Malformed or hostile payloads are a realistic threat (Denial of Service, Tampering in STRIDE terms) — the parser must fail safely (reject) rather than catastrophically (crash, leak memory, expose a code-execution vulnerability).
Load / scale testing, since the service is described as “rapidly growing.” Test under anomalous, bursty load, not just the steady-state happy path. Models the London Ambulance Service collapse: a system that functions under normal load can fail catastrophically when load exceeds design assumptions, flooding itself with duplicate retry requests.
End-to-end testing for the critical user journeys (posting, following a remote user) plus security-focused testing — e.g. attempting to forge a post claiming to be from another server’s user, given the federated trust model where servers are not centrally vetted.

Mark-scheme guidance: 6 marks reward roughly one mark per distinct, well-justified strategy. Name the strategy, explain why it matters for this specific decentralised system, and link it to course concepts or case studies. Do not simply list testing types generically.

Part (b): Password vs Public-Key Authentication [14 marks]

1. How password authentication currently works (baseline)

The user registers with a username and password. The server hashes the password with a per-user salt using a slow hash (bcrypt, scrypt, Argon2) and stores the salt and hash. On login, the user submits credentials over TLS; the server hashes the provided password and compares. On match, a session token is issued.

The user generates a key pair locally. The public key is registered with the home server (analogous to SSH key-based login). The private key never leaves the user’s device.
To log in, the server sends a random challenge (nonce).
The client signs the challenge with the private key and returns the signature.
The server verifies the signature against the stored public key. On success, it issues a session token.
Crucially, no secret (password or private key) is ever transmitted over the network. The server never learns the private key.

3. How posts are authenticated cross-server with public keys

Each post is digitally signed by the author’s private key at creation time. The signature is attached to the post.
A remote server that receives the post fetches the author’s public key from the author’s home server (analogous to fetching a TLS certificate or an SSH host key) and verifies the signature.
This lets any receiving server independently and cryptographically confirm that the post genuinely originated from the claimed author and has not been tampered with in transit — without needing to trust the sending server’s word.
By contrast, under password authentication, cross-server post authenticity has no natural equivalent: Server B has no cryptographic way to verify a post claimed to be from a user of Server A. It must simply trust Server A’s assertion — a Spoofing vulnerability (STRIDE).

Pros of public-key login:

Phishing-resistant: nothing secret is typed into a fake login page. The private key never leaves the device.
Server-breach resistant: only public keys are stored server-side. A database breach discloses no secret — an attacker learns who the users are but cannot impersonate them.
Eliminates weak/reused password risk: no password to be guessed, reused across services, or cracked from a hash.

Cons of public-key login:

Unfamiliar to ordinary users: SSH-key-style authentication is well-known to developers but alien to the general public.
Key management is hard: there is no simple “forgot password” recovery equivalent. Losing the private key with no backup can mean permanent loss of account control.
Requires client-side tooling: secure key storage (OS keychain, browser extension, hardware token) that most users do not currently have for a social network.

5. Pros and cons — Cross-server post authentication (public key vs password)

Pros of public-key for cross-server authentication:

Enables independent cryptographic verification by any server without a trusted third party or blind trust in the sending server — essential in a decentralised system where servers are run by arbitrary, unvetted operators.
Directly mitigates Spoofing and Repudiation (STRIDE) for federated content.
A malicious or compromised server cannot forge a post attributed to a user on another server — the signature would not verify.

Cons of public-key for cross-server authentication:

Requires a public-key distribution and revocation infrastructure — how does Server B know that the key it fetched for Alice is genuinely Alice’s key and not a key substituted by a malicious Server A? This requires some form of trusted registry or web-of-trust.
Signature verification and key lookups add computational and latency overhead at scale, versus a password check that only matters at login time.
Key compromise and rotation: if a user’s private key is compromised, all previously-signed posts become suspect, and a revocation mechanism (e.g. Certificate Revocation List) is needed to propagate the knowledge that the old key is invalid.

6. Balanced conclusion / recommendation

A strong answer proposes a hybrid: keep password (+ two-factor authentication) login for home-server usability, since login is a human-facing, low-frequency operation where usability and recoverability dominate. Adopt public-key signing for every post, since cross-server post authentication is a machine-to-machine, high-frequency operation where cryptographic verifiability (not human usability) is critical, and it is the only mechanism that scales trust across a decentralised network of independently-operated servers.

Mark-scheme guidance: 14 marks likely split roughly as: ~4 marks for correctly describing the challenge-response login mechanism; ~4 marks for correctly describing signed-post cross-server authentication; ~4 marks for balanced, specific pros/cons (not generic); ~2 marks for a coherent, justified conclusion/recommendation. Marks are lost by only discussing login or only discussing post authentication — the question explicitly asks for both.