The standard BIP39 does three things:

1. Generate 256+8 entropy

2. Generate sentence

3. Derive seed from sentence (using PBKDF2 with HMAC-SHA512).

I wonder what would be the security implication of doing things this way:

1. Generate entropy and use it as seed

2. Derive 256 bit array from entropy (using PBKDF2 with HMAC-SHA256/HMAC-SHA512). + 8 bit checksum

3. Use above bit array to construct sentence

Essentially, instead of creating the seed from the sentence, I create the sentence from the seed. In the last step, if HMAC-SHA512 is used, it would generate a bit array of length 512 which is too long for the sentence. To solve that I would XOR the two halves of the array. Alternately, I could just use HMAC-SHA256.

Why would I do things this way you may ask. The company I work for has a library that does seed generation and this is what we are mandated to use.

The standard BIP39 does three things:

1. Generate 256+8 entropy

2. Generate sentence

3. Derive seed from sentence (using PBKDF2 with HMAC-SHA512).

I wonder what would be the security implication of doing things the reverse way:

1. Generate entropy and use it as seed

2. Derive 256 bit array from entropy (using PBKDF2 with HMAC-SHA256/HMAC-SHA512). + 8 bit checksum

3. Use above bit array to construct sentence

Essentially, instead of creating the seed from the sentence, I create the sentence from the seed. In the last step, if HMAC-SHA512 is used, it would generate a bit array of length 512 which is too long for the sentence. To solve that I would XOR the two halves of the array. Alternately, I could just use HMAC-SHA256.

The company I work for has a library that does seed generation and this is what we are mandated to use.