Mutation testing found that pointing CredentialCipher at
AadResourceType.Vault passed the entire suite. Every credential test compared
the cipher against itself — round trips, cross-type refusals, two-machine sync —
and all of those stay true when both halves of one cipher are wrong together,
because Seal and TryOpen share the constant. A password sealed under the resource
type for a vault encrypts cleanly, decrypts cleanly, syncs cleanly, and violates
docs/crypto.md in a way nothing surfaces until another implementation refuses the
item. By then the AAD is frozen into stored ciphertext and only clients can
re-encrypt it.
This is the third time that hole has appeared in this file, and the second time
mutation testing rather than review is what found it. So the fix is structural
rather than another hand-written test: one table of wire type to resource type,
a theory that seals a sample through each cipher and opens it with the resource
type the table names — never the one the cipher holds — and a guard asserting the
table covers ItemKinds.SyncedTypes. A fourth item type can no longer be added
without pinning its resource type: the coverage test fails, and the sample switch
throws with an explanation.
The two per-cipher tests it replaces said the same thing for hosts and keys, so
nothing is lost and the credential row is no longer something someone has to
remember.
Verified by re-running the mutation matrix. All seven sabotages are now detected:
the credential merge dropping its redaction, the key/credential exclusivity check
disabled, the schema version ladder flattened so a key-bound host claims the
credential version, a credential sending the server an empty fields record
instead of none, CredentialKind claiming to be a host, CredentialCipher sealing
under the wrong resource type, and the credential noun reading "host". Two of
those were unproven before this run — one because the earlier sabotage did not
compile, and one because it was genuinely undetected.
Sync.Tests 88/88, Domain.Tests 117/117. Zero warnings, dotnet format clean.
The client can now seal and open an SSH key item. Nothing consumes it yet —
the repository, the sync engine's per-type handling and the UI come next — but
this is the layer everything above it depends on, and it is the layer where
the crypto has to be right.
SshKeySecret holds the private key as an ordinary string, deliberately, and
says so: a .NET string cannot be wiped, so the material lives until the GC
reuses the memory. libsodium's guarded memory was considered and rejected
because the passphrase protecting the key, the password on the next item and
the JSON the codec just parsed are all strings on the same heap — protecting
one field among them reads as security and buys nothing. What the design does
give is that the key never reaches the disk in plaintext, never reaches the
server at all, and is handed to SSH.NET through a MemoryStream so there is no
temporary key file to leak.
Validation refuses a public key by name. ssh-keygen writes two files whose
names differ by four characters, and pasting the wrong one otherwise produces
a vault item that looks fine and fails at connection time with an
authentication error that says nothing about which file you chose.
The merge redacts the private key and its passphrase from the conflict log.
A host conflict shows both values so the loser can be put back; doing that for
a private key would write the discarded key into a log that is designed to be
read rather than used and is deliberately retained after acknowledgement. Two
different private keys are not something anyone reconciles by reading them
side by side.
And the lesson worth recording, because it nearly shipped: the first version
of AadResourceTypeTests proved nothing. It checked that a key payload does not
open as a host and vice versa — true however both ciphers are misconfigured,
because Seal and TryOpen share one constant, so changing it changes both and
the round trip still works. Sealing every private key as if it were a vault
passed all twelve tests. The tests now open a sealed payload independently
through ItemKeys with the resource type named out of band, and that does fail
under the same sabotage. A test that only compares an implementation against
itself cannot catch a self-consistent mistake.
The trap it defends: SyncEntityType.SshKey is 3, AadResourceType.SshKey is 6,
because the crypto enum also carries None, User, Device and Vault ahead of the
item types. A cast between them is a specification violation that encrypts
cleanly and would only surface when another implementation refused the item.
jaap-jan