Jump to content
Trader-to-the-Crown

Need advice for testing my secret key offline for an XRP paper wallet.

Recommended Posts

So I know that I can test my secret key for my paper wallet by importing it into Toast Wallet, but that defeats the whole purpose of holding long term in a paper wallet.

I dont want to expose my secret key to a 3rd party wallet software like Toast or Gatehub until I am ready to sell. Once I expose the key to a 3rd party service, I lose the security advantages of having the paper wallet, and yet until I test my secret key I am not comfortable moving my XRP balance into my paper wallet. Feels like a damned if you do, damned if you dont situation.

I heard there is a way to test it offline with something called (nodeJs)? Does anyone know how to do this?

Seems somebody on Reddit is in a similar predicament, but they've yet to get an answer on this either.

Edited by Trader-to-the-Crown

Share this post


Link to post
Share on other sites
10 hours ago, Trader-to-the-Crown said:

I heard there is a way to test it offline with something called (nodeJs)? Does anyone know how to do this?

Node.js is a javascript environment (a computer program that can execute javascript).

Ripple-lib (https://github.com/ripple/ripple-lib) is javascript code that can be used to interact with the XRP Ledger.

To use ripple-lib you need to be able to configure a javascript environment (node.js or otherwise), and then write javascript code to perform some XRPL-related function.

You can use ripple-lib to create and sign a transaction offline, and then take the signed transaction to a similar online environment to submit it to a rippled server. There are tutorials to help you do this, but it's not easy if you don't have programming experience. If the transaction that has been created offline using your own code and secret key is validated by the Ripple network, that proves that your secret key is genuine (if you trust ripple-lib).

These are the sort of lengths you need to go to if you're not willing to expose your secret key to some other third-party software like Gatehub/Toast/Rippex.

 

You can also use well-known wallets like Rippex or ripplerm to sign transactions offline and then move them to an online PC to submit them using the same software. In this case you're trusting that the wallet software is trustworthy, as the offline side of it could create any transaction that it wants using your secret key (I'm not saying that it would, but it could).

10 hours ago, Trader-to-the-Crown said:

until I test my secret key I am not comfortable moving my XRP balance into my paper wallet. Feels like a damned if you do, damned if you dont situation.

Your reasoning is sound, in my opinion; a paper wallet is unsuitable unless you can securely verify the secret key - which the majority of people are unlikely to be able to do.

Edited by at3n
Spelling

Share this post


Link to post
Share on other sites

@at3n

Thanks so much for the reply. For a moment I considered trying to go deeper, but honestly it sounds like the steps are a bit beyond me.

I don't seem to see this complaint that I have when looking at other threads with people creating paper wallets. Do people for the most part just trust that as long as the public key works the secret key is bound to work?

Are the chances of getting a faulty secret key pair (in my case, from BitThomp) astronomically low? I hate to be paranoid. It seems there are a ton of people with paper wallets, but very little discussion on testing the secret key offline.

Somebody said it was possible to test if a secret key matches up to it's public key properly on theworldexchange.net, but they didn't go into detail on how to do it and I have a feeling it isn't something I can do offline...

Share this post


Link to post
Share on other sites
6 minutes ago, Trader-to-the-Crown said:

@at3n

Thanks so much for the reply. For a moment I considered trying to go deeper, but honestly it sounds like the steps are a bit beyond me.

I don't seem to see this complaint that I have when looking at other threads with people creating paper wallets. Do people for the most part just trust that as long as the public key works the secret key is bound to work?

Are the chances of getting a faulty secret key pair (in my case, from BitThomp) astronomically low? I hate to be paranoid. It seems there are a ton of people with paper wallets, but very little discussion on testing the secret key offline.

Somebody said it was possible to test if a secret key matches up to it's public key properly on theworldexchange.net, but they didn't go into detail on how to do it and I have a feeling it isn't something I can do offline...

Look for posts by myself and @Kakoyla about using the Ripplerm wallet offline. It requires a fair bit of reading and fiddling but will reliably accomplish what you seek. Just make a new wallet and fund it with the minimum reserve to play around with before you touch your cold wallet key(s).

Share this post


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

Look for posts by myself and @Kakoyla about using the Ripplerm wallet offline. It requires a fair bit of reading and fiddling but will reliably accomplish what you seek. Just make a new wallet and fund it with the minimum reserve to play around with before you touch your cold wallet key(s).

Thanks.

I just gave you your 1000th like.

I feel special. :)

It sounds like this is what I might need to do. I will look up the posts.

Edit: if anybody else has more input I would still like this thread to grow a bit in discussion on it.

Edited by Trader-to-the-Crown

Share this post


Link to post
Share on other sites
9 hours ago, Trader-to-the-Crown said:

I don't seem to see this complaint that I have when looking at other threads with people creating paper wallets. Do people for the most part just trust that as long as the public key works the secret key is bound to work?

I don't honestly know how much people think about it, but for the most part, I think people just trust the popular wallets/key generation tools. Of course, this tends to be fine in most cases, but what if they happen to find a hacked version, or a wallet that everyone thought was safe is not? The Safari ripple-lib bug caught a lot of people out about a year ago, there are plenty of posts to prove it, so these things can happen. Given that you're suspicious enough to be asking these questions, I think that you're being more careful than most people.

9 hours ago, Trader-to-the-Crown said:

Are the chances of getting a faulty secret key pair (in my case, from BitThomp) astronomically low? I hate to be paranoid. It seems there are a ton of people with paper wallets, but very little discussion on testing the secret key offline.

I'll admit that I don't understand the maths behind cryptographic algorithms, but I think that the risk is not that the algorithms will make a mistake, but that either the service (e.g. Bithomp) will not implement the algorithm correctly, or else will deliberately give you the wrong keys in order to steal from you (I'm not accusing Bithomp here of anything, just using it as an example of a service that people trust). Another point to consider is that the key pair might be valid but the software could be generating pre-determined or predictable keys, so that the wallet developer can watch the wallets created by it and steal everything when they start filling up.

9 hours ago, Trader-to-the-Crown said:

Somebody said it was possible to test if a secret key matches up to it's public key properly on theworldexchange.net, but they didn't go into detail on how to do it and I have a feeling it isn't something I can do offline...

theworldexchange can be saved offline and you can use it offline to compare secret keys and wallet addresses (using the login link), but you're still trusting that the site is a) programmed correctly, b) not malicious and c) not hacked. Any fully offline check will not be able to actually submit the transaction to the network, which is arguably the only definitive way to verify that the secret key is correct (unless you understand the maths from first principles and can follow every calculation in the code).

Edited by at3n
Elaborated

Share this post


Link to post
Share on other sites
8 hours ago, at3n said:

theworldexchange can be saved offline and you can use it offline to compare secret keys and wallet addresses (using the login link), but you're still trusting that the site is a) programmed correctly, b) not malicious and c) not hacked

All of that is true but unless you are willing to create a transaction offline to test the key,  then I personally think for many people theworldexchange gives the easiest and safest test.  I am not an expert and anything I say could be wrong but as I understand it....

lets look at the risks mentioned...   

A) programmed correctly.

 Unless theworldexchange has exactly the same error in its code as the paper wallet software that you used,  then it's exceedingly unlikely that the two software programs will come up with the same public address from the same secret key unless in fact it is the correct address.  So if theworldexchange.net (henceforth TWE) gives the same address then odds are that your secret key/ public address combination is correct.

b)  not malicious

Its hard to say in an online world,  but user pftq on here has been around for a while and has often been most helpful and knowledgable.  Let's look at c)

c) not hacked.

If @pftq is malicious, or if the site was hacked, the result would be the same...  the page could capture your private key and perhaps transmit it to a bad actor.  However...  if you go into your browsers private mode before going to the site,  then after the page loads disable all network access, then do your test, then close the page,  delete cache and cookies, then close the browser before resuming normal network connectivity....  I believe you will have made it difficult (but perhaps not impossible) for a malicious piece of code to have recorded and transmitted your secret key.

To elaborate the test....  On the TWE page use the login link at top right to get the login pop up.  Enter your secret key.  Does it give the same public address as your wallet?  If so it is likely a valid combination.  Now clean up properly as advised above.  

Also during all this make damn sure that no camera in a phone, laptop or any other device can see your private key.

 

I am not an expert....  I could be wrong, and there are a LOT of ways to get this stuff wrong.  I only say all the above as a starting point for your own research.

Share this post


Link to post
Share on other sites
Guest

Ideally, you would encrypt a message with your public address (could be on an internet-connected computer, but doesn't require interaction with the XRP ledger). You would then decrypt the message on a cold computer, using your private key, thereby proving that the private key does indeed unlock the pubic address. Equivalently, you could sign a message with your private key and then validate the signature against your public key.

A javascript guru would find it easy to write a user-friendly in-brower tool to do this, probably with some minor tweaks to code borrowed from here. A while ago, I replied to a post here, offering a ridiculously convoluted alternative which illustrates the  process of proving that given secret does indeed unlock a given address. Unfortunately, my ridiculously convoluted answer was, well,  ridiculously convoluted. Nonetheless, it illustrates that @Trader-to-the-Crown is asking for something very reasonable and eminently possible using asymmetric cryptography that the XRP ledger shares with many other systems.

Edit: the relevant part of the earlier xrpchat discussion is https://www.xrpchat.com/topic/22124-how-to-prove-address-ownership/?tab=comments#comment-337515

 

Edited by Guest
Linked to the wrong point in the earlier discussion.

Share this post


Link to post
Share on other sites

I should also point out that if you install Nodejs then David Schwartz ( user @JoelKatz ) somewhere here gave the couple of lines of code needed to create a secret key.  I'm not sure if he included anything about validating an existing one but it might be worth looking into that too.  Also I think it needed the ripple lib from GitHub...  can't recall the exact name.

Share this post


Link to post
Share on other sites
On 5/5/2018 at 12:35 PM, Tinyaccount said:

Unless theworldexchange has exactly the same error in its code as the paper wallet software that you used,  then it's exceedingly unlikely that the two software programs will come up with the same public address from the same secret key unless in fact it is the correct address.  So if theworldexchange.net (henceforth TWE) gives the same address then odds are that your secret key/ public address combination is correct.

In the case of the Safari Bug with ripple-lib last year, any browser-based wallets that used ripple-lib to generate keys could generate a bad key pair when creating wallets from within the Safari browser. TWE uses ripple-lib (unless that's been changed recently). So at that time, if you generated a key pair offline with a different wallet based on ripple-lib, using Safari, chances are you would have been given an incorrect pair. If you then used TWE offline with Safari to check that key pair, then by the same bug you could possibly have been told that the false key pair was correct Edit: as per pftq's post below, TWE was not vulnerable to this bug as it was patched. But the general point is that you could have been using a wallet that was vulnerable. If I recall correctly, this was Apple's fault, not TWE or Ripple, and because it was a bug in a third-party software, it affected all wallets equally. It's not infeasible that something like this could happen again, so I wouldn't advise using offline key generators to validate previously generated keys.

On 5/5/2018 at 12:35 PM, Tinyaccount said:

Its hard to say in an online world,  but user pftq on here has been around for a while and has often been most helpful and knowledgable.

I'm in no way trying to say that pftq or TWE is not trustworthy. The OP brought up TWE, so that's what I used in my example, but my points apply to any online wallets that provide similar functionality.

Edited by at3n

Share this post


Link to post
Share on other sites
6 hours ago, at3n said:

In the case of the Safari Bug with ripple-lib last year, any browser-based wallets that used ripple-lib to generate keys could generate a bad key pair when creating wallets from within the Safari browser. TWE uses ripple-lib (unless that's been changed recently). So at that time, if you generated a key pair offline with a different wallet based on ripple-lib, using Safari, chances are you would have been given an incorrect pair. If you then used TWE offline with Safari to check that key pair, then by the same bug you could possibly have been told that the false key pair was correct. If I recall correctly, this was Apple's fault, not TWE or Ripple, and because it was a bug in a third-party software, it affected all wallets equally. It's not infeasible that something like this could happen again, so I wouldn't advise using offline key generators to validate previously generated keys.

I'm in no way trying to say that pftq or TWE is not trustworthy. The OP brought up TWE, so that's what I used in my example, but my points apply to any online wallets that provide similar functionality.

Not true.  TWE at the time did not have this bug because fixing it only required re-compiling the ripple-lib source with latest libraries/dependencies (specifically the bignumbers.js library), which is what was done to make sure TWE didn't have the issue.  The other wallets with the Safari bug were also actually running versions of Ripple Labs years behind the current version at the time.  Ripple Labs' fix to the issue in later versions was essentially that (recompiling with updated libraries, which they really should have done immediately but did not for some time).  See: 

 

 

The code for TWE already includes the Javascript code for verifying secret key with address, which as others stated can be used offline or on a disconnected computer to ensure nothing is being transmitted out.  You would end up with the same thing but w/o the other Ripple-lib functionality (trading, trustlines, etc) on the page if you wanted to create just a secret key validator.  Specifically, it is these lines below in the js file.  There are 4 lines in ripple-lib that have to also be added to expose the "deriveKeypair" and "deriveAddress" functions from Ripple Labs, which I also labeled with "// pftq" in the ripple-lib js file; I've been asking them to do this in the official release for some time (since it's just 4 lines to be able to add verification functionality).  If you guys can ask them as well, maybe they'll eventually include it so adding the lines yourself are not necessary.  Most of the code below, you'll see, is just UI updates, and all the work is being done by deriveKeypair + deriveAddress which is from Ripple Labs (look it up in the ripple-lib js file).


        var pair = api.deriveKeypair($.trim($("#keyInput").val()));
        if(pair) {
        
          // Address is derived from the public key which is derived from the secret key
          // Make sure it matches the address the user input
          var publicKey = pair.publicKey;
          //console.log("Key pair for secret given: "+pair.publicKey+" / "+pair.privateKey);
          
          // If account field is blank, we can just generate it from the secret key (technically only the secret is needed)
          if($("#accountInput").val()=="") $("#accountInput").val(api.deriveAddress(publicKey));
          
          // Else check against what they put
          if(api.deriveAddress(publicKey)==$.trim($("#accountInput").val())) {
            validKey = true;
            saveLogin2(validKey, error);
          }
          else { 
            // if we get here, it means the secret is valid but secret key doesn't match the account account
            
            console.log("Secret key failed.");
            
            // Check if it's the RegularKey instead by first looking up the RegularKey setting of the account
            api.getSettings($.trim($("#accountInput").val())).then(function(receivedSettings) {
              if("regularKey" in receivedSettings) {
                console.log("Checking against additional regularKey: "+receivedSettings["regularKey"]);
                
                // Redo the check against the RegularKey
                if(api.deriveAddress(publicKey)==receivedSettings["regularKey"]) {
                  validKey = true;
                  console.log("RegularKey matched.");
                }
              }
              // No regular key found
              else {
                console.log("No additional regularKey to check against: ");
                console.log(receivedSettings);
              }
            }, function(err) { console.log("Error getting account settings: "+err); }).then(function() {
              // If other misc errors come up, such as API errors
              saveLogin2(validKey, error);
            });
          }
        }
      
    

The trust issue is annoying, but unless there's a consensus on what you'd need to see, I don't see a way to solve it.  I could hire the same code auditor as Ripple Labs, but it would make little difference if no one bothers to look at the audit in the first place (few seem to look at the source code, for one) or if no one recognizes the name of the code auditor (can anyone here actually name the auditor for Ripple?).  On top of that, you could just say I forged the audit.

Edited by pftq

Share this post


Link to post
Share on other sites
56 minutes ago, pftq said:

Not true.  TWE at the time did not have this bug because fixing it only required re-compiling the ripple-lib source with latest libraries/dependencies (specifically the bignumbers.js library), which is what was done to make sure TWE didn't have the issue.

Apologies, I didn't realise that, I'll edit my post to reflect that. I'm not trying to bad-mouth theworldexchange at all.

It would be very hard or impossible for most users to work out things like this however, and I think that it's still good advice that in general, for something as important as verification of a paper wallet, it's better to use a wallet or code that signs a tx offline and then submit it online (or else @tev's suggestion of using the public and private keys to sign/encrypt a message and then verify/decrypt it, I like that also, although probably too complicated for many to be able to use with confidence).

Share this post


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

Apologies, I didn't realise that, I'll edit my post to reflect that. I'm not trying to bad-mouth theworldexchange at all.

It would be very hard or impossible for most users to work out things like this however, and I think that it's still good advice that in general, for something as important as verification of a paper wallet, it's better to use a wallet or code that signs a tx offline and then submit it online (or else @tev's suggestion of using the public and private keys to sign/encrypt a message and then verify/decrypt it, I like that also, although probably too complicated for many to be able to use with confidence).

That is what the TWE does already (signs offline and submits online); it's handled by Ripple-lib.  Really, pretty much any wallet that uses Ripple-lib would do that (sign offline, only submit signed tx online).  The problem with suggesting writing your own code is that if you had the technical skill to write or call Ripple-lib, you could also just verify yourself that the wallets out there are already doing the same thing.  Like you said though, it's hard for most users to verify what's using Ripple-lib or not and then even then it seems most don't realize the signing happens offline.

Edited by pftq

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...