Jump to content

Had two XRP wallets cleared out.


ChavasRegal

Recommended Posts

  • 3 weeks later...
On 1/12/2018 at 9:24 AM, gtyj said:

Thanks @MooseInTime I was looking at the infinitesimally small chance that the secret was brute-forced hacked:  

A Ripple wallet secret is 30 characters long. Each characters can be either an upper case letter, a lower case letter or a number except for the first character (which must be an s). There are 26 lower-case letters in the english alphabet(a-z) and 26 upper-case letter in the english alphabet (A-Z) and 10 1-digit numbers (1-9).
 
That means every character except for the first one in a secret can be one of 62 possibilities. This means that for brute force hacking to take place on a 30 character secret the hacker would have to guess 62^29 times which is 9.5358409*10^51 guesses!!

This isn't really correct... there isn't a valid ripple address for every combination of 30 characters. Even if there were, those 30 characters aren't the full a-z, A-Z, 1-9 space--ripple addresses are encoded in Base58, which means for every characer you have 58 possibilities. The reason for this is that it avoids things like lowercase l and capital I which look almost the same but are not actually the same. Additionally, even within this keyspace, not every possible combination is a valid ripple address either. In order to find the actual number of real valid addresses (called the 'keyspace') you use the step in the process of key generation that has the least entropy. For ripple, this happens to be the RIPEMD160 hashing algorithm (you can see the documentation for this process here https://ripple.com/build/accounts/#address-encoding) which has a 160 bit output. This means that the total number of possible valid ripple addresses is 2^160, or about 1.5 * 10^48, several magnitudes lower than the 62^29 figure. That said, it's still a ridiculous amount of possibilities and so the likelihood of a pure bruteforce is very very low.

On 1/12/2018 at 6:54 AM, gtyj said:

Interesting tidbit, this code was apparently forked from some original code by Mike Hearn for bitcoin you can see the reference on line 63, screenshot below:

image.png.f46ff76c0982db432506da9666527bd4.png

There is a reference to a link for documented bugs in the original code. This link is on line 6612

image.png.6ee3f5484926afb43306f66ffca78692.png

I'm checking the latest bugs reported, they can be found here https://github.com/indutny/elliptic/issues and the home page for elliptic is here https://github.com/indutny/elliptic Maybe the creator of this wallet got much of the algorithmic heavy lifting done in the forked code, so he/she might not even be aware of the inner mathematical workings of it. 

Elliptic (used by the ripple-keypairs npm package, which is used in the official ripple-lib npm package and used by this generator) uses crypto.getRandomValues(), which is a JavaScript API that calls a browser-specific implementation of a CSPRNG (cryptographically secure pseudorandom number generator). This is why there was the big "DONT USE ON SAFARI" warning for this and other genrators: old versions of safari did not implement this function in a secure way. You can verify this by looking at lines 2606-2660 in the source for the generator. The bitshifting, modulus, etc, you or someone else mentioned in an earlier post is all doing operations for the elliptic curve functions that are used to generate the cryptographic public-private key pair, not generating random numbers.

Anyway, in conclusion, it's very likely this generator is not inherently compromised, but rather that some form of malware or user error related opsec violation resulted in the XRP being lost.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...