Jump to content
codiusrex

Ripple: Only XRP Private Keys That Used Software From Before August 2015 Are Vulnerable

Recommended Posts

Guest

And there's a thread in "Technical Discussion" if that's what you're into. 

 

Share this post


Link to post
Share on other sites

If you had signed trans prior to the date mentioned in the FAQ then there is a small risk that your key could be determined.

Two ways to fix it.  Create a new account...  ie a new paper wallet,  an app like ToastWallet, or a desktop wallet software.  Then transfer your xrp into the new wallet.  You’ll still have 20 xrp reserved in the old wallet.

Alternatively you could just create a Regular Key, for your existing wallet using up to date software and then test the new key by signing a small transaction with it.  Once sure it works then you can disable the master and you are no longer at risk.

Share this post


Link to post
Share on other sites

I understood it differently. You  can sign transactions long after the Aug, 2015 date and still be vulnerable.  It depends on the software used to sign transactions; however, most should be safe if they don't currently use questionable software (poor quality software creating nonces that don't have sufficient randomness in them), or they've used good, updated software (e.g., software using deterministic nonce generation like in the case of older wallets using nonces generated by ripple wallet libraries whose version was created in Aug. 2015 or later).

In my case, I was using my favorite wallet to sign transactions even as late as 2017.  That wallet software had the last version come out in late 2016, but the ripple-lib portion of that wallet responsible for taking care of this issue was older than the wallet itself, coming from early 2016 or before, so I was sort of cutting it close.

 

Edited by enrique11
correction highlighted

Share this post


Link to post
Share on other sites
2 hours ago, WrathofKahneman said:

Any idea if the later Rippex wallet is outside the threat window?

Yes, they're supposed to be safe according to Ripple.  For example, the last version of rippex wallet for Linux (I would assume it's OK for other platforms as well like Microsoft and MacOS if they were updated at similar times and are basically using the same mechanism to generate nonces, but honestly I don't know how the process works for other platforms, upgrading and stuff and the libraries used and if they are basically updated at similar times with similar versions of ripple-lib - I just use Linux, so I am only confident about the system I use and the wallet created for it.) used ripple-lib version 0.13.0-rc14, and if you look at the following link that I posted yesterday in a similar thread (https://github.com/ripple/ripple-lib/commits/develop?after=dc148bf95441f8ad879026f8cb2473be4d6f055f+699), the "Bump version to 0.13.0-rc3" reference at the bottom of the linked page, you see that the earliest version of ripple-lib that's supposedly safe that I could find in August of 2015 was created on August 4, 2015 and is version 0.13.0-rc3, so any version of ripple wallet that's using ripple-lib version 0.13.0-rc3 or greater should be safe.  So even later wallet versions of rippex (not necessarily the last version) should be safe as long as they use a ripple-lib version that's at least 0.13.0-rc3.

I'm still just learning about github commands like 'commit' and 'push'.  'Commit' records changes to a local github repository, but the link I referenced above looks like it's on the main github ripple repository, so it should it should be OK because the wallet software should be using these versions, but again...I just started briefly going over these commands yesterday, and didn't really look in depth into them and don't understand them fully.

 

Edited by enrique11
additional comment

Share this post


Link to post
Share on other sites

In any case, I think we all should not be so worried about this because the researches that found this vulnerability, found a number of vulnerable BTC and ETH wallets, but only found one ripple wallet that was vulnerable if I recall correctly - I should post the link in this thread if I come across it again.  I don't know the sample size of wallets they tested from various coins or how many BTC and ETH wallets they found to be vulnerable, but if my memory serves they did make it sound significantly worse for BTC and ETH than for XRP.

Edited by enrique11

Share this post


Link to post
Share on other sites

In any case, the odds are very low and generally requires a substantial amount of work by the attackers that might not be worth the effort unless the wallet has high value:

https://cryptoslate.com/researchers-discover-vulnerability-bitcoin-ethereum-ripple-digital-signatures/

Quote

Furthermore, as long as developers use the proper techniques and documented methods to ensure user security, the signature scheme is considered secure:

“As far as we know, ECDSA is a secure digital signature algorithm if implemented correctly. We concluded that these were not common implementations based on the fact that we only found a few thousand vulnerable signatures out of nearly a billion Bitcoin signatures that we examined.”

And here we have the actual data from the paper published by the researchers I've highlighted the relevant data using the bold version of the font:

https://eprint.iacr.org/2019/023.pdf

Quote

7 Ripple

Collecting data.

We downloaded a portion of the Ripple blockchain that

included 218,101,343 signatures. There were 571,482 unique public keys, of which

379,575 had generated more than one signature, totaling 217,909,436 signatures

(99%) that were generated by a key that had been used more than once.

Running the cryptanalysis.

We clustered signatures by public key, and

examined the keys that had generated more than one signature. We ran the

same tests as for Bitcoin. The total computation time took 1.1 CPU years, and

the longest single computation took 5 calendar days for a single key that had

generated 361,366 signatures.

Results and analysis.

We found one private key that had been compromised

by a repeated signature nonce. This key had generated 21 signatures. It holds

30.40 XRP (approx. 14 USD) and 1.81 CNY. We deduce that attackers have not

yet begun to systematically observe the Ripple blockchain for repeated nonces.

8 SSH

Collecting data.

We gathered DSA and ECDSA signatures from Internet-wide

scans of SSH on port 22 that were performed by Censys [

17

] between April 3,

2018 and September 18, 2018. The scans contained between 7.9 million and 9.4

million DSA and ECDSA signatures each, for a total of 196,884,009 signatures

from 20,103,764 distinct public keys. These included 191,855,472 NIST P-256

signatures, 2,634,869 DSA signatures, 2,095,181 NIST P-521 signatures, 164,919

NIST P-384 signatures, and 133,568 ed25519 signatures.

Running the cryptanalysis.

The SSH dataset included a wide variety of

different DSA groups. We ran the tests described in Section 5.2, scaled to the

relevant group size. The total computation time was 2.8 CPU-years, and the

longest computation took 8 days to process the most common key, which had

been used for 1,450,916 signatures from our scans.

Results and analysis.

256-bit keys with 32-bit shared suffixes.

Three private keys produced signatures

whose nonces all shared the suffix

f27871c6

. The hosts have gone offline since,

and we were unable to identify the implementation. This suffix is one of the

“constant words” used in the calculation of a SHA-2 hash [

24

], with swapped byte

order. We can can speculate that the server is using SHA-2 to generate the nonce,

but has a bug in the implementation.

Biased Nonce Sense

15

224-bit keys with 160-bit nonces.

One further key was compromised due to the

use of small nonces. All 23 signatures by this key used a 160 bit nonce with

a 2048-bit DSA public key with a 224-bit subgroup, and were observed at the

same IP address. We speculate that this may be due to the use of a 160-bit hash

function like SHA-1 or MD5 being used to generate the nonce in a 224-bit group.

Repeated nonces.

681 signatures were compromised by repeated nonces. Of these,

612 used DSA, and 69 used ECDSA with NIST P-256. These came from 34

distinct public keys on 80 distinct IP addresses.

We compared this number to repeated nonces found in a March 25, 2012 scan

of SSH that requested only DSA host keys provided by the authors of [

18

]. In

the 2012 scan, 22,182 nonces had been used more than once, and 58 distinct keys

were vulnerable on 24,893 distinct IP addresses. We conclude that many of these

vulnerable implementations have been taken offline or patched since then.

9 HTTPS

Collecting data.

We gathered ECDSA signatures from weekly Internet-wide

scans of HTTPS on port 443 performed by Censys [

17

] between April 3, 2018

and September 6, 2018. The number of ECDSA signatures per scan increased

from 1.5 million to 1.9 million, resulting in 50,313,795 total ECDSA signatures

from 182,843 distinct keys on 3,333,482 distinct IP address. 50,096,848 signatures

were from NIST P-256, 212,523 were from NIST P-384, 4,400 were from NIST

P-521, and 24 were from NIST P-224.

Running the cryptanalysis.

We ran the same sequence of tests as described in

Section 5.2, scaling the number of bits to the curve order. The total computation

time was 152 CPU-days, and the longest computation took 17 days to process a

single key that had produced 4,093,917 signatures from our scan.

Results and analysis.

We did not find any small or biased signature nonces.

We found three different sources of signatures with repeated nonces, which we

hypothesize are due to flawed random number generators. These resulted in 462

vulnerable signatures that had been generated by 7 distinct private keys on 97

distinct IP addresses.

 

Edited by enrique11

Share this post


Link to post
Share on other sites
17 minutes ago, enrique11 said:

generally requires a substantial amount of work by the attackers

2 signatures with the same nonce and you have the private key in fractions of a second.

The only "hard" part is going through all signatures that were made so far (the researchers in that report only tested a subset of all transactions on XRPL), which can be probably done for a few cents using the transaction dataset on Google BigData.

Share this post


Link to post
Share on other sites
22 hours ago, Tinyaccount said:

 

Two ways to fix it.  Create a new account...  ie a new paper wallet,  an app like ToastWallet, or a desktop wallet software.  Then transfer your xrp into the new wallet.  You’ll still have 20 xrp reserved in the old wallet.

Alternatively you could just create a Regular Key, for your existing wallet using up to date software and then test the new key by signing a small transaction with it.  Once sure it works then you can disable the master and you are no longer at risk.

how comfortable you are with keeping funds in Nano ledger Vs paper wallet/toast wallet. ?

how much technical knowledge is required to create a regular key for existing wallet, how to do it, if my crypto is sitting with gatehub ripple wallet ?

 

Share this post


Link to post
Share on other sites
On 1/20/2019 at 8:01 AM, Tinyaccount said:

If you had signed trans prior to the date mentioned in the FAQ then there is a small risk that your key could be determined.

Two ways to fix it.  Create a new account...  ie a new paper wallet,  an app like ToastWallet, or a desktop wallet software.  Then transfer your xrp into the new wallet.  You’ll still have 20 xrp reserved in the old wallet.

Alternatively you could just create a Regular Key, for your existing wallet using up to date software and then test the new key by signing a small transaction with it.  Once sure it works then you can disable the master and you are no longer at risk.

Do you (or anyone can chime in) have step by step instructions on how to go about using the last option ?.  I'm now using Toast Wallet on iOS

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...