# SHRINCS: 324-byte stateful post-quantum signatures with static backups **URL:** \ **Category:** Protocol Design\ **Tags:** cryptography, post-quantum\ **Created:** [December 11, 2025, 8:40am UTC](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158 "2025-12-11T08:40:59Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![conduition](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/conduition/32/384_2.png) [@conduition](https://delvingbitcoin.org/u/conduition)\ **Post date:** [January 27, 2026, 6:38am UTC](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158/14 "2026-01-27T06:38:55Z")
Ah you’re right, that would be a bad footgun. Maybe one could force the issue by rotating the TPM auth value or decryption key after every new signature, making old disk backups completely invalid? But then we’re back to the same synchronization issue as with [your first approach](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158/11), where two parallel requests would result in a race condition when writing to the TPM. So might as well just use your state commitments idea. Come to think of it, is there anything special about a TPM in this context besides its isolation from the hard drive? If all you need is an independent authenticated CRUD interface to commit to some state, that interface could be almost anything… a webserver, a database, a nostr relay, a thumb drive, heck maybe you could even use OP\_RETURN. Certainly many options to explore here… --- _[View the full topic](https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-quantum-signatures-with-static-backups/2158)._