Rendered at 14:43:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
socketcluster 4 minutes ago [-]
This article describes exactly the quantum-resistant stateful signature scheme I implemented (from scratch) for my blockchain project about 5 years ago; including the Merkle 1979 variant of Lamport OTS. I also constructed a Merkle Signature Key for multiple-reuse in the exact same way described by the article. See https://capitalisk.com/whitepaper#29-passphrases-and-signatu....
The article stops exactly where I did and doesn't go further into SPHINCS+ which builds on top of the same primitives to provide statelessness.
And the reason I stopped at that was probably for the same reason. There is already a fair amount of complexity involved. I wanted a signature scheme which would be relatively simple to understand and implement. Also, there were no good SPHINCS implementations at the time for my engine and I didn't feel confident to implement from scratch.
Retr0id 7 hours ago [-]
> Does it mean Merkle’s authentication tree is still used today?
> It is. In fact, the Merkle tree is a fundamental part of blockchain.
True, and merkle trees are just about everywhere, but more interestingly it's part of SLH-DSA (the NIST standardization of SPHINCS+), a quantum-secure signature scheme. And it's not just any old merkle tree, it's a continued evolution of the original Lamport signature scheme discussed in the article.
> Current signature schemes can use as few as 32 bytes per key and 64 bytes per signature [RFC8032], but post-quantum replacements are much larger. [...] a new form of X.509 certificate that integrates logging with certificate issuance [...] This achieves the following: Log entries do not scale with public key and signature sizes. Entries replace public keys with hashes and do not contain signatures
The article stops exactly where I did and doesn't go further into SPHINCS+ which builds on top of the same primitives to provide statelessness.
And the reason I stopped at that was probably for the same reason. There is already a fair amount of complexity involved. I wanted a signature scheme which would be relatively simple to understand and implement. Also, there were no good SPHINCS implementations at the time for my engine and I didn't feel confident to implement from scratch.
> It is. In fact, the Merkle tree is a fundamental part of blockchain.
True, and merkle trees are just about everywhere, but more interestingly it's part of SLH-DSA (the NIST standardization of SPHINCS+), a quantum-secure signature scheme. And it's not just any old merkle tree, it's a continued evolution of the original Lamport signature scheme discussed in the article.
> Current signature schemes can use as few as 32 bytes per key and 64 bytes per signature [RFC8032], but post-quantum replacements are much larger. [...] a new form of X.509 certificate that integrates logging with certificate issuance [...] This achieves the following: Log entries do not scale with public key and signature sizes. Entries replace public keys with hashes and do not contain signatures