Jump to content
Ctrl-Z

If XRP are still in escrow by the times quantum computers arrive, will they be secure?

Recommended Posts

There have been some posts about secret keys and wallet addresses standing up to quantum computers (I'll make believe here that I actually know what quantum computers are:nea:).

In one post, if I recall correctly, Joel Katz says that even if it would be a problem in the future, the wallet string can be increased.

If XRP are in escrow for 20 years and quantum computers arrive before then, is there some way to secure the destination wallet before the release time?

Share this post


Link to post
Share on other sites

Escrows are towards addresses and addresses can change the keys that are allowed to sign transactions for them.

This means if you create an Escrow for your retirement in 40 years, but in 20 years there are quantum computers that might be a problem, you can set a different quantum resistant "regular key" on your wallet and disable the no longer safe original one. This assumes that quantum resistant crypto is around and implemented into XRPL before quantum computers are widely able to break existing crypto primitives, which imho is a reasonable assumption. There are already some (probably) quantum resistant signature schemes out there, they are just a bit clunky and quantum computers are still far away enough to be able to wait for a few more innovations and improvements in this area instead of immediately jumping onto something that might turn out in the future to not have been the best choice when it actually matters.

Edited by Sukrim

Share this post


Link to post
Share on other sites

Yes, you could definitely secure such a wallet. In fact, depending on how you've used the destination wallet, it may be resistant to quantum computers today!

The obvious way would, of course, be if a new post-quantum signature algorithm was implemented in the code. Simply generate a new keypair and use it, likely by configuring it as a regular key for the destination account and disabling the master key. Tada.

But even if no post-quantum signature algorithm was implemented, you could still secure the destination account using existing algorithms. The idea would be to generate a new ECDSA or Ed25519 keypair, and configure that as the account's regular key while disabling the master key. This may see a bit weird at first. After all, if this is a regular ECDSA or Ed25519 keypair, what makes it secure?

It all boils down to algorithms and safety margins.

We may not have general purpose quantum computers right now, but we do have quantum algorithms and two are of concern: the first is known as Shor's algorithm. It's fast, but you can only use it in some cases. The other is Grover's algorithm. It works all the time but it's slow. I'm playing a bit fast and loose with the definitions of "fast" and "slow" here, and this isn't the whole story, but just go with it for now.

In order to be able to use Shor's algorithm, your public key must be known. In Ripple (and Bitcoin too) only the hash of the public key is known; the public key remains unknown (unless the holder chooses to publish it ahead of time for some reason) until a valid transaction is presented. That's why I said earlier that some wallets may be resistant to quantum computers today.

So, if no transaction is made, then a quantum attackers doesn't have the information needed to launch a "fast" Shor attack, and is instead, forced, to use Grover's "slow" algorithm.

Share this post


Link to post
Share on other sites

The story is slightly different for escrows that are held based on crypto-conditions instead of time-locked. If the hash function is broken so people can easily create hash collisions, then someone could make their own valid fulfillment and release the funds without going through the person who was supposed to release it. That said, as far as I've seen SHA-256 (currently used by all crypto-conditions in the XRP Ledger) isn't any more likely to be broken by quantum computers than just regular computers. And even in the case that something's released, it still only goes to the intended destination address, which is set when the escrow is created. As long as the destination address is locked with a secure key (as Nik describes) then it's not like some third party can steal the funds. But really, conditional escrows are meant for short-term locks (Interledger payments, which should take seconds to hours depending on the slowest link in the chain) not multi-year lockups.

I'm more concerned about Ripple's "Year 2068 problem" where the XRP Ledger's 32-bit time format overflows. You can't even schedule time-based escrows to expire past then! And upgrading the timestamps will involve modifying the ledger header, which is one of the oldest, crustiest, hardest-to-update pieces of the XRP Ledger. The good news is, that particular deadline is approaching at a very predictable rate. ;)

Share this post


Link to post
Share on other sites
15 minutes ago, mDuo13 said:

someone could make their own valid fulfillment and release the funds without going through the person who was supposed to release it

Just to be clear: This does NOT mean that funds can be released TO anyone who manages to break the preimage-SHA256, it means that they can be released BY anyone who manages this. The only ones that would benefit from such cases would be someone hoping that funds are released towards them instead of the Escrow being cancelled.

As already said, the weakest crypto primitive for quantum computers is definitely a published public key, not a SHA256 hash.

Share this post


Link to post
Share on other sites
18 hours ago, mDuo13 said:

I'm more concerned about Ripple's "Year 2068 problem" where the XRP Ledger's 32-bit time format overflows.

Why was the decision made to use a 32-bit time format?! :) Is there a significant performance benefit or was it an oversight?

Share this post


Link to post
Share on other sites
On 1/26/2018 at 2:10 PM, mDuo13 said:

I'm more concerned about Ripple's "Year 2068 problem" where the XRP Ledger's 32-bit time format overflows. You can't even schedule time-based escrows to expire past then! And upgrading the timestamps will involve modifying the ledger header, which is one of the oldest, crustiest, hardest-to-update pieces of the XRP Ledger. The good news is, that particular deadline is approaching at a very predictable rate.

Sounds very familiar to the Y2K issue, however Y2K was mostly hype.

Y2.068K (or is it 2038?)sounds like a real problem, and banks will never buy into anything with such a short life span.  Your post presents a major concern. Why such a short life span? Also you stated that this is not easily fixed. I doubt your intention was to de-rail XRP, but I am uncomfortable knowing that Ripple has a life expectancy that does not go beyond infancy, when measured in bank years.  Even bridges are designed to last at least 100 years.

Edited by Valhalla_Guy
added 2038 date

Share this post


Link to post
Share on other sites
10 hours ago, Valhalla_Guy said:

Sounds very familiar to the Y2K issue, however Y2K was mostly hype.

Y2.068K sounds like a real problem, and banks will never buy into anything with such a short life span.  Your post presents a major concern. Why such a short life span? Also you stated that this is not easily fixed. I doubt your intention was to de-rail XRP, but I am uncomfortable knowing that Ripple has a life expectancy that does not go beyond infancy, when measured in bank years.  Even bridges are designed to last at least 100 years.

@JoelKatz, are you able to comment on this?

Share this post


Link to post
Share on other sites
11 hours ago, Valhalla_Guy said:

Sounds very familiar to the Y2K issue, however Y2K was mostly hype.

Y2.068K (or is it 2038?)sounds like a real problem, and banks will never buy into anything with such a short life span.  Your post presents a major concern. Why such a short life span? Also you stated that this is not easily fixed. I doubt your intention was to de-rail XRP, but I am uncomfortable knowing that Ripple has a life expectancy that does not go beyond infancy, when measured in bank years.  Even bridges are designed to last at least 100 years.

This is not really a serious problem nor a "big concern". The timestamp format has the "zero" point as January 1, 2000, and the counter is 32-bits worth of seconds so what... 135 years or so. That gets us to 2130. I figure we can get started on this in a little early just to be safe. Sometime around 2100 sounds reasonable.

Share this post


Link to post
Share on other sites
8 minutes ago, nikb said:

This is not really a serious problem nor a "big concern". The timestamp format has the "zero" point as January 1, 2000, and the counter is 32-bits worth of seconds so what... 135 years or so. That gets us to 2130. I figure we can get started on this in a little early just to be safe. Sometime around 2100 sounds reasonable.

Thank you so much for the answer. Your time frame for XRP's life cycle, greatly exceeds the time expectancy of my body, so I am relieved.

Let me say, I worked through Y2K, and I wish this conversation could be time capsuled... History repeats itself, and I can laugh wondering how close, to the 'last minute', folks will wait, before getting started on the fix.

Share this post


Link to post
Share on other sites

On the question of Quantum computers, they definitely have the potential to render current Cryptocurrencies obsolete, as whilst present public key /private key schemes are fairly impenetrable to conventional attack (lots of parallelism and decades/hundreds of years would be needed), a Quantum computer of sufficient Quibits (not available yet)could tackle this problem very rapidly. Look up Shor’s algorithm for more info.

That said, this is easier to solve long term, I could envisage leveraging some of the Quantum Encryption that is coming in stream for comms, so perhaps CryptoCoins will be Replaced with Quantum CryptoCoins.

 

Share this post


Link to post
Share on other sites

@Valhalla_Guy FYI this is similar but on a different level to Y2K. It's the same sort of thing as the 32-bit Unix time overflow problem that's a real problem that the rest of the world will already have dealt with by 2038. Unix time started in 1970, vs XRPL's 2000, so we have more time. Plenty of time.

@mDuo13 says we have until 2068, @nikb says 2130; it depends whether a signed or unsigned integer is used, out of interest which is correct? I couldn't find an answer on the Ripple dev site.

Edited by at3n

Share this post


Link to post
Share on other sites
5 minutes ago, at3n said:

@Valhalla_Guy FYI this is not so equivalent to Y2K, it's similar to the 32-bit Unix time overflow problem that the rest of the world will already have dealt with by 2038. Unix time started in 1970, vs XRPL's 2000, so we have more time.

@mDuo13 says we have until 2068, @nikb says 2130; it depends whether a signed or unsigned integer is used, out of interest which is correct? I couldn't find an answer on the Ripple dev site.

If a signed integer is used, changing it to an unsigned is trivial: do nothing but simply start interpreting the 32 bits as unsigned rather than signed.

Share this post


Link to post
Share on other sites

×