Reused R values again

[johoe]

Hello,

there has been a lot of reused R values in the signatures on the blockchain, recently.  This exposed many private keys.  After googleing the addresses, I think it is related to Counterparty (XCP).  Here is a list of the exposed addresses in alphabetic order.  Most keys were exposed very recently, i.e., in the last week.

If you own one of the following addresses, you should transfer the money to a fresh address (before someone else does it for you).  Also figure out, which client has the bug that revealed the private key by reusing R values.  Then notify the author of that tool.

112KZ24UgNndZqdnu2cXwXStSjtY78ZRUh
12ZXAga2nRxBECsMDjFypWuL9UkKEaS4Z3
12sisxXmNPmFTpekBKEqZCELYXESPYUHCB
139YrtXS2J1KiD8pf2R3RtKRPr8sLwLuiq
13GSuGxtMZyE6SDA8XJyuWsHYpXZyNQTAn
13ikC8398HhciFWkqPCrRHWUBASGxhBY4m
13tRCNGCGuVN4gYyf6CpfYckhM3qrJy9YX
14Bgi1c11HBcj7krN5tRepMdL3SPghEaMM
14kaXa47cUcMpvKnCa8zr38C9v7sVPxSta
14qF25Rg3hJaYFHwE6ST2rr1cnBS3DPYNe
14uS988CkkfTs7Ckre8nkVedSQF9v4CqrM
1599DB5Tb1RWDPYMuU3YJT3jRwyyoPZa1B
15Ew6Sen8hVhTfLmXvAEEqGfX58iYWqEV5
15mcUhVMi3KmoWvP6Y8NpVaXaPVGCWztgL
1681LkMDLNw6CCjUrMojRKC8BaiwQ2LTFt
16LEKMzhabDoTghR2no3a59SJQC6MJp2aM
16NMGWRavnYG5bhWzY8GAXWiTZLytpT4v7
16khUbFwUK6X7U5X919RJeWyfBHSLfJMda
16vHYDZCLZiD97TucWr5Wht9zBA7JJmuF5
17SP6Qc3fP3zUWFkfRrwY3TF3a6eQ3NsZr
17Vxv31VfpFY6tWBBB93tcSgP4SYeqzTTb
17quWZhtGikUcTUpExchL6UdFga6Z8hME9
17xnTfrWYiLMhEQmW55VCa5cVhSZMVUak6
181ErGfBCT7twckweWJgoDMGXNepvb4qnp
185YGf4EoVfgqFBSAAUf1wDte9KVwmdHMy
187TT5PpAKGHRBGjdaKDZsgBH1s8yNCtS4
18RecXQxH8xuqS1zNgrukvPybDtc3Mn4br
18SEPGaZ3xdHiH2hkSdPgkYdnvzPr6PZYS
18U2grD3VwFa626tkTnabXSY2nVQAvmf3U
18W9kV7SqNPnvcbZRzM34aE14m5tFmAuz5
18djF84ZNVURvFUX2ZAVaFqV9MerjJkQtE
18mEp3aKQ9thp3H72rrzHAfW719YmHq2f7
199EPbUzU6mBr7dP61ihWsicuJyeYbJviS
19Ey6feEfARgzcNRmUxBZNQFYSmwgsU9Wc
19usDGaGtwHfMoJKAJEJd3KcfZFWj5zocV
19vokfKSJJMwHAqQ3Kehk8Gq5drXhi7wzU
1AApKu3su7VT9K1hgyxp3pcp2DSNC5V9s3
1AFZ8j6Mm6EphAFJbHyzCxKpKm9si8Vt3v
1AGCK1JM7pEu5r4g5yRiezXhn83TPGaWEh
1AKE18rv9BUPpxciQziTjQzwNQoMSrvQaV
1AX5hvrNXTs8KnDVBSRwHPHg5iQ5fyb8rs
1AjwULXBv9TeVjADC3khcP69USBGRXYUpd
1ArJ9vRaQcoQ29mTWZH768AmRwzb6Zif1z
1AsEhnbniTP4YSA8L1Xa1uQjfSfHbb8tzJ
1AsbDvSw2rzEa39erkCrMW6KTr4tDHGSAH
1Asfz56unNm1c527p3ENavRqecShQyxHeN
1B9FoQWdPift6CUXUs6K82TZxaTyHpTUnC
1BDMV3Yb6Pp2ycB94UsruXgPWAWBJhBuKL
1BYuQ21smrF1hKfmHPsDnJkWZZdEpBFLZo
1Bn1n2N9Z3Xhnxd3b6ViNMstg7oGjh8XAa
1BwrmTmhnp6K6Shbq5zQQqGqnsfXsunsqE
1C4YepY3K1gDrRiQ5E9rgaJuXvrawxXMJG
1CAsRJ5Z9CXdhBwxrCVrf8kJNPBxYQJiH1
1CLfNqGBb949bBbMgefRPkDVgpgyEgWRF
1CPzjQTH5vNADXQGeCfHtRgX8S5xMLGMr4
1Cbw9MZ8Vrfkzv1FxuJS5JBySbypuMARQj
1CgEzXmF7SeNr8rd2AfyN1DQNJpprVxWmW
1CjKefUiRhK5hWf79MoJqccHC1ohye7SWr
1CpV2F9YASreNrBGf1E8QgFgKdqYQopzGH
1CtgapxmS4CRLCNFGTbidAqfk9WNdR2kdn
1D76ha9QoxkUPLxufDoZVEzx6hH3uVJvnZ
1DEsbC42Je7psYeaE2mbWNUpSEFTL9aQUs
1DL21hg5FBLC4h9mXwx9XDbHmUK3BZFCQe
1DkCk3S98BCwPP8wdmxqQKcQoH4WJthvMR
1DpyhFtQs3yVM4gSf3KiD9GBxcPaxuQRDT
1DqXkT8KR25q56sAerfSg875KaJ6o3f3mi
1Dsoi4eggJhipmYZtFGPGBxLX8nguYxiGh
1DxzwX4qC9PsWDSAzuWbJRzEwdGx3n9CJB
1E1rbpZitcZ73JQoLYXB18pDm8BTHVqxtk
1EGok6kAbJRrzryXAGyCHRq5c649rhzwJ3
1EKJUnK4EE83LdGsCnFPZxgkybyFiTdbMk
1EMkFrY86siasW3F9zC2bS1ZcSuTdaiJqj
1EMxjb3667se6LuqkhRsrBaAScGsx5DMFq
1EZtDBBkqkHxRXNSBwTV7HhBbPVvqC8Rte
1EkkAMw1K6HKGiou5vNrLBffDtjVAC5HW3
1EqBqwtfJMZERvyckvexLJLuSrqYewCaE3
1Es37FWCT3xDCrQM2NEJLajRPYNbk7jUaH
1FMhAUpVgU2H3n576vUe7vQp94zCkRPnf6
1FSmh8gSuPkZTqx6LeH6Jic4iZ1A8BsZ2L
1FyQtBr9ub8FhKGDcgW2uAbU6cHYuNmBk3
1GNvTWNZM48QA44QmbVjxXhQ7hmJDicxec
1GvhZ6FewuuyYwZ9cPWd614Gu6UhWacrDY
1HAEJNWN7johTEiooRau7F6NFvHnBDXHzh
1HDGRnafT7ogCaMuHx9csBGvGeYc441tQ4
1HMYjeeZf4qq9L9WZRaBKnNjsP1bSLsuMs
1HSUdtBoNbexP3ordhnSZ2jfHCGVvAbGt
1HW45VWikPEoijyKtguggMEJ5CnsS78ESf
1HfjrpJLP5SaPRFzYUxrzhppw6xv6GXZ6f
1Hu5wfuk9nHuYDpdX6FjQrU1NYvpUS8r6t
1JHL7mbGq64heFnJA8i2QVm18p4TQ1kf9M
1JX7Z9Si6tUQgFa4PLNTtJ8bC9WrfMDvLb
1JmY6KZxoMjMaFKLVSMAr7BdsAAWASMR7d
1K3iZPSqMCxtMd5o5hw4gfpFq3i9zqL61o
1K8fu7jfjuKS28YrA2rSCy7fkZhNvcab5p
1KJERjQwXx8ojrKRSPFKwkCct1aAkyHgnF
1KS7abb8CrqrSizfyPXkcRocYejZQ332xM
1KiAVfFJH9EU29C9H9p2SBnrkfzrgrRRCe
1KojFMcdHzDndhfqPxb5CnXeB1R5u9nnxG
1KpxMLLmEhaqoUXN1hfq8fci4z7p593HsV
1KvvnDBRtHFZdE9ngqGWV5VGznFgXuF1fd
1Kzf3YptWEMwDHF1nmVpMbs3jSvWjWdSbR
1L2Bcohuf1qyHykTdP8rD74K6HQSsTaTE
1LCnNsa2pxbZCsVdRoNqLGFcULbrEFL4i1
1LKVE8ys5rep3LbELC3fhfCRWXQiEi7hpv
1LKumxgbfSycQVaAwagpyZRSy71wXC2zhF
1LWDzisQtETsxk6N8QNa1KuUSiYtmmfa5A
1LhA9wbU4enUCT8EVorxeJegQtkZcyr7m6
1LrUd8tr5TD3UvD4KZaiNcAxmFveCw5h27
1M52izWFApBEuRMqMx4gbr8prABCA9Q9tv
1M7hSnVZniAXrre2SH9qaHvfxgXRAjpMVk
1MLQDQQsaHPSPQwp3TJ5YSbffm2EHneaU9
1MMMpX4AKhf9JTviWuU7fwnZuTdW78G2Mf
1MX1fSzSvTuw3yNgPNE3Ni31kT1DSdeUPC
1MmJk1peLVmycqY8Hq6WyZfrK4u1oTvkER
1NAddQ2XhM96aGn4yK9naRzxTxe7BbNTLG
1NLbWbTczixoA3sCgQg5NLpsExqRPJiA3H
1NMb6g4rQXHmsaHaiy1iV2Wmn4bTGwxyLT
1NR7Bw4XWK3oic9HvgWFProGVzp5jKeqCw
1NWXH2DE5DTfKWAwABAvFesGXKkyKBUoiN
1NeAtszct9Uav81CEr1FGhV4KAaXahdsVF
1NjGEKWWrupvbzvEivnfXJpdNdXK5xzdDb
1NkYPP3Eix9shAvU47xJtnL4Ggd2ScAbcD
1P5anXJVbPeXsw4wExuQ8SCBRevRPe8syQ
1PEAu3bS7t6ZYKGX77ZJsEKSupGzdR5Kpj
1PNa9dZ3P3fVhx1uMCqJ4sEYmyhxnQNy3M
1PQwoVNRCiK2J5GNumfpT3qk7KnhKPJ6Ph
1PVHbRqh1eYsGCVZ7t18UCQ6oPzXFR3HQz
1QBYgXMTqEQNgoVotQN2iP1sPhHRPEoDHb
1QDB2W1VFqinxu5zm4qMGecQTfviBjk3JA
1RfEM5WPtboTNnjHN3HR889FyuUx6T14D
1ZaRiG4qLj336tKFMZCGPpySoRQsReivv
1iuC1ovtbMJQLniEiJtR5obbWvVkmTjiE
1ptDzNsRy3CtGm8bGEfqx58PfGERmXCgs
1sgNrgAnjMVSzyeMDTeVsKN7FuZy34U5t
1vdbVPC6Ts9d5WhRDriPdndvvCwmCbKCj

[1714146263]

1714146263

[1714146263]

1714146263

[PhantomPhreak]

There was a tx signing bug in BitcoinJs which Counterwallet (a Counterparty web wallet) triggered. Counterwallet has been patched, and all users of Counterwallet should indeed generate new accounts and sweep all of their funds there.

See the original announcement.

[DeathAndTaxes]

For this and other reasons (flawed, weak, unverifiable or backdoored PRNG) developers should strongly consider using RFC6979 to create deterministic signatures.  The k value does not need to be random it only needs to be unknown and used once.  Transactions are already unique and the signer has something which is unknown to the public (private key).  This means it is possible to sign transactions without needing to rely on "random" elements.

http://tools.ietf.org/html/rfc6979

There are implementations in Python, C++, Java, (and when I get a chance to do some refactoring C#).

Code:

# Test Vectors for RFC 6979 ECDSA, secp256k1, SHA-256
# private key, message, expected k, expected signature

"01", "Satoshi Nakamoto", "8F8A276C19F4149656B280621E358CCE24F5F52542772691EE69063B74F15D15", "934b1ea10a4b3c1757e2b0c017d0b6143ce3c9a7e6a4a49860d7a6ab210ee3d82442ce9d2b916064108014783e923ec36b49743e2ffa1c4496f01a512aafd9e5"
"01", "All those moments will be lost in time, like tears in rain. Time to die...", "38AA22D72376B4DBC472E06C3BA403EE0A394DA63FC58D88686C611ABA98D6B3", "8600dbd41e348fe5c9465ab92d23e3db8b98b873beecd930736488696438cb6b547fe64427496db33bf66019dacbf0039c04199abb0122918601db38a72cfc21"
"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140", "Satoshi Nakamoto", "33A19B60E25FB6F4435AF53A3D42D493644827367E6453928554F43E49AA6F90", "FD567D121DB66E382991534ADA77A6BD3106F0A1098C231E47993447CD6AF2D06B39CD0EB1BC8603E159EF5C20A5C8AD685A45B06CE9BEBED3F153D10D93BED5"
"f8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181", "Alan Turing", "525A82B70E67874398067543FD84C83D30C175FDC45FDEEE082FE13B1D7CFDF1", "7063ae83e7f62bbb171798131b4a0564b956930092b33b07b395615d9ec7e15c58dfcc1e00a35e1572f366ffe34ba0fc47db1e7189759b9fb233c5b05ab388ea"
"e91671c46231f833a6406ccbea0e3e392c76c167bac1cb013f6f1013980455c2", "There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!", "1F4B84C23A86A221D233F2521BE018D9318639D5B8BBD6374A8A59232D16AD3D", "b552edd27580141f3b2a5463048cb7cd3e047b97c9f98076c32dbdf85a68718b279fa72dd19bfae05577e06c7c0c1900c371fcd5893f7e1d56a37d30174671f6"
"0000000000000000000000000000000000000000000000000000000000000001", "Everything should be made as simple as possible, but not simpler.", "EC633BD56A5774A0940CB97E27A9E4E51DC94AF737596A0C5CBB3D30332D92A5", "33a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c96f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
"fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140", "Equations are more important to me, because politics is for the present, but an equation is something for eternity.", "9DC74CBFD383980FB4AE5D2680ACDDAC9DAC956DCA65A28C80AC9C847C2374E4", "54c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed07082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
"fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140", "Not only is the Universe stranger than we think, it is stranger than we can think.", "FD27071F01648EBBDD3E1CFBAE48FACC9FA97EDC43BBBC9A7FDC28EAE13296F5", "ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd06fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"

[grau]

Or see how it is done in Java:

in Bits of Proof:

https://github.com/bitsofproof/bop-bitcoin-client/blob/master/api/src/main/java/com/bitsofproof/supernode/common/ECKeyPair.java#L157

or in bitcoinj:

https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/core/ECKey.java#480

[Yuki1988]

We have a victim here (https://bitcointalk.org/index.php?topic=581667.0) with the address 1PNa9dZ3P3fVhx1uMCqJ4sEYmyhxnQNy3M.
It seems he is using blockchain.info wallet.

[ddink7]

We have a victim here (https://bitcointalk.org/index.php?topic=581667.0) with the address 1PNa9dZ3P3fVhx1uMCqJ4sEYmyhxnQNy3M.
It seems he is using blockchain.info wallet.

This is indeed my wallet. I also did use Counterwallet recently to access some XCP that were tied to that address. Early this morning, 12.5038 BTC were stolen from my account, apparently due to this bug with Counterwallet.

[VTC]

Has in the past or is currently brainwallet.org vulnerable to using the same or weak R / k values when building the transactions?  I see bitaddress.org now has an extended random generator on page load, and I believe blockchain.info wallet was patched when the android bug was discovered.

[gmaxwell]

Practically all of the web keygen / signing apps I've audited use a really sketchy structure where access to the system's cryptographically strong prng is inside a try/catch block and failure results in silently replacing the entropy with snake oil...

Interesting to see that this instance was a different failure mode where the inadequate type-safety of JS combined with a lack of testing for deterministic DSA yielded sadness. (It appears to use a derandomized DSA, but had no tests for it, and the ability to test is one of the big advantages of derandomizing DSA... an underlying library change the behavior of the hash function and the signatures started using a constant nonce).

[LifeisGreat88088]

So sad , my address is on the list .

But thanks for the post!

[johoe]

Since this thread was bumped, I think I should update it.

There seems to be a new buggy program that reuses the same R value for all signatures in a transaction.  It started around September 2014. Because the program uses mostly unique addresses, the bug is not always exploitable.  But reuse happened often enough to break over 400 new keys. The list is getting too long to post it here so here are the links:

http://johoe.mooo.com/bitcoin/broken.txt
http://johoe.mooo.com/bitcoin/endangered.txt

The first list contains the addresses whose private key can be computed from the block chain.  The second list additionally contains addresses that were used by the faulty client but only in a context where it cannot be broken (unless I'm missing something).

Does anyone know what the buggy program is?  Or does anyone recognize any of the more recent addresses?

Note that the addresses that appear only in the second list still may be in danger, e.g., if they stem from a BIP32 wallet and one knows the "xpub" public key.

It looks like there are some bots sweeping all funds that go to such a broken wallet.

[cr1776]

So sad , my address is on the list .

But thanks for the post!

I asked in your other thread (https://bitcointalk.org/index.php?topic=879419.0), but which program did you use to create this address and where did you get the program?

[RocketSingh]

Since this thread was bumped, I think I should update it.

There seems to be a new buggy program that reuses the same R value for all signatures in a transaction.  It started around September 2014. Because the program uses mostly unique addresses, the bug is not always exploitable.  But reuse happened often enough to break over 400 new keys. The list is getting too long to post it here so here are the links:

http://johoe.mooo.com/bitcoin/broken.txt
http://johoe.mooo.com/bitcoin/endangered.txt

The first list contains the addresses whose private key can be computed from the block chain.  The second list additionally contains addresses that were used by the faulty client but only in a context where it cannot be broken (unless I'm missing something).

Does anyone know what the buggy program is?  Or does anyone recognize any of the more recent addresses?

Note that the addresses that appear only in the second list still may be in danger, e.g., if they stem from a BIP32 wallet and one knows the "xpub" public key.

It looks like there are some bots sweeping all funds that go to such a broken wallet.

I'm a little confused with all the tech junks that is being talked about here. Can u plz tell me in simple terms that if I use blockchain.info to create an address, download the paper wallet containing the private key and keep it and the password safe, then am I secured ?

I can see gmaxwell was talking about some try-catch which may kill the entropy in the seed. Is that present in blockchain.info as well ?

[amaclin]

I'm a little confused with all the tech junks that is being talked about here. Can u plz tell me in simple terms that if I use blockchain.info to create an address, download the paper wallet containing the private key and keep it and the password safe, then am I secured ?

If you are asking this question - it means that you are not secured.

[yakuza699]

So sad , my address is on the list .

But thanks for the post!

I asked in your other thread (https://bitcointalk.org/index.php?topic=879419.0), but which program did you use to create this address and where did you get the program?

So as far as I understood it he used omniwallet.org

He said "I  imported the private key of B" but he might meant that he created it there. And then he said "The address is mine, I create it from the wallet!!" which probably meant that he used bitcoin core. I think that either one of them.

Edit: he generated those private keys using the blockchain.info web wallet.

[johoe]

So sad , my address is on the list .

But thanks for the post!

I asked in your other thread (https://bitcointalk.org/index.php?topic=879419.0), but which program did you use to create this address and where did you get the program?

So as far as I understood it he used omniwallet.org

He said "I  imported the private key of B" but he might meant that he created it there. And then he said "The address is mine, I create it from the wallet!!" which probably meant that he used bitcoin core. I think that either one of them.

Edit: he generated those private keys using the blockchain.info web wallet.

The private key leaked due to the counterparty bug.  The transaction that revealed the private key was
https://blockchain.info/tx/86510ddeded6486b73fe08ab4ce6320ab1aa1d5d006d699e37aeb1b1e9df3e50
The wallet was already sweeped in April, e.g.,
https://blockchain.info/tx/737326ba838fb6b887480f9be2924141000d5e11e8bc450655ab4743da508754
Probably the amount of 0.0017 was to few to be noticed. 

So the moral is, don't reuse your old addresses, especially with different clients.  Otherwise, you will get bitten if one of the client you tried is buggy.  If possible, use a fresh address for every transaction. 

[johoe]

I'm a little confused with all the tech junks that is being talked about here. Can u plz tell me in simple terms that if I use blockchain.info to create an address, download the paper wallet containing the private key and keep it and the password safe, then am I secured ?

I can see gmaxwell was talking about some try-catch which may kill the entropy in the seed. Is that present in blockchain.info as well ?

It is hard to test javascript code in every browser and if the entropy generator fails under some systems, usually nobody will notice (until two people create the same private key by accident).  That said, I haven't audited the blockchain code, so I cannot say whether it has this problem or not.

But if you want to generate a paper wallet, because this is the most secure storage, it is a bad idea to do it on a service that stores your private keys in the cloud (even if it stores them encrypted).  If someone guesses your password or phishes it, he will get access to your keys.  If you generate a paper wallet, do this on an offline computer.  The private key should never leave this computer at all (except to the printer).  If you are paranoid, install a fresh system on the computer before and after you generate the paper wallet, to avoid trojans on your computer.

[RocketSingh]

I'm a little confused with all the tech junks that is being talked about here. Can u plz tell me in simple terms that if I use blockchain.info to create an address, download the paper wallet containing the private key and keep it and the password safe, then am I secured ?

I can see gmaxwell was talking about some try-catch which may kill the entropy in the seed. Is that present in blockchain.info as well ?

It is hard to test javascript code in every browser and if the entropy generator fails under some systems, usually nobody will notice (until two people create the same private key by accident).  That said, I haven't audited the blockchain code, so I cannot say whether it has this problem or not.

But if you want to generate a paper wallet, because this is the most secure storage, it is a bad idea to do it on a service that stores your private keys in the cloud (even if it stores them encrypted).  If someone guesses your password or phishes it, he will get access to your keys.  If you generate a paper wallet, do this on an offline computer.  The private key should never leave this computer at all (except to the printer).  If you are paranoid, install a fresh system on the computer before and after you generate the paper wallet, to avoid trojans on your computer.

I have a standalone machine with Pentium II processor which I do not use for long. It is infected with some virus/malware too. But I dont plan to connect it to the internet in some coming years too unless I get time to re-install fresh OS on it. So, if I download bitaddress.org in my current machine and copy it to the old machine using an USB and then generate an address over there, just to note down the address/private key pair on a piece of paper, then will that address be safe for use as a cold storage ?

[itod]

I have a standalone machine with Pentium II processor which I do not use for long. It is infected with some virus/malware too. But I dont plan to connect it to the internet in some coming years too unless I get time to re-install fresh OS on it. So, if I download bitaddress.org in my current machine and copy it to the old machine using an USB and then generate an address over there, just to note down the address/private key pair on a piece of paper, then will that address be safe for use as a cold storage ?

Do not use infected machine for this. Just don't, no matter if you don't plan to connect it to the internet, you may connect it accidentally by mistake. It's much better to boot fresh OS from the CD, for instance many people recommend Puppy Linux for this purpose since it works well with many printers and runs almost on any PC including old Pentium II like yours. Why risk something when you can do it safely and don't waist time on OS re-installation?

[dserrano5]

I have a standalone machine with Pentium II processor which I do not use for long. It is infected with some virus/malware too. But I dont plan to connect it to the internet in some coming years

As said, don't use it. You don't know if the random numbers generated are truly random, they could be predictable or plausibly brute-forceable for the attacker.

[Remember remember the 5th of November]

I have a standalone machine with Pentium II processor which I do not use for long. It is infected with some virus/malware too. But I dont plan to connect it to the internet in some coming years

As said, don't use it. You don't know if the random numbers generated are truly random, they could be predictable or plausibly brute-forceable for the attacker.

You must be joking right? Considering his machine, the virus was probably written 15 years ago or longer. Nevertheless caution is needed.