Secret Key doesn't match public key

[PaladinStacker]

3 hours ago, supersonic said:

I'm just happy I was paranoid enough to use different generators and realising this before making my next investment with possibly another minimalist client created ID. A bit gutted about wasting my money though, my first ever bought 1361 XRPs down the drain..  

If it's any consolation, there's a lot of people who bought XRP when it was way above $0.30. I'm sure some have sold at a loss by now. 

[T8493]

46 minutes ago, JoelKatz said:

If we knew exactly what was going wrong, there's a chance we could recover the private keys. That's another reason it would be worth investigating. I wonder if offering a bounty would help or if I can generate interest inside Ripple in getting this figured out. It's a mystery. And I don't like mysteries. They give me a bellyache, and I got a beauty right now.

@supersonic should offer a bounty? Or are you (or RL) offering a bounty?

Just asking for clarification. I can't help here anyway because I don't have a Mac with Safari browser.

 

 

[Professor Hantzen]

1 hour ago, JoelKatz said:

If we knew exactly what was going wrong, there's a chance we could recover the private keys. That's another reason it would be worth investigating. I wonder if offering a bounty would help or if I can generate interest inside Ripple in getting this figured out. It's a mystery. And I don't like mysteries. They give me a bellyache, and I got a beauty right now.

I've looked into this a little just now.  All I can say is, it is really very broken.  I've done a bit of logging and apart from the above reported issues, the minimalist client under Safari also *sometimes* doesn't always agree with *itself* what the public key is from one moment to the next. I have to travel now so I can't keep looking into it - but if it helps:

1) The minimalist client is using ripple-lib version "ripple-0.12.5-rc2-min.js"
2) The problem seems to be happening somewhere here:

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()
	};
}

The "secret" passed to this function is what the user enters in the text box.  This *sometimes* has an incorrect associated public address by the end of this function.  It would be super-convenient if it was the first "else" being called accidentally - but I commented out that line, and the issue still occurs.

When modifying the code to the following:

function generateAddress(_secret) {
	console.log('before:', _secret);

	if (_secret) {
		_secret = ripple.Seed.from_json(_secret);
	} else {
		alert('should not reach here');
		//_secret = ripple.Seed.from_bits(ripple.sjcl.random.randomWords(4));
	}

	var return_object = {
		secret: _secret.to_json(),
		address: _secret.get_key().get_address().to_json()
	};

	console.log('after:', _secret);
	console.log('return_object:', return_object);

	return return_object;
}

The secret always stays the same as what the user enters (I added the underscore to reduce the potential of some kind of namespace/scoping issue).  However, *sometimes* there is a new public address returned by the end.  It is indeed a mystery.

Edit: Adding to it, I did a test with a live account and connecting to the public ripple servers - and setting a trust line.  Unfortunately, though the secret doesn't *appear* to be corrupted in the above chain, it still could be occurring somewhere else.  When the public address changes for an active account, attempting to set a trustline using the public servers results in an "invalid secret" error - I'm not sure if that's because the secret changed to a corrupt one, or because of the public address mismatch.

Edited August 3, 2017 by Professor Hantzen
Updated to add trustline test

[T8493]

Just curious: has anyone made any progress in finding out the root cause of this bug?

 

[supersonic]

15 hours ago, T8493 said:

@supersonic should offer a bounty? Or are you (or RL) offering a bounty?

Just asking for clarification. I can't help here anyway because I don't have a Mac with Safari browser.

Well if someone can tell me how to regain control over my account I'm more than happy to send him/her half of the amount of the XRPs that are being stored there. 

 

[pftq]

@supersonic, I sent you a PM with some ideas/suggestions.

[Mercury]

Sorry, am I missing something? If you still have your secret key couldn't you recover it on another client?

[T8493]

1 minute ago, Mercury said:

Sorry, am I missing something? If you still have your secret key couldn't you recover it on another client?

It looks like the minimalist Ripple client calculated the wrong address (account id) from his secret key.

[Mercury]

It looks like the minimalist Ripple client calculated the wrong address (account id) from his secret key.

Ah. Well that's random. Hmmmm. Well he said he can sometimes get the right pair to show up, but sitting there spinning the wheel hoping to get the right combo is a bad way to secure a wallet.

[supersonic]

Just for clarification:

The pair generated by the client is a mismatch.

That means, I sent XRP to a address I never even had a secret key for. 
The secret key given to me by the client does match a different address, not the one that showed up with  it in the client when it generated the pair. 

Sorry for the confusion, English isn't my first language. 

Quote

@Mercury Ah. Well that's random. Hmmmm. Well he said he can sometimes get the right pair to show up, but sitting there spinning the wheel hoping to get the right combo is a bad way to secure a wallet.

Well I don't think that is what's happening. I can reproduce the error.

When I type in my secret, every time I press set identity a different address shows, after a couple of tries and refreshing the page sometimes even the same mismatch that I was given in the first place. 

 

Edited August 4, 2017 by supersonic

[Mercury]

My mistake, I understand the issue now. This is not a good issue to be having, especially since it can be reproduced by others in different clients. 

[tulo]

If it is an issue with ripple-lib and safari, wouldn't that be a problem for all generated accounts on gatehub also? Are they using ripple-lib? @gatehub @enej

Maybe is it related to old ripple-lib version only? We should check with someone using the new rippleAPI on safari/mac.

@karlos I think it is better to remove the link to the minimalist client because someone could lose way more than 1500 XRP with this bug.

[pftq]

5 hours ago, tulo said:

If it is an issue with ripple-lib and safari, wouldn't that be a problem for all generated accounts on gatehub also? Are they using ripple-lib? @gatehub @enej

Maybe is it related to old ripple-lib version only? We should check with someone using the new rippleAPI on safari/mac.

@karlos I think it is better to remove the link to the minimalist client because someone could lose way more than 1500 XRP with this bug.

At least for the bug I mentioned earlier (bignumbers and Safari javascript interpreter causing freezing+glitching of the whole page), it affects everyone including Gatehub, unless they've patched it up in the past month or so.  I specifically checked xrpcharts + Gatehub + the clients to confirm it wasn't just my code at the time, and all sites were freezing when viewed from an Apple device updated to the most recent OS.  Not sure if Gatehub itself uses ripplelib; it could just be they depend on libraries that got affected as well, but the point is there was a change in Apple's interpretation of javascript recently that broke a lot of things.

 

Edited August 5, 2017 by pftq

[T8493]

2 hours ago, tulo said:

 

@karlos I think it is better to remove the link to the minimalist client because someone could lose way more than 1500 XRP with this bug.

Yeah, but if RippleAPI is affected, then basically all wallets (including e.g. GateHub) could have the same problem.

Maybe we should give a more general warning regarding the use of all RippleAPI-based wallets (basically all wallets) on Safari/Mac browsers.

 

[pftq]

1 hour ago, T8493 said:

Yeah, but if RippleAPI is affected, then basically all wallets (including e.g. GateHub) could have the same problem.

Maybe we should give a more general warning regarding the use of all RippleAPI-based wallets (basically all wallets) on Safari/Mac browsers.

 

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

For the bug I mentioned above (may or may not be related), the fix is available here.  All you have to do is recompile ripplelib with updated library dependencies.  I've posted this a few times in a couple threads.    But as mentioned previously, ripplelib hasn't been updated since May and many of the wallets haven't been updated for years, which is why I suggested earlier putting a "last updated" or other notice on the wallets so we know what code is too old.  The minimalist client, for example, is still using ripplelib from 2 years ago.

 

Edited August 5, 2017 by pftq