Feedback for BTC mini key generator

[raritycheck]

Hey guys


Please provide feedback on any vulnerabilities for https://github.com/raritycheck/BTCMiniKeyGenerator

We want to use this to create BTC mini private keys for our various projects.

But we really want some hardcore feedback.

[BitMaxz]

It is an interesting BTC tool but why it need to install PortAudio what is the use of that software for generating a mini key?

Another thing is that is this mini key you mean is a mini private key? is it supported on Electrum?

I don't want to install any random software into my PC but if you are looking for someone who can make a feedback about your project I think better explain first how it exactly works and what it exactly produce so that people who will try it atleast knows what it is and how it works.

[raritycheck]

It is an interesting BTC tool but why it need to install PortAudio what is the use of that software for generating a mini key?

Another thing is that is this mini key you mean is a mini private key? is it supported on Electrum?

I don't want to install any random software into my PC but if you are looking for someone who can make a feedback about your project I think better explain first how it exactly works and what it exactly produce so that people who will try it atleast knows what it is and how it works.

Great questions

• PortAudio is used for adding entropy with audio around
• Yes generated mini keys are supported on electrum. here 1000+ keys generated with the tool

It cannot be installed on a computer. It can only be used to generate mini keys by running the python program

Added How it works?

[hugeblack]

It's good that it's open source but is the entropy address generation really random? I see you are using secrets.token_bytes() in addition to random data from audio or system time. Do you think that mini key is cryptographically secure?

[nc50lc]

But we really want some hardcore feedback.

In terms of randomness, I'd say that it's on the secure side for concatenating uRandom and its "Audio-based" entropy generation. (audio_randomness.py)
And it doesn't stop there since the result is also combined with timing-based entropy.

As for the generation of the mini private key;
It's using a 29-character part of the base58-encoded entropy appended with "S" which isn't too bad considering there's no standard on generating mini-private keys.

What I'd like to see is a modern version where the encoded WIF has compressed pubKey flag to be compatible with SegWit. (K or L - WIF)
But that's not currently supported by clients supporting mini private keys which automatically assume that it's associated with an uncompressed public key.

[raritycheck]

But we really want some hardcore feedback.

In terms of randomness, I'd say that it's on the secure side for concatenating uRandom and its "Audio-based" entropy generation. (audio_randomness.py)
And it doesn't stop there since the result is also combined with timing-based entropy.

As for the generation of the mini private key;
It's using a 29-character part of the base58-encoded entropy appended with "S" which isn't too bad considering there's no standard on generating mini-private keys.

What I'd like to see is a modern version where the encoded WIF has compressed pubKey flag to be compatible with SegWit. (K or L - WIF)
But that's not currently supported by clients supporting mini private keys which automatically assume that it's associated with an uncompressed public key.

Thank you

This one focuses only on creating mini keys which we need to create secure keys for collectibles
We think of creating WIF creation tool.

Regards
Team RC

[ABCbits]

But we really want some hardcore feedback.

Most member who visit this board aren't programmer or Bitcoin developer, so don't expect hardcore feedback. But here's my amateur feedback.
1. What would happen if there's no audio input on the device? Would the code throw error or return weird data?
2. Consider adding tests to your code.
3. I think using audio input, os.urandom and secrets should be secure enough.

[Quickseller]

But we really want some hardcore feedback.

Most member who visit this board aren't programmer or Bitcoin developer, so don't expect hardcore feedback. But here's my amateur feedback.
1. What would happen if there's no audio input on the device? Would the code throw error or return weird data?

If the audio cannot be detected, or if there is no audio device, an exception will be raised (the program will crash), but due to try statements elsewhere, the private key will not be generated.

It appears the script is intended to use the user's audio input as a means of 'randomness'

Code:

#audio_randomness.py
    if frame_count < min_frames:
        raise ValueError("Insufficient audio data captured. Try increasing the duration or ensuring the microphone is working properly.")

#...
 # Check if audio data is silent
    audio_array = np.frombuffer(audio_data, dtype=np.int16)
    if np.max(np.abs(audio_array)) < silence_threshold:
        raise ValueError("Captured audio appears to be silent. Please check the microphone volume and try again.")

I would suggest this code not be used to generate private keys that will contain anything of actual value.

The code uses 'mini keys' which use less entropy. Also, the first digit of the mini key be '0', which even further reduces entropy (and perhaps is unnecessary).

Also, although the audio portion may introduce additional entropy, audio is potentially predictable, and an attacker could potentially record your environment to get an idea of what your audio input will be, and some sound devices may reduce variance in audio even further. If you are generating many keys at the same time, each of those keys may get very similar (if not the same) input for audio, which is not good.

Given the OP's history of selling physical coins whose private keys later are compromised, it is probably not a good idea to trust any software used to generate private keys produced by this person.

[raritycheck]

But we really want some hardcore feedback.

Most member who visit this board aren't programmer or Bitcoin developer, so don't expect hardcore feedback. But here's my amateur feedback.
1. What would happen if there's no audio input on the device? Would the code throw error or return weird data?

If the audio cannot be detected, or if there is no audio device, an exception will be raised (the program will crash), but due to try statements elsewhere, the private key will not be generated.

It appears the script is intended to use the user's audio input as a means of 'randomness'

Code:

#audio_randomness.py
    if frame_count < min_frames:
        raise ValueError("Insufficient audio data captured. Try increasing the duration or ensuring the microphone is working properly.")

#...
 # Check if audio data is silent
    audio_array = np.frombuffer(audio_data, dtype=np.int16)
    if np.max(np.abs(audio_array)) < silence_threshold:
        raise ValueError("Captured audio appears to be silent. Please check the microphone volume and try again.")

I would suggest this code not be used to generate private keys that will contain anything of actual value.

The code uses 'mini keys' which use less entropy. Also, the first digit of the mini key be '0', which even further reduces entropy (and perhaps is unnecessary).

Also, although the audio portion may introduce additional entropy, audio is potentially predictable, and an attacker could potentially record your environment to get an idea of what your audio input will be, and some sound devices may reduce variance in audio even further. If you are generating many keys at the same time, each of those keys may get very similar (if not the same) input for audio, which is not good.

Given the OP's history of selling physical coins whose private keys later are compromised, it is probably not a good idea to trust any software used to generate private keys produced by this person.

Thank you Quickseller

Unfortunately we trusted another software and hence the keys were compromised but it's not just ours but a widespread RNG attack https://www.blockchain.com/explorer/addresses/btc/1AMPtQJ3ajQBjZ1JdrtnhBukFgq7MW8749

 but we are refunding every sngle impacted user.
 
And we want to make the software we are suggesting more secure.

Audio just adds another layer of entropy. But it has audio + urandom + time based entropy.
If we do want to generate mini keys.. what are your suggestions to make it more secure.

[nc50lc]

Unfortunately we trusted another software and hence the keys were compromised but it's not just ours but a widespread RNG attack

It would be interesting if you mention that software for comparison.

Because it could be the entropy or the mini private key itself.
For example: the script in the OP produces a 256-bit entropy but about 34% of it is discarded when generating the mini private key.
So its overall security is reduced to about 2^168 which is still secure in today's standard. (e.g.: old unspent Casascius Coins)

But of course, wait for more extensive reviews before deciding to use the script to store bitcoins.

Also, the first digit of the mini key be '0', which even further reduces entropy (and perhaps is unnecessary).

The standard "0x00" at the start of SHA256(<mini_PrvKey>?) is for validity check only.
Ref: https://github.com/raritycheck/BTCMiniKeyGenerator/blob/a23567757fcc541cde0494f960682bca6d8a7d99/generator.py#L42-L46
e.g. (refer to his "keys generated" list):

• SHA256(Se26HZpLMfrCyKyzwAKoFy4XoqUKv?) = 0092378840ae9002c0588b6cf15040417410f647e374e2a9a4937aa39768419e

The ECDSA Private key is calculated without the "?" at the end and has no first Byte restrictions.
Ref: https://github.com/raritycheck/BTCMiniKeyGenerator/blob/a23567757fcc541cde0494f960682bca6d8a7d99/generator.py#L69-L75
e.g.:

• SHA256(Se26HZpLMfrCyKyzwAKoFy4XoqUKv) = 9694e04ab39ab01e9ce268b93821a3f0512c8475183efb80e80372f788447815
• WIF: 5Jxbz5v4W3iTu6LVze2E1xgUFS5ECheZFfc25i6cUywB5uLuqp1
• Addrs: 12UcdGZMANBKqvVS1s7GzvHQDcJ1aAB9Hf

[raritycheck]

Unfortunately we trusted another software and hence the keys were compromised but it's not just ours but a widespread RNG attack

It would be interesting if you mention that software for comparison.

Because it could be the entropy or the mini private key itself.
For example: the script in the OP produces a 256-bit entropy but about 34% of it is discarded when generating the mini private key.
So its overall security is reduced to about 2^168 which is still secure in today's standard. (e.g.: old unspent Casascius Coins)

But of course, wait for more extensive reviews before deciding to use the script to store bitcoins.

Also, the first digit of the mini key be '0', which even further reduces entropy (and perhaps is unnecessary).

The standard "0x00" at the start of SHA256(<mini_PrvKey>?) is for validity check only.
Ref: https://github.com/raritycheck/BTCMiniKeyGenerator/blob/a23567757fcc541cde0494f960682bca6d8a7d99/generator.py#L42-L46
e.g. (refer to his "keys generated" list):

• SHA256(Se26HZpLMfrCyKyzwAKoFy4XoqUKv?) = 0092378840ae9002c0588b6cf15040417410f647e374e2a9a4937aa39768419e

The ECDSA Private key is calculated without the "?" at the end and has no first Byte restrictions.
Ref: https://github.com/raritycheck/BTCMiniKeyGenerator/blob/a23567757fcc541cde0494f960682bca6d8a7d99/generator.py#L69-L75
e.g.:

• SHA256(Se26HZpLMfrCyKyzwAKoFy4XoqUKv) = 9694e04ab39ab01e9ce268b93821a3f0512c8475183efb80e80372f788447815
• WIF: 5Jxbz5v4W3iTu6LVze2E1xgUFS5ECheZFfc25i6cUywB5uLuqp1
• Addrs: 12UcdGZMANBKqvVS1s7GzvHQDcJ1aAB9Hf

Thank you.
Given that it is a mini key. Is it possible to use 256 bits ?


It was a site walletgenerator.net

[nc50lc]

Given that it is a mini key. Is it possible to use 256 bits ?

No, because the newer standard is still only 30 base58 characters and the first character is always "S";
Even if you managed to device a way to use a complete 256bit entropy to generate it,
the security wont still be 2^256 since an attacker could just go for the mini private key itself, and not the entropy.

It was a site walletgenerator.net

Oh, so it's not entirely related to mini private keys but about bad entropy.

[ABCbits]

It was a site walletgenerator.net

Oh, so it's not entirely related to mini private keys but about bad entropy.

Bad entropy? it's about malicious website/code. See these threads,
Vulnerability discovered on bitcoinpaperwallet[.]com - DO NOT USE IT
walletgeneratordotnet scam Paper wallet generation scam

[raritycheck]

Given that it is a mini key. Is it possible to use 256 bits ?

No, because the newer standard is still only 30 base58 characters and the first character is always "S";
Even if you managed to device a way to use a complete 256bit entropy to generate it,
the security wont still be 2^256 since an attacker could just go for the mini private key itself, and not the entropy.

It was a site walletgenerator.net

Oh, so it's not entirely related to mini private keys but about bad entropy.

Yes. The site has bad entropy or back door .. but we can’t trust anyone anymore.

Hence asking for feedback for mini keys.

[nc50lc]

Oh, so it's not entirely related to mini private keys but about bad entropy.

Bad entropy?

Yes "bad entropy", the attacker (or owner) replaced the pRNG by a deterministic approach, so the entropy is bad.

The backdoor isn't directly stealing bitcoins out of the victims through non-entropy related method.
It's because they edited the code's pRNG so that they can reproduce the private keys that the affected versions have generated.

[raritycheck]

Is there a process of getting the generator officially vetted?

Regards
Team RC

[ABCbits]

Oh, so it's not entirely related to mini private keys but about bad entropy.

Bad entropy?

Yes "bad entropy", the attacker (or owner) replaced the pRNG by a deterministic approach, so the entropy is bad.

The backdoor isn't directly stealing bitcoins out of the victims through non-entropy related method.
It's because they edited the code's pRNG so that they can reproduce the private keys that the affected versions have generated.

I see, that makes sense after you explain it in detail.

Is there a process of getting the generator officially vetted?

Regards
Team RC

Short answer, get a security audit.

[raritycheck]

Oh, so it's not entirely related to mini private keys but about bad entropy.

Bad entropy?

Yes "bad entropy", the attacker (or owner) replaced the pRNG by a deterministic approach, so the entropy is bad.

The backdoor isn't directly stealing bitcoins out of the victims through non-entropy related method.
It's because they edited the code's pRNG so that they can reproduce the private keys that the affected versions have generated.

I see, that makes sense after you explain it in detail.

Is there a process of getting the generator officially vetted?

Regards
Team RC

Short answer, get a security audit.

Who can do it?

[NotATether]

If the audio cannot be detected, or if there is no audio device, an exception will be raised (the program will crash), but due to try statements elsewhere, the private key will not be generated.

What is wrong with simply using /dev/urandom for entropy gathering? Maybe even /dev/random if you are wary of the pseudo-generated bits, but that is not really necessary as minikeys are much smaller and normal private keys.

Most servers do not have audio devices on-board and the ones that do (in the rare case), are not utilizing them so you will not be getting any data from them.

[ABCbits]

--snip--
Short answer, get a security audit.

Who can do it?

I barely know about this field. But generally you either.
1. Use automated audit service.
2. Hire an individual auditor.
3. Seek security company which offer security audit service.

You probably want to ask this question on either security/open source community or research how similar software/script got audited. For example, WALLET.FAIL which discover several weakness on hardware wallet is run by company called Keylabs. Take note it's just an example and i don't endorse them.