I have cross-checked the seeds generated from the mnemonics with some other BIP39 wallets. I found that although the relation between English mnemonics and entropy conforms the BIP-0039 standard, the seed generation did not match even when only using ASCII (0..127) characters in the password (I know the UTF-8 normalization is still missing there).

I have added failing tests, but could not get them pass yet.

To manually cross-check the test-cases I have added based on the Trezor test-vector referenced from the standard, please

• visit https://iancoleman.io/bip39/
• Fill the "BIP39 Passphrase" field with "TREZOR" (all caps)
• tick the "Show entropy details" checkbox
• copy the entropy from a test-item in the test vector and paste it into "Entropy" field
• compare the "BIP39 Seed" field with the seed in the test-item. They should be identical

I think the problem should be somehow in the crpyto::pbkdf2 implementation, but could not narrow it down.

I did some minor refactoring on top of #14

Includes the API improvements, fixes, and most of the performance boosts from #14 but uses newer dependencies based on recent advances in the Rust ecosystem.

• replaces FxHashMap with hashbrown for ~2x the performance boost (~8x performance boost on top of the original hashmap). hashbrown is also going to be merged into the rust std so it will allow for the dependency to be dropped in the future.

• removes ring as a dependency in favor of smaller specialized crypto libs that have came out of rust crypto recently. No longer depends on ssl implementations.

Hi, first of all, thanks for providing this crate. I'm here to ask a question and complain about the API a bit. Sorry. :D

My question is: how to generate a mnemonic from existing key? Bip39 describes the general conversion of encoding a key into a human-friendly string. It could be used outside of Bitcoin, etc. and that was my plan. I already have a key generated.

struct Bip39 seems confusing. There is no such object as Bip39. There could be bip39:: Mnemnonic , but clamping all the functions into a struct doesn't seem to serve any purpose.

The whole crate could be just couple two functions:

fn mnemonic_to_key(&str) -> Result<Vec<u8>> and fn key_to_mnemonic(&[u8]) -> Result<String> + bit39::Result error types. Lenght of the string/vec already provides KeyType? The lang stuff could be skipped until someone actually makes an effort to implement it? :)

Please let me know what you think, etc. I am planing to use this crate for some stuff, so I was just wondering: maybe I could make a PR or something.

I noticed that when you click in the documentation you get taken to the instructions for version 0.5.1, which has examples that aren't in compliance with the most up to date version of this crate. Since the actual link being used is https://docs.rs/bip39, I think this problem is with docs.rs, and nothing in the actual repository.

Disclaimer: This is a really big PR and I'm happy to make a fork of the crate and maintain it on crates.io if you'd rather not change the API as much as I've done here.

• Reworked most of the API surface, removed methods dealing with hex-encoded strings, added LowerHex and UpperHex trait implementations to both Mnemonic and Seed for printing those out as hex. In general, I don't think parsing hex-encoded strings is within the scope of the library.
• Added remaining languages.
• wordlist now operates on &'static str instead of allocating Strings. When retrieved from Language, it returns a &'static [&'static str] instead of a &'static Vec<String>.
• Similarly, WordMap is a newtype wrapping around FxHashMap<&'static str, u16> (which is just a regular HashMap using fast hashing algo from rustc, it's not as secure in terms of collisions as the default, but since we aren't allowing any insertions it shouldn't matter).
• Replaced Result<T, Error> with custom Result<T> and switched to using the bail! macro from error_chain to reduce some boiler plate.
• Removed bit-vec, bitreader and data-encoding dependencies.
• Added benchmarks (rustup run nightly cargo bench) and a bunch new tests when necessary.

Performance:

• Validating phrases is now ~6x faster.
• Creating a new Mnemonic from entropy is way faster (I don't have the original figures) due to reduced number of allocations (worst case scenario is 2-4 depending on the length of the key).
• Generating a new Mnemonic (skipping Seed generation) from random entropy is now 20x+ faster.

test from_entropy ... bench:         418 ns/iter (+/- 229)
test new_mnemonic ... bench:         560 ns/iter (+/- 347)
test new_seed     ... bench:   1,404,971 ns/iter (+/- 397,740)
test validate     ... bench:         657 ns/iter (+/- 591)

Generating a Seed is obviously most expensive due to the 2048 pbkdf2 rounds.

• Removed bitvec dependency, wrote a quick BitWriter struct that allows pushing 11 bits onto a Vec<u8> at once.
• Removed a bunch of unnecessary allocations. This results in some (not all) functions that used to take generic S: Into<String> to take &str, which is more idiomatic although it is a breaking change on the API surface. Functions that need allocated strings (constructors that return owned structs mostly) remained unaffected.
• wordlist and wordmap work using &'static str instead of Strings to avoid unnecessary allocations (not very critical).
• Replaced Result<T, Error> with custom Result<T> from error_chain.
• Bunch of smaller idiomatic changes that I likely can't recall here.
• Added benchmarks (rustup run nightly cargo bench). Phrase validation time has been cut to nearly a quarter of original time.

I've clone repo and tried to install, but cargo doesn't see it as valid package.

bip39-rs $ cargo install
error: no packages found with binaries or examples
$ cargo install --path .
error: no packages found with binaries or examples
$ cargo install --git https://github.com/infincia/bip39-rs
    Updating git repository `https://github.com/infincia/bip39-rs`
error: no packages found with binaries or examples   
$ cargo --version
cargo 0.25.0

Other packages work fine, e.g.

$ cargo install --git https://github.com/rigelrozanski/dicedemon
    Updating git repository `https://github.com/rigelrozanski/dicedemon`
  Installing dicedemon v0.1.0 (https://github.com/rigelrozanski/dicedemon#02fcdf40)

This is the opposite of get_entropy and get_entropy_hex, it's needed if you want to go from the entropy to the mnemonic.

I noticed there was some related discussion in #5, so I'm not sure if that was ever resolved.

cache word list+word map using lazy_static!

The current implementation parses the word list over and over again. Using lazy_static! we can do the operation only once and use it directly the next time the crate is used.

introduce to_entropy / to_entropy_hex

other bip39 implementations all feature the to_entropy call, which converts a mnemonic to the original entropy value. to_entropy_hex returns a hex formatted string of the entropy bytes.

Feedback about the API

Generally, I agree with #4 and the API for this crate should by different. Seed and MNemonic should be distinct types that can be initialized by calling ::from(String) or ::new, expose functions to convert between each other and and to/from entropy, as well as each providing their own .as_hex() etc. . This way using the create would be a lot easier and intuitive.

This crate has a bug. I noticed it doesn't have any unit test that verifies the implementation against the test vectors in the BIP39 spec.

    #[test]
    fn test_bip39() {
        let v_entropy = "68a79eaca2324873eacc50cb9c6eca8cc68ea5d936f98787c60c7ebc74e6ce7c";
        let v_mnem = "hamster diagram private dutch cause delay private meat slide toddler razor book happy fancy gospel tennis maple dilemma loan word shrug inflict delay length";
        let v_seed = "64c87cde7e12ecf6704ab95bb1408bef047c22db4cc7491c4271d170a1b213d20b385bc1588d9c7b38f1b39d415665b8a9030c9ec653d75e65f847d8fc1fc440";
        let v_passphrase = "TREZOR";


        let mnem = bip39::Mnemonic::from_phrase(v_mnem, bip39::Language::English).unwrap();
        let seed = bip39::Seed::new(&mnem, "TREZOR");
        assert_eq!(v_seed, &hex::encode(&seed.as_bytes()));

    }

That example is director from the spec and it fails.

Hi,

I've reviewed this crate using cargo-crev.

Some notes:

• maybe you should not implement Debug for Seed and Mnemonic. Debug makes it easy to accidentally log them somewhere and thus leak them.
• there are multiple issues that cargo clippy will point out - nothing serious, but it is a good idea to just do what Clippy says. :)

Using failure might be easy internally, it's really annoying for external users not using failure. There is no way to catch the error and convert in another type while keeping some information intact.

This PR applies the fix @maciejhirsz mentioned in #17 (giving co-author credit). It also includes @wigy-opensource-developer's test and reverts back to using the rust only crypto crates.

Fixes #17

Any opinion on whether this crate would be a good home for incompatible improvements to BIP32, provided the improvements are dramatic enough?

Argon2 would be an obvious improvement over PBKDF2.

If I understand, BIP32 already requires the same wordlist for checksums, yes? I could imagine either (a) improving that to actual error correction, which sounds very user friendly but requires the same wordlist, or (b) making the checksum work without the original wordlist, but doing both (a) and (b) together sounds hard.

Any idea if anyone ever considered the wordlist size question? I know diceware recommends a larger wordlist with like 12.9 bits per word, but not sure if such a wordlist can easily avoid confusables in all desired languages.