I am using BIP39 specifications to generate 12 word mnemonic which will later used to generate Master Public/Private and their 2^32-1 child keys. These children keys will then be used for asymmetric encryption.
import (
"github.com/tyler-smith/go-bip39"
"github.com/tyler-smith/go-bip32"
b64 "encoding/base64"
)
type BipKeys struct {
Entropy []byte
Mnemonic string
Passphrase []byte
Seed []byte
MnemonicShares []string
RootPublicExtendedKey *bip32.Key
RootPrivateExtendedKey *bip32.Key
RootPrivateHexKey string
}
func(instance *BipKeys) GenerateEntropy(numberOfBytes int)([]byte, error){
entropy, err := bip39.NewEntropy(numberOfBytes)
if err != nil {
log.Printf("There is some error generating entropy %s", err)
}
return entropy, err
}
func (instance *BipKeys) GenerateMnemonic(entropy []byte) (string, error){
mnemonic, err := bip39.NewMnemonic(entropy)
if err != nil {
log.Printf("Some error in generating Mnemonic %s", err)
}
return mnemonic, err
}
func (instance *BipKeys) GeneratePassphrase(saltBytes int, passphraseBytes int) ([]byte, error){
salt := GenerateRandomSalt(8)
passphrase := GenerateRandomString(8)
password, err := GenerateScryptKey(salt, []byte(passphrase))
return password, err
}
GenerateRandomString and GenerateRandomSalt just generates random string and bytes based on crypto/rand packages.
My question is, When people say that the keys not generated properly from random functions are susceptible to break, what they actually mean? How can I check that the bip39.NewEntropy(numberOfBytes) is actually generating the perfect entropy required for Mnemonic? Is there any way by which I can check if 12 word mnemonic can be generated just by exposing first 5 words (which means the entropy function implementation wasnt correct and is susceptible to attack)?
My question is, When people say that the keys not generated properly from random functions are susceptible to break, what they actually mean?
Bad randomness is attacked in cryptography in two ways:
By exhaustive search of the seed that was used to generate the stream of bits. A prominent example is the Debian OpenSSH vulnerability.
By attacking the predictability of random number generators that were not designed to meet cryptographic requirements. In statistical random number generators, the main requirement is that the data looks random. In cryptographic random number generators, we require more: given the stream of bits, a very smart person who knows the algorithm cannot figure out what future or previous bits for the random number generator are. As an example, although the Mersenne Twister has a large internal state, it does not meet the cryptographic requirement.
Your question about measuring entropy is the wrong question. Measuring entropy is treating it like it is a statistical random number generator, not like a cryptographic random number generator. You say:
GenerateRandomString and GenerateRandomSalt just generates random string and bytes based on crypto/rand packages.
That's all you need to know -- you should not need to worry about anything else. As mentioned above, no amount of measuring entropy is going to tell you that your keys are secure. Instead, you need to be a cryptographic expert to analyse such algorithms. For a consumer of the randomness, all you can do (short of using another source such as /dev/urandom) is trust that this has been designed well and analysed by cryptographic experts.