The settings file holds a signing key and a data encryption key - what does disclosure of each one let an attacker do?

## Two entries, two different kinds of power An internal admin tool's settings file often carries both: a key used to sign the tool's own outputs so the tool can later tell its own values from forged ones, and a key used to encrypt stored records so the records are unreadable without it. Both fail the disclosure test and both are secrets. The reason an interviewer asks about them together is that the *shape* of the damage is different, and the difference decides what 'we replaced the key' is worth. ## What each disclosure buys the holder | | signing key | data encryption key | |---|---|---| | capability gained | produce values that verify as ours | read ciphertext that key protected | | direction in time | forward: forgeries from now on | backward: everything already encrypted | | what the attacker needs besides the key | somewhere to present the forgery | a copy of the ciphertext | | what a replacement achieves | new forgeries stop being accepted once verifiers stop trusting the old key | only new records are protected by the new key | | what a replacement does not achieve | it does not retract what was already accepted | it does not make copies already taken unreadable | ## The forward direction: a production capability A holder of the signing key can produce anything the verifier checks with that key: a link the tool treats as one of its own, a record the tool believes it wrote, a value another system accepts because it verifies. That capability lasts for as long as verifiers still accept the key, and verifiers are the hard part - every party that checks signatures has to learn that the key is no longer trusted, and until they do, forgeries keep verifying. There is a second, quieter loss. Before the disclosure, a valid signature was evidence that only the key's holder could have produced the value. Afterwards it is not, because a second party demonstrably held the key. That is why a signing-key disclosure casts doubt over past outputs even though the attacker never touched them: the signature stops being proof of origin. ## The backward direction: a reading capability A holder of the data encryption key reads whatever that key encrypted, but only for ciphertext they actually have. The crucial question after disclosure is therefore not about the key at all - it is **which copies of the ciphertext exist**. An export taken last quarter, a backup, a follower replica, a file someone pulled down to debug: each is a copy that the disclosed key opens, forever, with no further access to our systems required. This is where the most common mistake in the whole subject appears. Putting a new key in place protects what is encrypted **from then on**. It does not reach the copies an attacker already holds - those remain readable under the old value. Re-encrypting the stored records under the new key is a separate, usually expensive piece of work, and even that reaches only the records *we* hold, never the copies we do not. ## The classification consequence Both entries belong in the secret class, but they carry different costs and different urgency, and the honest way to state the difference is by direction: - The **signing key** is the entry whose disclosure keeps producing new damage while anyone still trusts it, and whose damage stops accumulating only when verifiers stop trusting it. - The **data key** is the entry whose disclosure has already done most of its damage at the moment of exposure, bounded by how much ciphertext has escaped. A useful second question falls straight out of that: for the signing key, who verifies and how would they be told? For the data key, what has been exported, and to where? Those are different investigations, and a team that classifies both entries as 'key material' and stops has not asked either of them. ## What a strong answer avoids It avoids saying that replacing the key 'fixed' anything an attacker already took - that claim is false for both entries in different ways. It avoids treating the two as interchangeable because both are key material. And it names the direction explicitly rather than implying it, because both claims are perfectly grammatical stated backwards and stating them backwards is the classic version of getting this wrong.