You are viewing a single comment's thread from:

RE: Proposal: Design and early-development libraries for (QR) hash-based signatures

in Quantum Resistance3 years ago (edited)

Eliptic curve cryptography is vulnerable to a modifief version of the shor algorithm

https://arxiv.org/abs/quant-ph/0301141

That means that once a few thousand qubit quantum computer exists, having either a public ECDSA key or an ECDSA signed transaction, deriving the signing key in a reasonable amount of time becomes practical.

The solution is multifaceted, but the signatures part of it involes a combination of a largish private key that is statefull, a one time signature algorithm such as WOTS or WOTS+, and merkle trees.

LMS is a candidate. So is XMSS, and there are others. Currently looking into an XMSS-like posibility using BLAKE or BLAKE2 as core hashing algorithm.

Please note that offering quantum-secure signatures is not enough to fix the problem by itself. We will also need separation strategies and tech to effectively separate both the market and the liquidity of upgraded vs vulnerable key holdings. That part isn't part in any way of the current proposal, that just aims for a first step on the signatures part of things.

Sort:  

Suppose there is a reasonable solution, ahead of any action taken against Hive. What do we do about blocks prior to the solution? Do we pull all of the transactions out and re-sign them into a whole new chain? Do we leave them in place and only use the new signing from then on?

Good question, and something that might eventually need attention, together with market/liquidity isolation. A question though that should I think, if it is relevant, be mostly relevant for brand new nodes that need to sync the whole chain from zero.

As stated, my proposal above is just a small first step on the hash-based quantum-resistant signatures part of things. I think we need a roadmap and people like you who know to ask the right questions to come to that roadmap.

Maybe you could look into the new node aspect in a blog post and post it in the (still fetal sized) community ?

I suppose having a separate balance that uses quantum-resistant keys would be a good first step. Those keys would be preferred after that. Whereas the legacy (non-quantum-resistant) keys would be less preferred, for a time. Then, once adequate adoption is achieved, the legacy keys would be fully discouraged.

Then, after enough time has elapsed, the legacy keys would only be used for replays, perhaps at that point, using quantum-resistant checkpoints during the replay.