Jump to content
Guest

Does the “Biased Nonce Sense” paper affect old clients?

Recommended Posts

Guest

https://ripple.com/dev-blog/statement-on-the-biased-nonce-sense-paper/

Some further questions:

How does this affect transactions signed with the old Ripple desktop and web clients (Ripple Wallet and Ripple Trade, pre-August 2015 releases)? Did they never or only sometimes use deterministic nonces?

Is there a way to check specific transactions for the nonce method?

If transactions used non-deterministic nonces, is there any reason to be especially concerned about random number generation or biased nonces with these old Ripple clients?

@mDuo13 @nikb @JoelKatz

Share this post


Link to post
Share on other sites
1 hour ago, tomxcs said:

Is there a way to check specific transactions for the nonce method?

You could look for the nonce used and if it is your transaction you could check if it is the deterministic one according to RFC 6979 (since you need the private key for that) or just a random number.

Share this post


Link to post
Share on other sites

RFC6979 wasn't even published until Aug 2013, which is after the XRP Ledger was created. It's certainly likely that some software that's been around since the beginning uses random nonces instead of deterministic nonces, which is still secure as long as they're truly random. If they're less random, that's a problem.

It is my understanding that prior to around August/July 2015, the rippled server used OpenSSL instead of libsecp256k1 for signatures. The OpenSSL implementation does not (did not at the time?) use deterministic nonces, but rather uses random nonces. As long as the source of randomness was strong enough (depends on your system, but probably yes) then you're probably OK.

I dug into the history of ripple-lib and couldn't find anything one way or the other on the signing implementation prior to around July/August 2015.

It's hard to say whether someone is actually affected, though, even knowing what code they used to generate their signatures. Most people won't be affected unless they made a lot of signatures with questionable software... but it's a sliding scale—the less random your nonces, the fewer signatures it takes to figure out your private key. The extreme case is if you reuse the exact same nonce it only takes just two signatures. Incidentally, this is the exact mistake Sony made with the PS3 back in like 2011. They used the exact same nonce on every signature... oops.

Long story short, it's not a bad precaution to rotate your keys anyway.

BTW, credit for actually writing the article goes mostly to @nikb. I just proofread and posted it.

Share this post


Link to post
Share on other sites
16 minutes ago, mDuo13 said:

RFC6979 wasn't even published until Aug 2013, which is after the XRP Ledger was created. It's certainly likely that some software that's been around since the beginning uses random nonces instead of deterministic nonces, which is still secure as long as they're truly random. If they're less random, that's a problem.

It is my understanding that prior to around August/July 2015, the rippled server used OpenSSL instead of libsecp256k1 for signatures. The OpenSSL implementation does not (did not at the time?) use deterministic nonces, but rather uses random nonces. As long as the source of randomness was strong enough (depends on your system, but probably yes) then you're probably OK.

I dug into the history of ripple-lib and couldn't find anything one way or the other on the signing implementation prior to around July/August 2015.

It's hard to say whether someone is actually affected, though, even knowing what code they used to generate their signatures. Most people won't be affected unless they made a lot of signatures with questionable software... but it's a sliding scale—the less random your nonces, the fewer signatures it takes to figure out your private key. The extreme case is if you reuse the exact same nonce it only takes just two signatures. Incidentally, this is the exact mistake Sony made with the PS3 back in like 2011. They used the exact same nonce on every signature... oops.

Long story short, it's not a bad precaution to rotate your keys anyway.

BTW, credit for actually writing the article goes mostly to @nikb. I just proofread and posted it.

Thanks @mDuo13, well explained. 

Triggered by @Sukrim I created a little script that checks if RFC6979 is used on a transaction by replaying an old transaction with the newest ripple-lib (which uses RFC6979). If the old transaction uses RFC6979, then the resulting hash will be the same. I think it works pretty ok, but no guarantees that it works 100% . I checked some of my accounts and indeed most of them make the cut somewhere at August 2015, depends of course which client was used and when that client was updated to use a newer version. For those interested, here is the script (careful with those secrets, clear your shell history afterwards):

const { RippleAPI } = require('ripple-lib');

const txHash = process.argv[2];
const secret = process.argv[3];

const rippledService = 'wss://s2.ripple.com';

const api = new RippleAPI({
    server: rippledService
});

(async () => {
    await api.connect();
    const transaction = await api.getTransaction(txHash, {includeRawTransaction: true});
    const rawTx = JSON.parse(transaction.rawTransaction);
    delete rawTx.meta;
    delete rawTx.TxnSignature;
    delete rawTx.date;
    delete rawTx.hash;
    delete rawTx.inledger;
    delete rawTx.ledger_index;
    delete rawTx.validate;

    const signed = await api.sign(JSON.stringify(rawTx), secret);

    console.log(JSON.stringify(transaction.specification, null, 2));
    console.log("New txHash:", signed.id);
    console.log("Old txHash:", txHash);

    api.disconnect();
    process.exit(0);
})().catch(err => {
    console.error(err);
})

 

Share this post


Link to post
Share on other sites

The problem is having the history back to 2015.

I have 20+ accounts and at least 1M+ transactions up to August 2015 :unsure:

I'll need to study and make a script that checks all the transactions of one account...or just rotate the accounts and lose 400 XRP.

Share this post


Link to post
Share on other sites
11 hours ago, tulo said:

or just rotate the accounts and lose 400 XRP.

You'd just need to re-key the accounts and disable the master keys. That costs you a few hundred drops, not a few hundred XRP.

Share this post


Link to post
Share on other sites
On 1/16/2019 at 2:20 PM, tulo said:

The problem is having the history back to 2015.

I have 20+ accounts and at least 1M+ transactions up to August 2015 :unsure:

I'll need to study and make a script that checks all the transactions of one account...or just rotate the accounts and lose 400 XRP.

What @Sukrim said! Just set a regular keys, verify that it works and then disable the master key. Minimal cost—just tx fees.

Share this post


Link to post
Share on other sites

Should this (set and verify regular keys, then disable master key) be done by running a ripple server?  Can it be done safely, easily via other means like node.js plus a script, or some other means?

Anyway, I used a linux wallet client for signing transactions offline and the ripple-lib version referenced in the wallet source code was released after August, 2015 (I'm guessing the  "bump version to..." in https://github.com/ripple/ripple-lib/commits/develop?after=dc148bf95441f8ad879026f8cb2473be4d6f055f+699 references the dates the ripple-lib versions were changed), so it should be safe regardless, right?

Edited by enrique11

Share this post


Link to post
Share on other sites
11 hours ago, enrique11 said:

Should this (set and verify regular keys, then disable master key) be done by running a ripple server?  Can it be done safely, easily via other means like node.js plus a script, or some other means? 

Anyway, I used a linux wallet client for signing transactions offline and the ripple-lib version referenced in the wallet source code was released after August, 2015 (I'm guessing the  "bump version to..." in https://github.com/ripple/ripple-lib/commits/develop?after=dc148bf95441f8ad879026f8cb2473be4d6f055f+699 references the dates the ripple-lib versions were changed), so it should be safe regardless, right? 

First question: You can do it with ripple-lib or software built on top of it that is capable. You would use a settings transaction to set the regular key pair (providing its address in the regularKey field), then send just about any transaction you want using the regular key just to confirm it works (if you've got nothing better to do, you can send a "settings" transaction with no arguments), then use a second settings transaction to disable the master key pair. That last transaction to disable the master key pair has to be signed using the master key.

Second question: It sounds like the version you use uses deterministic nonces, so I think you are OK. But I'm not a cryptographer, so, uh... please don't hold me liable if I'm wrong. If you're not sure, it's safer to rotate the keys.

Share this post


Link to post
Share on other sites
14 hours ago, nikb said:

What @Sukrim said! Just set a regular keys, verify that it works and then disable the master key. Minimal cost—just tx fees.

How easy/tricky/technical/risky would it be for somebody like me who is not very technical minded ?? @nikb how to create new account ? Is it with ripple or hardware wallet ? Plz advise.

Share this post


Link to post
Share on other sites

Good question.  The rippex website provided wallets that were already in generic executable form, not like in the form in the link you posted from github where you have to do stuff to the source code to build a working wallet - the link you posted contains the wallet source code.  In the source code files you will find a file called package.json.  Inside that file you will find the ripple-lib version referenced.

Hopefully the guys at rippex who created the wallet apps for people to download followed the same or similar directions in their README.md file when building the wallet apps and used the referenced dependencies (including ripple-lib) in the package.json when creating the wallet apps.

I'm not a coder, but I gotta figure out this stuff too...won't leave it to chance.

 

 

Edited by enrique11

Share this post


Link to post
Share on other sites
On 1/19/2019 at 5:40 PM, enrique11 said:

Should this (set and verify regular keys, then disable master key) be done by running a ripple server?  Can it be done safely, easily via other means like node.js plus a script, or some other means?

Anyway, I used a linux wallet client for signing transactions offline and the ripple-lib version referenced in the wallet source code was released after August, 2015 (I'm guessing the  "bump version to..." in https://github.com/ripple/ripple-lib/commits/develop?after=dc148bf95441f8ad879026f8cb2473be4d6f055f+699 references the dates the ripple-lib versions were changed), so it should be safe regardless, right?

 

It's up to you if you use a 3rd party binary but this is the step by step process that I created. 

Edited by jargoman

Share this post


Link to post
Share on other sites

ICYMI, I have ported (almost finished) ripple-client-desktop to RippleAPI, the latest ripple-lib. https://r0bertz.blogspot.com/2019/01/revive-ripple-client-desktop.html

Generating regular key already works.

Disabling master key now works too. https://github.com/r0bertz/ripple-client-desktop/commit/14b5317aca3f8500a448b965921473a67abe1fc2

I just tried it on my own accounts.

Share this post


Link to post
Share on other sites

×
×
  • Create New...