r-zakarya
642dfdb077
Adding an entry took five to seven seconds. The log now says where they went: key derived in 4395 ms. Every save re-derived the master password - 600000 iterations - to arrive at exactly the key that had just been used. The remedy was already half written: EncryptContainerWithKey exists for this reason, but only within a single save. The key now lives for the session, and is reused only when the container carries the same salt and the same iteration count - the desktop may have re-encrypted its own with a fresh salt, and a key that does not fit fails on GCM's tag while the message blames the password, which would be right. Nothing new is exposed: the plaintext vault is already in memory, and the cache already holds the password that produces this key. It goes with them, at lock - salt included, or the next open would think it holds a usable key and decrypt against nothing. The envelope is read in one place now rather than copied per entry point: at three copies, a drift between them would surface as a wrong-password error. Measured against the real repository: HTTP 200, decrypted, 8 entries - so the envelope refactor holds. The reuse line itself is not yet measured on the device.
