eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How Superintelligence Works | Agent WebAuthn PRF — Credential Secrets, Salts and Safe Recovery

—

by

eduKate Asia

Did you know? A passkey can do more than sign a login challenge when the authenticator and client support WebAuthn’s pseudo-random function extension. The `prf` extension lets a web application request a credential-associated 32-byte output for a chosen input, with an optional second input. A careful application can use that output as input key material for client-side encryption without asking the server to store the underlying credential secret. The output is not the passkey’s private signing key, and supporting the extension is not automatic for every browser, authenticator or credential.

The safe engineering job is to negotiate actual PRF support, choose domain-separated evaluation inputs, bind outputs to the right credential and relying-party context, derive application encryption keys with a documented construction, and design recovery before encrypting important data. The application must keep raw PRF outputs and derived keys out of server requests, logs and automatic JSON serialisation. A successful WebAuthn login proves an authentication event under configured checks; it does not prove that the PRF extension ran or that encrypted data can be recovered on every future device.

This is engineering for current passkey-capable systems and authorised AI-agent workflows, not a claim that artificial superintelligence currently exists. The worked byte counts and access scenarios below are invented, checkable examples—not reports of an executed production deployment.

Contents

What changes when authentication also yields credential-bound key material

Traditional WebAuthn signs a challenge so a relying party can verify an authentication ceremony. The server checks origin, RP ID, challenge and signature under a registered credential’s public key, together with applicable user-presence and verification requirements. That produces evidence that an authenticator associated with the credential participated. It does not directly provide a symmetric encryption key for local documents.

Some applications want encrypted notes or drafts to remain unreadable to the remote service while an authorised person can unlock them by using a familiar passkey flow. WebAuthn’s `prf` extension is relevant because it offers a deterministic pseudo-random output scoped to the credential and evaluation input. An application can build encryption-key derivation around that output, provided it treats availability and recovery as first-class concerns.

The W3C Web Authentication Level 3 specification defines the PRF client extension and its integration with authenticators, including those implementing CTAP2’s `hmac-secret`. It describes `first` and optional `second` evaluation inputs, an `enabled` flag in registration output, and `results` when an evaluation succeeds. These precise fields matter more than a product marketing description of ‘passkey encryption’.

The agent’s role should remain bounded. It may request an authorised user-mediated WebAuthn operation and use the returned output in a permitted client workflow. It must not infer that an unrelated webpage, plugin or instruction can bypass the origin or user-verification context. The credential holder’s access decision remains under the platform and application policy, not the language model’s confidence.

Importantly, the signing credential and the application encryption key have different lifecycles. A login credential can authenticate to a server even if local encrypted content is permanently inaccessible because the derivation was not supported or its recovery key was lost. Conversely, a copied application encryption key can expose data even if the user’s passkey remains uncompromised. Keep those trust boundaries visible.

What the W3C extension actually returns

The `prf` client extension uses evaluation inputs typed as byte arrays through BufferSource. The structure `eval` contains a required `first` value and may include `second`. During an authentication ceremony, `evalByCredential` can map specific allowed credential identifiers to corresponding evaluation inputs. A selected credential’s output is returned as `results.first`, and optionally `results.second` if that second input was supplied and evaluation occurred.

The specification’s abstract authenticator procedure describes a pseudo-random function associated with the credential, producing exactly 32-byte outputs. A compatible authenticator does not reveal the underlying secret to the web application simply because the caller provided an input; rather, it evaluates the function and the client receives the result. This is a powerful distinction, but the result itself may become usable key material and must be protected accordingly.

During registration, the `enabled` output can indicate that the credential supports the PRF. A registration call may not return evaluation results even when support exists; the specification explains that some authenticators need a subsequent assertion to produce outputs. During authentication, the extension’s `results` can be absent if no suitable input was evaluated or the platform did not provide it. Never replace a missing result with zero bytes or a guess.

The standard also states restrictions on `evalByCredential`: it applies to assertions with a nonempty `allowCredentials` list and has credential-ID validation rules. When the user selects a discoverable credential without the application knowing which credential will be chosen in advance, a generic `eval` input may be more appropriate. The developer must match the correct input mode to the supported ceremony rather than quietly ignoring the API’s conditions.

An AI agent should represent the result as a typed security outcome: evaluation requested, credential selected, extension results present or absent, and whether the intended client-side use succeeded. Do not mark encryption ready simply because a normal WebAuthn assertion passed.

Why the input is hashed with a WebAuthn-specific context

An authenticator implementing CTAP2 may also expose a lower-level `hmac-secret` extension. WebAuthn’s `prf` interface deliberately separates web applications’ use from other potential consumers of the underlying PRF. The W3C processing algorithm hashes an application-provided evaluation input with a fixed context prefix: SHA-256(UTF8(‘WebAuthn PRF’) || 0x00 || input). This keeps WebAuthn inputs in their designated domain instead of exposing arbitrary lower-level evaluations.

Domain separation is not a substitute for authorisation. It prevents one class of cross-protocol confusion, while the browser and authenticator still enforce the relevant origin, RP ID, credential and verification boundaries. A developer should not strip the prefix or implement an imagined direct `hmac-secret` call when following the WebAuthn extension.

Application-level separation is also worthwhile. An online document editor might use distinct logical purposes for ‘private-notes key v1’ and ‘local-attachment key v1’, plus appropriately generated context values. The application can feed a purpose-specific byte sequence to the API and, where needed, a documented key-derivation function with its own context. Two uses that accidentally share identical PRF inputs for the same credential can produce identical PRF outputs.

This deterministic behaviour is useful and risky. It allows an authorised future assertion to reproduce material needed to decrypt stored ciphertext, but a leak of the PRF output for that context can undermine confidentiality. Secure code should minimise the time key material remains in memory and avoid persisting raw outputs when a more limited derived key is sufficient.

The distinction matters for incident response: rotating a server’s session cookie does not rotate an application key derived from the same credential and PRF input. A real key-rotation plan changes the data-encryption key or wrapping scheme and handles older ciphertext deliberately; it does not rely on the next login challenge magically changing an unchanged derivation input.

One user account is not automatically one cryptographic key

A person may have several passkeys for the same service: a phone credential, a security key and a credential synced through a platform. The PRF is associated with a particular credential, and the application cannot simply assume that different registered credentials return the same bytes for the same input. The verified public key used for login is also not a safe source from which to derive the private PRF output.

Consider an invented account with three authorised credentials, A, B and C. Each can authenticate under the site’s normal policy. But if a note was encrypted under a key derived from credential A and there is no deliberately designed wrapping or recovery method for B and C, a successful sign-in with B does not by itself make that note decryptable. Counting three login options as three recovery options would be an architectural mistake.

Synced credential behaviour must be tested with the specific platform support and security properties intended for deployment. The existence of a synced passkey is not a universal guarantee that a PRF extension will be available, that outputs will be identical across copies, or that the application can read old ciphertext after device migration. Treat these as product- and credential-specific capabilities.

A robust design may generate a separate random data-encryption key and use each verified credential’s derived material only to wrap that key for authorised use. That allows multiple access paths without requiring different credentials to generate identical PRF outputs. However, adding a wrapped-key record must itself be an authorised account operation and its integrity and version metadata must be protected.

The agent should report the distinction: credentials registered for authentication, credentials verified to support PRF evaluation, credentials actually enrolled to unwrap the same data key, and independent recovery methods available. These counts are different units. Secure access should not be advertised through a credential that has never been enrolled for that ciphertext.

What must never be accidentally sent to the remote service

WebAuthn ceremonies often involve sending a credential response to a server for authentication verification. A developer may serialise the response using `PublicKeyCredential.toJSON()` or a helper library. The Level 3 specification explicitly notes that client extension PRF results can be included in this JSON serialisation when present. For a client-side encryption design, forwarding that entire object to the server could leak exactly the key material the design meant to keep private.

The correct architecture separates server-verifiable authentication evidence from local PRF output. Use the relevant verification fields according to the WebAuthn protocol, and exclude or redact client-only extension results before transmitting, logging or sending them to telemetry. This requires examining the particular API and library path actually used, not assuming that the platform automatically hides secrets from every JSON call.

Do not paste raw PRF outputs into AI prompts for debugging. A language model can explain their role from redacted lengths and state flags; it does not need production key material. Avoid console logging, crash reports, analytics breadcrumbs and unprotected browser persistence containing the output or derived key. Minimise exposure and favour established WebCrypto operations rather than hand-rolled encryption.

Client-side secret management also raises content-security and application-script trust questions. An attacker able to run arbitrary same-origin script while a valid user evaluates the PRF may still be able to request results or intercept derived keys. Strong authentication does not make a compromised application JavaScript environment trustworthy. Defend against injection and supply-chain compromise.

Finally, test failure paths. If the extension is absent, the client should fail closed for encrypted content rather than silently uploading plaintext or downgrading to a weak password-derived key without informed authorisation. Graceful user experience means a clear explanation and legitimate recovery route, not bypassing the encryption design.

Worked byte budget: encrypting a short local note

Here is a fully invented storage calculation, not a benchmark. Suppose a UTF-8 document is exactly 1,200 bytes after encoding and the application uses AES-GCM with a 128-bit authentication tag and a fresh 96-bit nonce. The encrypted payload contains 1,200 bytes of ciphertext plus 16 bytes of tag, totalling 1,216 bytes. If the nonce is stored alongside it, the combined nonce, ciphertext and tag occupy 12+1,216=1,228 bytes before any additional framing or metadata.

An application may derive an AES key from a 32-byte PRF result using a documented key derivation or key-wrapping design. The 32-byte output size is a protocol-defined property in the abstract WebAuthn PRF processing. It does not imply that every application’s final encryption key must have 256 bits; algorithm selection, derivation parameters and policy determine the actual key size.

Suppose the system stores 250 such notes with the same plaintext length and independent nonces. Ignoring all record headers and optional metadata, their combined protected payload storage is 250×1,228=307,000 bytes. Using the unencrypted length alone would predict 250×1,200=300,000 bytes. The 7,000-byte difference comes from 250×28 bytes of nonce and tag overhead. This is an arithmetic illustration, not a throughput or cost measurement.

Never reuse a nonce with the same AES-GCM key merely to save 12 bytes per document. Nonce uniqueness and authenticated encryption are requirements of a secure design. A random nonce strategy depends on limits and collision analysis; a deterministic managed counter has different operational hazards. Use documented WebCrypto and platform guidance appropriate to the application’s scale.

Stored ciphertext can still be unusable if the application fails to preserve which key version, credential wrapper or derivation context was used. A practical encrypted record therefore needs integrity-protected metadata and a recovery plan in addition to the visible byte array. Saving space is not the reason to omit those fields.

Why two evaluation inputs do not provide automatic key rotation

The `prf` extension permits one or two evaluation inputs in a ceremony. That can support a workflow where an application requests key material for both a current context and an upcoming context, then performs a documented rotation. The outputs are merely results of two evaluations; the browser does not automatically decrypt old data, re-encrypt records, update wrappers or delete obsolete key material.

Suppose context A derives the key currently used to unwrap stored data and context B derives a new wrapping key. A correct migration would verify the person is authorised, derive or recover the old wrapping material, authenticate and decrypt the old wrapped data key, then rewrap it under the new key with integrity protection. The application should verify that the new wrapper can actually recover the same data key before retiring the old wrapper.

If there are 180 encrypted records, a careless migration that rewrites 170 and reports success because the API returned no error for those 170 has only verified 170/180≈94.44% of records. The remaining ten records are 10/180≈5.56% incomplete. More importantly, the correct unit could be the number of distinct data keys or wrappers, not record count; define the migration’s actual target and check every relevant object.

Do not confuse key-rotation success with sign-in success. The user may authenticate correctly while one encrypted notebook cannot be opened. Test old and new key versions and record the recovery boundary. A failure that is not reversible may permanently deny access to user data.

An AI agent assisting with a rotation should not irreversibly delete old wrappers based solely on a positive-looking intermediate response. It should prepare a verifiable plan, check the intended outcomes and observe the authorised retention policy. Cryptographic state changes should be idempotent where possible and recoverable from recorded checkpoints.

Registration success and PRF availability are different outcomes

A familiar sign-in screen can make credential support look binary: the user either logged in or did not. The PRF extension has additional states. During registration, the client may report `enabled` true or false, indicating whether the created credential has PRF capability. It may return no evaluation outputs during the registration ceremony even when the credential supports later evaluation. During an assertion, the requested evaluation can succeed and return bytes, or it can be absent while ordinary authentication succeeds.

For a fictional deployment test, consider twelve authenticator-browser combinations. All twelve successfully perform a standard WebAuthn login. Eight report the necessary PRF capability for a new credential, six actually return expected evaluation results in the supported test ceremony, and four remain unable to produce an output in that test. The login success ratio is 12/12=100%, but the observed usable-output ratio is 6/12=50%. The difference is central to user promises; this example is illustrative, not a current browser compatibility survey.

An agent performing readiness checks must not convert the twelve successful logins into twelve ready encryption routes. It should record which credential and platform combination was tested, what input was used, whether `results.first` appeared with the correct 32-byte length, and whether an allowed repeat produced the same result for the same credential and input. These are observable capability checks; they do not require publishing the secret bytes.

The system also needs to consider consent and user presence. A person who enrolled a passkey for login did not necessarily consent to losing access to private documents when PRF evaluation is unavailable. Before changing storage to require this extension, provide explicit capability checks, an appropriate alternative and a clear recovery policy. Do not silently switch to plaintext storage if the encrypted path fails.

Treat implementation changes carefully. Browser or platform updates may add or remove capabilities, and security-key variants can differ. Record exact configurations in a controlled test matrix rather than claiming that ‘passkeys support PRF’ as a universal statement.

Using WebCrypto without inventing a cryptographic protocol

The 32-byte PRF result is cryptographic material, but a secure application still needs an encryption design. One approach feeds the result into a standard key derivation mechanism with explicit application context to obtain a key-encryption key. That key can wrap a separately generated random data-encryption key used for content. Alternatively, a carefully reviewed design may derive a direct content key for a constrained use. The right choice depends on rotation, recovery, multiple credentials and the threat model.

Web browsers expose standard cryptographic operations through the W3C Web Cryptography API. A typical AES-GCM flow uses a key imported or derived with the correct permissions, a unique nonce for each encryption under the same key, an authenticated ciphertext and integrity checks when decrypting. The protocol specification defines legitimate primitives, but integrating them safely requires choosing sizes, key derivation and metadata rules correctly.

Never use a predictable value such as the account email as an independent encryption key. A low-entropy identifier cannot serve as high-entropy key material merely because a hashing function outputs many bytes. Similarly, do not simply concatenate an untrusted label with a password and claim the result is equivalent to credential-protected PRF output. The property at issue is a secret, credential-associated function plus a secure client operation.

Define whether encrypted data should survive credential deletion, account migration and authenticator replacement. Direct encryption with one credential-derived key makes recovery depend strongly on reproducing that material. Envelope encryption with an independently generated data key can support multiple credential wrappers, but introduces protected wrapper metadata and additional authorisation checks. There is no zero-cost design that offers every convenience without new security responsibilities.

Use established libraries and independent review for production systems. This article describes the boundary and arithmetic; it does not replace a threat model, security testing or the cryptographic specification’s requirements.

Threats the extension mitigates—and threats it does not

A credential-associated PRF can reduce reliance on a server-held symmetric secret for a client-side use. The server may be able to store encrypted blobs without learning their data-encryption key, provided the client never transmits key material. That can be valuable for privacy, but it is conditional on the integrity of the application code running in the browser and the key-management design.

A same-origin script injection, compromised dependency or malicious extension can undermine a client-side encryption workflow while the authorised person uses it. If attacker-controlled code runs with the page’s privileges, it may observe derived material or read decrypted content. WebAuthn’s phishing-resistant origin binding is helpful at the authentication boundary, but cannot make compromised legitimate-origin code harmless.

Cross-account confusion is another risk. If an application stores a wrapped key under the wrong user, tenant or record, a later request might attempt to use an authorised credential on unrelated data. Protect the mapping between account, credential ID, derivation context and ciphertext. Check both authentication authority and local data ownership before attempting decryption.

Recovery introduces its own attack surface. A backup phrase, secondary credential or recovery key may be easier to steal than a hardware-protected secret if it is weakly stored. It may also be impossible to restore after a loss. Provide recovery methods that match the sensitivity and operational needs of the user and clearly label any trade-offs.

Threat modelling should distinguish an attacker who steals ciphertext, one who sees encrypted wrappers, one who controls the origin’s JavaScript, one who controls a separate phishing origin, and one who holds a legitimately enrolled credential. Different attackers require different mitigations. The PRF extension is a building block, not an all-purpose security product.

Recovery design before an agent encrypts its first document

Consider a user who enrols only one security key, derives a content key from its PRF and encrypts ten years of notes. If the device is destroyed and no other recovery method exists, those notes may be inaccessible even if the user can authenticate to the same account using a newly enrolled key. The new credential’s PRF is not obligated to reproduce the old credential’s secret output.

A thoughtful design begins with an explicit recovery objective. Does the application support multiple registered unlock credentials, an independently generated recovery key stored by the user, organisation-managed escrow under documented consent, or a documented no-recovery policy? Each option affects privacy, availability and trust. One product cannot promise end-to-end secrecy and effortless server recovery unless it explains where recoverable key material resides.

An independent random data-encryption key wrapped for multiple authorised credentials is one possible architecture. Enrolling credential B should require proof of the account owner’s authority plus access to the data key through an existing authorised route. A server record claiming B is enrolled is not proof that B can actually unwrap and use the same data key; verify the operation before removing the original wrapper.

Check restoration in an isolated test. Create a harmless known plaintext, encrypt it using the selected design, store the required metadata, then recover it through each advertised method without relying on the first credential. This is a model workflow description; no test has been executed in this article. Do not use real personal data or publish keys as test fixtures.

An agent’s user-facing message should distinguish successful login, verified decryption with credential A, verified decryption with independent credential B and untested disaster recovery. If a route has not been tested, it is unavailable as an evidence-backed promise even if the design diagram suggests it should work.

Failure signatures and bounded repair procedures

Failure one: a standard WebAuthn login succeeds but `prf.results` is missing. That is not permission to fabricate zero-valued key material. Check whether the extension is supported, whether the ceremony supplied a valid `eval` or `evalByCredential` input, whether a user-verification requirement was met and whether the selected credential is the one expected. Preserve the original authentication result without claiming that encryption succeeded.

Failure two: the same logical document input yields different decrypted results across devices. Inspect credential IDs, passkey synchronization capabilities, derivation-context bytes, encoding and salt handling. Do not assume similar display names imply the same credential-associated PRF. A code path using UTF-8 in one device and a different byte representation in another can change the output despite apparently identical text labels.

Failure three: a server log contains `results.first` after a normal WebAuthn authentication. Review serialisation, telemetry and API boundaries immediately. Treat the output as potentially compromised key material and follow the organisation’s approved incident and data-key rotation process; changing a session cookie is not sufficient remediation if application ciphertext keys were exposed.

Failure four: encrypted records become inaccessible after a rotation. Do not delete remaining old wrappers. Reconcile the set of expected records, key versions and successful decrypt-and-reencrypt checks using authorised material. Retry recoverable storage errors only after determining whether the original write completed, and keep a durable migration ledger.

Failure five: an agent believes a new credential can unlock old content because it can sign an authentication challenge. Repair by testing the actual wrapped-key recovery path; authentication and decryption are distinct operations. Failure six: a page silently falls back to storing plaintext when PRF is unsupported. Repair the fail-closed path and provide a clear consent-based user choice rather than a misleading success message.

Changed-context exercise: a learner moves from phone to shared classroom computer

Start with an invented learner who encrypted ten files on a personal phone using credential P and a properly stored wrapped data key. The learner later signs in from a shared classroom desktop using credential D. The login ceremony succeeds and the server recognises the account. Does that imply the encrypted files are available? No. The application still needs a valid, authorised mechanism for D to unwrap the same data key, and it must avoid exposing local keys on the shared machine.

Suppose eight of the ten files can be opened after the migration because their wrappers were updated, while two still reference an old context. The verified recovery fraction for that set is 8/10=80%; the failure fraction is 2/10=20%. The files must not be marked fully migrated merely because the account login was successful or because the first test file opened. The correct next action is to preserve the old recovery path and diagnose the two incomplete records.

Now change the context again: the shared desktop’s browser does not provide the PRF extension for credential D. It may still support ordinary WebAuthn authentication. The safe system reports that the user can sign in but cannot unlock the affected content through this route. It can offer a supported alternative, such as accessing the content on the original authorised device or a tested recovery method. It must not ask the learner to type raw PRF bytes into a form or upload a secret key to an AI assistant.

The classroom adds a new privacy constraint. Even a successful local decryption can leave plaintext in downloads, clipboard history or a shared browser profile. A secure app should bound local caching and make sign-out and data-clearing behaviour clear. The PRF extension answers how key material can be produced under a credential; it does not automatically solve shared-device confidentiality.

This transfer tests real understanding: preserve the distinctions among account authentication, credential-specific PRF availability, key-wrapper recovery, document-level completion and the physical security of the device displaying the decrypted content.

What the protocol does not promise

WebAuthn’s PRF extension is not guaranteed to be supported by every browser, authenticator or credential. Compatibility must be tested for the actual registration and authentication ceremonies. Some implementations can indicate capability at creation without returning an immediate evaluation result; some environments may lack PRF support altogether. Avoid universal statements that a login passkey always yields a usable data key.

The extension does not make any user-controlled JavaScript safe from compromise. A correctly signed WebAuthn assertion can coexist with insecure client application code. Sensitive outputs remain vulnerable if passed into logs, analytics, URLs, server requests or a compromised script context. The standard’s separate extension interface is not a defence against every application bug.

Neither origin binding nor pseudorandomness guarantees availability after account recovery. The credential may be lost, revoked or inaccessible on a new device. A secure recovery design is a separate system component with its own policy and possible trade-offs against secrecy.

PRF output is also not a replacement for the normal WebAuthn server verification ceremony. A remote service still needs to check signed authentication evidence using its registered challenge, origin, RP ID and credential state. Treat local encryption and server authentication as coupled but separately verified operations.

This guide is about present-day identity and cryptography for authorised applications. Future artificial superintelligence remains hypothetical, and nothing here suggests that current AI agents can or should bypass platform-provided user verification or override consent.

Frequently asked questions

Does a WebAuthn passkey automatically support the `prf` extension? No. The browser, authenticator and credential need compatible support, and the application should inspect actual extension results.

Is the PRF output the passkey private signing key? No. It is a separate, credential-associated pseudo-random output under the extension’s defined mechanism, not the public-key signing secret.

How long is one PRF output? The W3C Level 3 abstract authenticator procedure specifies a 32-byte output.

What are `first` and `second`? They are the one or two evaluation inputs requested through `eval`, or per-credential inputs using the permitted `evalByCredential` path.

Why might registration report enabled support without returning key material? Not all authenticators support evaluating the PRF during credential creation; an assertion may be required afterward.

Can two passkeys registered to the same user be assumed to produce identical PRF bytes? No. Key material is credential associated, so cross-credential decryption needs a designed wrapping or recovery approach.

Does ordinary successful login mean encrypted content can be opened? No. A separate PRF evaluation and correct key recovery path are needed.

May I send `PublicKeyCredential.toJSON()` to a server unchanged? Review it carefully: PRF client-extension results may be included in its JSON representation and should be withheld when intended to stay client-side.

Does including a second evaluation input rotate the key automatically? No. The application must migrate or rewrap the affected data and verify the outcome.

Can AI read my PRF result to diagnose a problem? It is unnecessary and unsafe to expose live key material. A useful diagnostic can record success flags, lengths, credential identifiers in appropriately protected form and redacted error categories.

Primary standards, verified siblings and practical reader routes

Engineers should start with the normative W3C Web Authentication Level 3 specification, particularly its PRF extension input, output, registration and authentication rules. The W3C Web Cryptography API describes standard browser cryptographic operations. Read the version actually implemented in the intended platforms and test the relevant capabilities rather than generalising from one working device.

For WebAuthn authentication foundations and origin checks, use the already verified eduKate sibling Agent WebAuthn Passkeys — Challenges, RP IDs and Verified Login. This PRF article owns a different question: how credential-bound secret outputs may support client-side key derivation and what recovery and data-protection limits remain.

Security reviewers should trace the exact path of the extension output through the client, including helper libraries, response serialisation, in-browser storage, telemetry and encryption calls. Ask whether a second authorised credential can actually unwrap existing content, how an old data key is retired and which encrypted records have passed a restoration check. Authentication logs alone cannot answer those questions.

Product owners should present usable recovery choices in human terms, not only cryptographic jargon. A person needs to know which device can unlock private documents, what happens when it is lost and whether any recovery service can access the material. A privacy claim unsupported by an actual threat model may be worse than a plainly limited, well-tested design.

For the wider engineering series, see How Super Intelligence Works. The byte counts, account scenarios and test outcomes in this article are explicitly invented to teach verifiable reasoning; no external service configuration or software test has been represented as performed.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading