Non-Deterministic and Incorrect Key-Pair from Mnemonic when `bip39` is pulled in as `3.1.0`

[fedellen]

It seems that when this library pulls in bip39 as 3.1.0 we are getting incorrect key pairs from seed phrase to key pair generation.

There is some strange behavior going on here. The seed produced by bip39 remains the same each time we run it. But later on in the generate part of human-crypto-keys we see the results start to differ.

// src/testme.js

import { getKeyPairFromMnemonic } from "./index.js";
import * as bip39 from "bip39";

const mnemonic =
    "slender during cost problem tortoise extra deal walnut great oblige planet kid";

(async () => {
    const seedBuffer = await bip39.mnemonicToSeed(mnemonic);
    const seedBuffer2 = await bip39.mnemonicToSeed(mnemonic);
    console.log(
        "seed buffer to hex string from bip 39 mnemonic to seed are the same?",
        seedBuffer.toString("hex") === seedBuffer2.toString("hex")
    );

    const { privateKey } = await getKeyPairFromMnemonic(
        mnemonic,
        {
            id: "rsa",
            modulusLength: 4096,
        },
        { privateKeyFormat: "pkcs8-pem" }
    );
    const { privateKey: privateKey2 } = await getKeyPairFromMnemonic(
        mnemonic,
        {
            id: "rsa",
            modulusLength: 4096,
        },
        { privateKeyFormat: "pkcs8-pem" }
    );
    console.log(
        "private keys are the same after get key-pair from mnemonic?",
        privateKey === privateKey2
    );
})();

Results on bip39 3.0.2:

> node lib/testme.js
seed buffer to hex string from bip 39 mnemonic to seed are the same? true
private keys are the same after get keypair from mnemonic? true

Results on bip39 3.1.0:

> node lib/testme.js
seed buffer to hex string from bip 39 mnemonic to seed are the same? true
private keys are the same after get keypair from mnemonic? false

In the version 3.1.0, the bip39 package changed their dependencies substantially and added @noble/hashes. This new dependency seems to alter several global cryptos. I still don't yet understand why this would effect the outcome given that the result from bip39 remains the same -- but locking the version of bip39 to 3.0.2 does fix the issue on our end...