Suneet Singal on a cryptographic inventory

Suneet Singal’s technology entries use a cryptographic inventory as a planning list, not as a tour of how to break anything. The list records where cryptography is doing a job you rely on: keeping stored information confidential, detecting a change, agreeing on a key, signing a document, or signing a person in. Each row names the system, the job, the algorithm if you can learn it from a source you are allowed to read, the lifetime of the data, and the vendor who can change the component. That is defensive bookkeeping. It is the vocabulary NIST and CISA expect organizations to have before they shop for post-quantum products, and it is useful even for a household that only has mail and a password manager. This page does not tell anyone to scan a network, probe a system, or extract a key. It is not personal security advice, and it is not a claim that a named company has finished the list.

What the inventory is

A cryptographic inventory is a table of uses, not a pile of certificates dumped from a folder. A use is a sentence. This site’s certificate lets browsers check the connection. This backup is encrypted with a method named in the backup vendor’s settings. This passkey signs the login for this mail account. This vendor signs the software updates for this laptop. If you cannot say the sentence, you do not yet have a row. You have a product name. Product names belong in a column. They do not replace the sentence.

The table is defensive because its reader is the owner, or someone the owner has asked to look at systems the owner operates or pays for. The sources are vendor documentation, settings screens the owner administers, certificates the owner can see for the owner’s own site, and standards pages from NIST or the FIDO Alliance. Nothing in this entry asks a reader to discover cryptography on a system they do not control. Looking at your own settings is ordinary administration. Sending probes at someone else’s network is not an inventory in the sense used here, and this reference will not describe how to do it.

Suneet Singal’s preserved article on post-quantum security discusses inventory as part of that article’s own argument, at that article’s own date. The address is /post-quantum-security-is-no-longer-a-future-problem/ . This entry does not copy the article’s checklist. It defines the columns so a reader can compare the article, a vendor questionnaire, and the CISA initiative page without losing track of which document said which thing. The article remains related reading. The editorial standards page explains why its date still limits it.

Columns that make a row useful

A usable row has at least these fields. The system or vendor, named specifically enough that someone else could find it. The job: confidentiality, integrity, key agreement, signature, or authentication. The algorithm and key size, written as the documentation writes them, or marked unknown. Whether the method is a public-key method. The data or session lifetime. Who can change the component: you, a vendor, a certificate authority, a platform. The date the row was last checked, and the link or screen the answer came from.

Unknown is an allowed value and a useful one. A row that says “encryption: unknown, vendor contacted on this date” is ahead of a row that guesses AES because AES is famous. Guessing pollutes the table. The post-quantum entry explains why the public-key column matters more for that particular planning problem than a blanket worry about every cipher. If you do not know whether a component is public-key, say so, and ask the vendor a yes-or-no question. Do not fill the cell from a blog post that was about a different product.

Leave secrets out of the table. The inventory names methods. It does not contain passwords, private keys, recovery codes, or seed phrases. A table that contains the secrets is a target, not a plan. The passkeys entry makes the same point about authentication notes. The map and the store stay apart. If a consultant asks you to export keys into a spreadsheet for convenience, that request is outside the inventory this page describes.

Data lifetime is a column, not a mood

Lifetime is how long the confidentiality or the trustworthiness has to last. A session that ends when a browser tab closes is a short lifetime. A tax file, a medical file, a set of plans, or a signature on firmware that will still be checked in ten years is a long lifetime. You do not need a precise birthday for the information. You need an honest bucket: short, years, or “must remain trustworthy for as long as this device is in the field,” which might be the longest bucket of all. The post-quantum planning question compares that bucket with the guidance on the NIST project page and the CISA initiative. This essay does not turn the comparison into a year of its own. If those agencies print a planning horizon, cite their document and its date. Do not cite this paragraph as the horizon.

Different rows in one product can have different lifetimes. A chat’s live transport and the same chat’s backup are the example used in the planning entry, and it is worth repeating because people file both under the product’s brand. Split them. A website’s certificate, which is replaced on a schedule, and the archives the website stored under an older method are also different rows. The certificate’s expiration date is not the lifetime of the archive.

If the lifetime is long and the method is an older public-key method used for confidentiality, the row is the kind of row post-quantum planning exists to find. Finding it is not the same as replacing it this week. Replacement depends on whether a vendor supports FIPS 203 for key establishment or FIPS 204 or FIPS 205 for signatures, and on testing this page does not pretend to supervise. The inventory’s job is to make the row visible and sourced. A shopping list without the row is how organizations buy a product that does not touch the file they actually cared about.

Identity belongs on the list

Passwords, passkeys, and multi-factor methods are cryptographic uses even though they feel like account settings. Give them rows. The job is authentication. The system is the site or the identity provider. The lifetime of a password is awkward, because a reused password stolen today remains useful until it is changed, which is a different shape of lifetime from a message that must stay secret for decades. Write that shape in the cell rather than forcing authentication into the harvest-now story. Some authentication signatures also need to be trustworthy later. Say which kind you mean.

The FIDO Alliance explains passkeys. CISA explains the passwords that remain. Those two pages, plus the settings screen, are enough to fill an identity row without any new theory. Mark whether a password fallback still exists beside a passkey. The fallback is part of the row, not a footnote, because it is often the weaker method and therefore the one a later reader of the inventory needs to see first.

Identity rows are also where a household inventory can start. You do not need a data center to practice the columns. Mail, banking, the manager, and the platform account that syncs passkeys are enough rows to learn that “we use passkeys” is too coarse. One of those accounts will still be password-only. The coarse sentence was the thing the table exists to correct.

Vendors and systems you do not operate

Most readers do not operate their mail server, their bank, or their certificate authority. The inventory still includes those services, with the owner column set to the vendor and the source column set to a public security page or a contract. You can record what the vendor says they use. You cannot record what they will not say, except as unknown. A questionnaire that asks a vendor which NIST standards they support, and when, is an inventory tool. A questionnaire that asks a vendor for another customer’s configuration is not.

Software you install is in between. You chose it, and you often cannot see inside it. The row can name the version and the vendor’s cryptographic claims for that version, with the date of the claim. When the version changes, the row’s date shows that the claim may have changed too. This is the archive-date habit applied to a settings page. A PDF from a vendor titled “encryption overview,” with no date and no algorithm name, fills almost nothing. Keep it in a folder if you like. Do not promote it to a completed algorithm cell.

Certificates on a site you do operate are a row you can fill from the certificate itself, which states an issuer, a validity period, and a public key algorithm. Reading the certificate for your own site in a browser you use as the site’s owner is inspection of your own property. This page does not extend that suggestion to certificates on systems you do not run, beyond what any visitor’s browser already shows for a site they chose to open. Validity dates belong in the inventory because an expired certificate is an availability and trust problem, separate from the post-quantum question. Put the date in the row. Do not treat “HTTPS” as a completed inventory. HTTPS is a label for a family of configurations.

How to read a standard against a row

When a row’s job is key agreement and the method is an older public-key algorithm the vendor names, the NIST document to hold beside it is FIPS 203, ML-KEM, and the announcement from August 2024 that finalized it. When the job is signatures, the documents are FIPS 204, ML-DSA, and FIPS 205, SLH-DSA. The match is by job, not by the glamour of the acronym. A signature standard does not fill a key-agreement row. A password guideline does not fill a backup-encryption row. The discipline is the same as matching a housing statistic to its universe. The wrong standard, confidently applied, is worse than an empty cell.

Hybrid deployments, which use an older method and a newer method together, get a note in the algorithm cell rather than a forced choice of one name. The vendor’s documentation has to say hybrid for the word to be earned. If you write it, say which two methods. “Hybrid post-quantum” with no names is an adjective. The post-quantum entry explains why this page will not add a deadline by which the older half must disappear. Deadlines, if you adopt one, come from a NIST or CISA document you cite, or from your own organization’s written plan. They do not come from a personal essay.

Review the table when a standard’s status changes or when a vendor ships a version you actually install. A quarterly date in the corner of the inventory is enough for many readers. The date is not a security control by itself. It is how a later reader knows whether the unknown cells are unknown as of last week or unknown as of three years ago. Old unknowns look like decisions if the date is missing. With the date, they look like work.

What the inventory is not

It is not a penetration test, a vulnerability scan, or a set of commands. It is not a list of targets. It is not proof that a system is safe. A completed row means you know what you think is in use and where that belief came from. The belief can be wrong if the documentation is wrong. The inventory does not correct the documentation by attacking the system to see. If a configuration needs to be verified, the person who administers it can read the setting they are authorized to read. That is still bookkeeping.

It is not a claim about Suneet Singal’s infrastructure. The site publishes a reference and an article library. It does not publish a cryptographic bill of materials for a company, and the biography’s real estate and corporate finance record should not be read as one. Readers in those fields have vendors, lenders, and data rooms. The inventory is a way to ask those parties a precise question. It does not answer the question for them.

It is not personal advice about which product to buy this month. Product choice depends on the rows, on support for the NIST standards where those rows need it, and on constraints this page cannot see. Use the table to make a short list of questions. Use NIST and CISA for the meaning of the standards and the initiative. Use FIDO and CISA’s password page for the identity rows. Then stop, and let the answers come from documents newer than this essay. If this essay and a newer NIST page disagree about a name, the NIST page wins, and the essay’s job was only to send you there with a row in your hand.

What this entry does not claim

Suneet Singal’s published professional background is in real estate and corporate finance. Company filings linked from this site record a chief executive officer departure from FC Global Realty Incorporated effective 2 January 2018 and an acting chief executive officer appointment at First Capital Investment Corporation effective 12 September 2017. The Suneet Singal Scholarship, Grant and Giving websites describe him as the founder of those programs. This entry explains a general subject. It is not a private track record, a current job title, an investment result, or a quote.

Continue with post-quantum planning in plain language, passkeys and passwords, and why an article’s date is part of its meaning.