Secret Key doesn't match public key

[T8493]

42 minutes ago, pftq said:

Well not all wallets; my wallet doesn't have that issue.

1

If you don't observe this behavior on some small number of test cases, that doesn't mean it doesn't exist in some other cases. 

Until the exact reason for this is found, I think it is prudent to give a warning to the users to not use Safari (at least on Mac).

These bugs can sometimes appear only under some special circumstances, e.g. this bug in ethereumjs library:

https://www.reddit.com/r/ethereum/comments/47nkoi/psa_check_your_ethaddressorg_wallets_and_any/

[Guest]

So for clarity...   are we talking about the wallet generated (if using Safari) from this link:

https://ihomp.github.io/ripply-paper-wallet/coldwallet-SHA1-cdfbe3260927b6073180a1099f02ef99ce0495e8.html

which comes from this beginner tutorial on XRPChat:

 

[pftq]

The relevant part of the code as Hantzen said is here.  For context, those functions being called don't even exist anymore in the current Ripplelib.  The bug I was aware of from May (and which again has a fix here) affected the bignumbers library (see: https://github.com/MikeMcl/bignumber.js/issues/120).  The newest version of ripplelib simply froze, but my guess is the older version might have generated different numbers and kept going.  For context again, the newest version of ripplelib freezes even when signing a transaction with a secret key, so the functionality to decrypt/encrypt keys is simply gone for Apple users, which means it's a bit random as to what it might have done if it didn't freeze and kept going.

function generateAddress(secret) {
	if (secret) {
		secret = ripple.Seed.from_json(secret);
	} else {
		secret = ripple.Seed.from_bits(ripple.sjcl.random.randomWords(4));
	}
	return {
		secret: secret.to_json(),
		address: secret.get_key().get_address().to_json()
	};
}

 

Edited August 5, 2017 by pftq

[Guest]

2 minutes ago, pftq said:

 The newest version of ripplelib simply froze, but my guess is the older version might have generated different numbers and kept going. 

So does that mean wallets generated in recent weeks from the Beginners Guide link will not have the problem?

[pftq]

41 minutes ago, Tinyaccount said:

So for clarity...   are we talking about the wallet generated (if using Safari) from this link:

https://ihomp.github.io/ripply-paper-wallet/coldwallet-SHA1-cdfbe3260927b6073180a1099f02ef99ce0495e8.html

which comes from this beginner tutorial on XRPChat:

 

I can't tell from looking at the code what version of ripplelib it uses or whether the author addressed the bignumbers.js bug.  It seems to be using a newer version of the library at least based on the code block below (notice it doesn't use .to_key(), .to_json(), etc but instead the newer deriveMethods from the alter APIs), but the github hasn't been updated since last year so it's unlikely to have accounted for the new Apple javascript changes: https://github.com/ihomp/ripply-paper-wallet  It's possible they addressed it a year ago from the get-go or modified ripplelib before they used it because they're not using the actual ripplelib library, just bits and pieces of it.  Again hard to tell just by looking at it; you'd have to ask them.

window.generateWallet = function(){
    var seed = rk.generateSeed();
    var keypair = rk.deriveKeypair(seed);
    var address = rk.deriveAddress(keypair.publicKey);
    return {"address" : address, "secret" : seed};
  } 

My suggestion would be to perhaps test your secret+address key combination on a few wallets to make sure it's valid before putting money in.  You can disconnect from the internet before running anything if you're concerned that they could store or save your information online.  For mine (www.theworldexchange.net), you can input the secret key alone or in combination and it'll tell you both the correct account address as well as if your keys don't match.  I'm not trying to promote my own site; it's just the only one I know has specifically addressed the Javascript change from Apple this year.  If you want to avoid trusting any one wallet, then you can also just go down the list and try a bunch of them.

Edited August 5, 2017 by pftq

[Guest]

Pftq many thanks for that....    So if the link in the Beginners Guid is to the affected code.... 

Shouldnt the Beginners Guide be immediately adjusted to PROMINENTLY WARN new users of the Apple (not Safari....  new users remember) bug?

[karlos]

18 minutes ago, Tinyaccount said:

Pftq many thanks for that....    So if the link in the Beginners Guid is to the affected code.... 

Shouldnt the Beginners Guide be immediately adjusted to PROMINENTLY WARN new users of the Apple (not Safari....  new users remember) bug?

Sounds fair, I will hide the guides for now, until we know whats going on. Right now we don't know which wallets are using old ripple-lib. As @pftq mentioned, the following wallets freeze in Safari:

• ripplerm Wallet
• Toast Wallet
• Yxxyun online wallet

But so far Ive tested all the "browser" based wallets, and none of them exhibit the same secret key/public key mismatch as jatchili in Safari. 
 

Edited August 5, 2017 by karlos
typo

[Guest]

Karlos thanks for that.  This is a particularly nasty and insidious bug because everything would look ok if you examined the ledger for the public address.  Users might never use that secret key until the day they stop hodling and want to sell.  

Then they discover the XRP they thought they had is forever inaccessible.

So sorry for your loss OP.   At least you found out early....   would be much worse to think you have a new fortune for ages then finally discover it's out of reach.

i wonder how many people are in that boat?    

Edited August 5, 2017 by Guest
Format

[Guest]

How hard would it be for someone here to create a page or a program which only checks that the key matches the public address?  Something that can be code inspected by the community, and maybe David/Joel, to give the already rattled user some confidence that the secret is not being stored by the website?

Obviously there is the local keylogger risk, but unless they offline sign and verify,  there is no way for the users of the simple wallet generator to know they are ok.  And the reason they used the simple wallet was likely a reluctance or inability to use a more thorough and difficult offline method.

There are at least three reasons we should address this problem urgently:

1)   As a community (I know I'm only new here...) we have a responsibility to those who followed our advice to try to assist them with this issue however we can.

2)   Real world folk can get a real world hurt and financial loss and worry from this issue.

3).  I think this bug has the potential to disproportionally blow up in the media and put a significant dampener on any enthusiasm for XRP.  I realise it's only a certain subset of a certain group that are potentially affected by this, but just as a rising tide lifts all boats, a gale of unrest will rock all in the harbour.

[Guest]

Please @karlos add BitGo to the list of wallets in the Links and Resources page.

Also perhaps mention there, that this is the only  wallet that is officially endorsed by Ripple. That means, any other wallet: use at your own risk.

Edited August 5, 2017 by Guest

[Guest]

Thanks for suggesting that Lucky.   (Presumptive of me to thank...   but I'm sure we are all of the same mind on this..)

Can bitgo allow a test of the secret key like @pftq wallet at Worldexchange can?   Not challenging... Just asking.

[pftq]

6 hours ago, Tinyaccount said:

How hard would it be for someone here to create a page or a program which only checks that the key matches the public address?  Something that can be code inspected by the community, and maybe David/Joel, to give the already rattled user some confidence that the secret is not being stored by the website?

Obviously there is the local keylogger risk, but unless they offline sign and verify,  there is no way for the users of the simple wallet generator to know they are ok.  And the reason they used the simple wallet was likely a reluctance or inability to use a more thorough and difficult offline method.

There are at least three reasons we should address this problem urgently:

1)   As a community (I know I'm only new here...) we have a responsibility to those who followed our advice to try to assist them with this issue however we can.

2)   Real world folk can get a real world hurt and financial loss and worry from this issue.

3).  I think this bug has the potential to disproportionally blow up in the media and put a significant dampener on any enthusiasm for XRP.  I realise it's only a certain subset of a certain group that are potentially affected by this, but just as a rising tide lifts all boats, a gale of unrest will rock all in the harbour.

For my site (https://www.theworldexchange.net), if you enter a secret key that doesn't link up to the account address, it'll give you an error.  You can also recover the address by only entering the secret key.  You can download the page and go offline to do this check (as well as generate wallets) if you're worried about logging.  The page is also open-source (like any pure HTML/javascript page) by just right-clicking and hitting view source.  The specific code block for checking secret key against wallet address is below, which I've commented up for your convenience.  The derive functions are part of ripplelib but hidden, so I had to modify ripplelib to make them  usable; you can find that change also in the source code by looking for "// pftq" in the added lines to ripplelib.

// Login and check validity of secret key + address combination.  Works offline!
function saveLogin() {
  if(loggingIn) return;
  else loggingIn = true; // Avoid logging in twice if the user keeps clicking
  if($("#disclaimerRead").prop("checked")==true) {
  
    // Assume invalid by default
    var validKey = false;
    var error = "<br />Check and re-enter your secret key.";
    
    try {
      // Allow read-only mode if left blank
      if($("#keyInput").val()=="") {
        validKey = true;
        saveLogin2(validKey, error);
      }
      
      // Otherwise analyze it
      else {
        // Custom-modded ripplelib to expose deriveKeypair for checking validity of the secret + address
        var pair = api.deriveKeypair($("#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)==$("#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($("#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);
            });
          }
        }
      }
    }
    catch (ex) { // invalid secret key format
      error = "<br />"+ex;
      saveLogin2(validKey, error);
    }
  }
  else {
    // Disclaimer box unchecked
    $("#disclaimerAgreement").css("border-color", "red");
    loggingIn = false;
  }
}

 

Edited August 6, 2017 by pftq

[BAX]

13 hours ago, lucky said:

Please @karlos add BitGo to the list of wallets in the Links and Resources page.

Also perhaps mention there, that this is the only  wallet that is officially endorsed by Ripple. That means, any other wallet: use at your own risk.

BitGo is not a consumer wallet! You and I can't use it unless you are enterprise custumer!

[supersonic]

19 hours ago, Tinyaccount said:

So for clarity...   are we talking about the wallet generated (if using Safari) from this link:

https://ihomp.github.io/ripply-paper-wallet/coldwallet-SHA1-cdfbe3260927b6073180a1099f02ef99ce0495e8.html

which comes from this beginner tutorial on XRPChat:

 

No, I used the minimalist client from this link: https://github.com/jatchili/minimalist-ripple-client

[Guest]

5 hours ago, supersonic said:

No, I used the minimalist client from this link: https://github.com/jatchili/minimalist-ripple-client

So is anyone here able to say if the bug affects https://ihomp.github.io/ripply-paper-wallet/coldwallet-SHA1-cdfbe3260927b6073180a1099f02ef99ce0495e8.html ?