engineering

Trust on first use

Trust on first use is a engineering topic covered in the lgStudy science library. This page brings together a partial reference excerpt, illustrations, worked examples, real-world applications and a short study plan, so you can understand Trust on first use rather than just read about it. In short: Trust on first use (TOFU), or trust upon first use (TUFU), is an authentication scheme used by client software which needs to establish a trust relationship with an unknown or not-yet-trusted endpoint. In a TOFU model, the client will try to look up the endpoint's identifier, usually either the public identity key of the endpoint, or the fingerprint of said identity key, in its local trust database.

Key takeaways

Trust on first use belongs to engineering; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect Trust on first use to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of Trust on first use from memory before moving on to harder problems.

Reference excerpt

Trust on first use (TOFU), or trust upon first use (TUFU), is an authentication scheme used by client software which needs to establish a trust relationship with an unknown or not-yet-trusted endpoint. In a TOFU model, the client will try to look up the endpoint's identifier, usually either the public identity key of the endpoint, or the fingerprint of said identity key, in its local trust database. If no identifier exists yet for the endpoint, the client software will either prompt the user to confirm they have verified the purported identifier is authentic, or if manual verification is not assumed to be possible in the protocol, the client will simply trust the identifier which was given and record the trust relationship into its trust database. If in a subsequent connection a different identifier is received from the opposing endpoint, the client software will consider it to be untrusted.

TOFU implementations In the SSH protocol, most client software (though not all) will, upon connecting to a not-yet-trusted server, display the server's public key fingerprint, and prompt the user to verify they have indeed authenticated it using an authenticated channel. The client will then record the trust relationship into its trust database. New identifier will cause a blocking warning that requires manual removal of the currently stored identifier. The XMPP client Conversations uses Blind Trust Before Verification, where all identifiers are blindly trusted until the user demonstrates will and ability to authenticate endpoints by scanning the QR-code representation of the identifier. After the first identifier has been scanned, the client will display a shield symbol for messages from authenticated endpoints, and red background for others. In Signal the endpoints initially blindly trust the identifier and display non-blocking warnings when it changes. The identifier can be verified either by scanning a QR-code, or by exchanging the decimal representation of the identifier (called Safety Number) over an authenticated channel. The identifier can then be marked as verified. This changes the nature of identifier change warnings from non-blocking to blocking. In e.g. Jami and Ricochet the identifier is the user's call-sign itself. The ID can be exchanged over any channel, but until the identifier is verified over an authenticated channel, it is effectively blindly trusted. The identifier change also requires an account change, thus a MITM attack for same account requires access to endpoint's private key. In WhatsApp the endpoint initially blindly trusts the identifier, and by default no warning is displayed when the identifier changes. If the user demonstrates will and ability to authenticate endpoints by accessing the key fingerprint (called Security Code), the client will prompt the user to enable non-blocking warnings when the identifier changes. The WhatsApp client does not allow the user to mark the identifier as verified. In Telegram's optional secret chats the endpoints blindly trust the identifier. Changed identifier spawns a new secret chat window instead of displaying any warning. The identifiers can be verified by comparing the visual or hexadecimal representation of the identifier. The Telegram client does not allow the user to mark the identifier as verified. In Keybase the clients can cross-sign each other's keys, which means trusting a single identifier allows verification of multiple identifiers. Keybase acts as a trusted third party that verifies a link between a Keybase account and the account's signature chain that contains the identifier history. The identifier used in Keybase is either the hash of the root of the user's signature chain, or the Keybase account name tied to it. Until the user verifies the authenticity of the signature chain's root hash (or the keybase account) over an authenticated channel, the account and its associated identifiers are essentially blindly trusted, and the user is susceptible to a MITM attack.

Model strengths and weaknesses The single largest strength of any TOFU-style model is that a human being must initially validate every interaction. A common application of this model is the use of ssh-rpc 'bot' users between computers, whereby public keys are distributed to a set of computers for automated access from centralized hosts. The TOFU aspect of this application forces a sysadmin (or other trusted user) to validate the remote server's identity upon first connection. For end-to-end encrypted communication the TOFU model allows authenticated encryption without the complex procedure of obtaining a personal certificate which are vulnerable to CA Compromise. Compared to Web of Trust, TOFU has less maintenance overhead. The largest weakness of TOFU that requires manual verification is its inability to scale for large groups or computer networks. The maintenance overhead of keeping track of identifiers for every endpoint can quickly scale beyond the capabilities of the users. In environments where the authenticity of the identifier cannot be verified easily enough (for example, the IT staff of workplace or educational facility might be hard to reach), the users tend to blindly trust the identifier of the opposing endpoint. Accidentally approved identifiers of attackers may also be hard to detect if the man-in-the-middle attack persists. As a new endpoint always involves a new identifier, no warning about potential attack is displayed. This has caused misconception among users that it's safe to proceed without verifying the authenticity of the initial identifier, regardless of whether the identifier is presented to the user or not. Warning fatigue has pushed many messaging applications to remove blocking warnings to prevent users from reverting to less secure applications that do not feature end-to-end encryption in the first place. Out-of-sight identifier verification mechanisms reduce the likelihood that secure authentication practices are discovered and adopted by the users.

… excerpt ends here. Continue reading the full article.

Worked examples

Example 1 — a first encounter with Trust on first use

Start with the simplest possible case. Write down what Trust on first use claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In engineering, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to Trust on first use before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about Trust on first use ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of Trust on first use

In research: Trust on first use appears in engineering research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses Trust on first use in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: Trust on first use is common in secondary-school and first-year university syllabi. It links to neighbouring topics Cybersecurity engineering, so understanding it makes those chapters shorter.
In everyday life: Look for Trust on first use outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

Ask Teacher Smith questions about this articleOpens your AI tutor with a question about “Trust on first use” →

Affiliate

Preply — study more efficiently by working with a personal tutor. 50% off.

How to study Trust on first use in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what Trust on first use means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain Trust on first use out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is Trust on first use in simple terms?

Why does Trust on first use matter?

Because it connects several engineering ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study Trust on first use?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on Trust on first use.