Is there a (simple) way to create a PGP key from a seed?

[Saint-loup]

Hello
I'm looking for a way to generate a PGP private key from a Bitcoin mnemonic seed (or a private key)
Does anyone know how I could do it please?
Thank you very much

[1714796426]

1714796426

[1714796426]

1714796426

[Bitcoin577]

Hello
I'm looking for a way to generate a PGP private key from a Bitcoin mnemonic seed (or a private key)
Does anyone know how I could do it please?
Thank you very much

I am new here on this forum and new in many other things I was also looking for any guide for PGP private key generator so have this check hopefully this will helps you as well https://www.youtube.com/watch?v=4PZb0tkxuUk

[odolvlobo]

Hello
I'm looking for a way to generate a PGP private key from a Bitcoin mnemonic seed (or a private key)
Does anyone know how I could do it please?
Thank you very much

I'm not an expert on PGP, but I know that it can use ECC with 256-bit private keys, so I guess BIP 32 and BIP 39 can be applied. However, I have never seen it.

[pooya87]

there is no tool or proposal for doing something like that in bitcoin world if that's what you are asking. but the principles are the same. you have a seed, a key derivation function, and child keys derived from that seed. so all you have to do is to choose a BIP-32 derivation path (eg. m/3146786'/9012455'/0 random path to avoid using anything that may be in use) and derive a new bitcoin private key (ie. a 256-bit number). then use that as your PGP key assuming you want a 256-bit long PGP key (i believe it is safe if you choose ECC algorithm not RSA).

if the PGP key is not 256-bit (eg. 4096 bit RSA or 384 bit ECC) then you have to take a step back right before going into BIP32 and use a different key size in PBDKF2 when you derive the BIP-32 seed using the mnemonic, and use that derived key as the PGP private key.

[NotATether]

if the PGP key is not 256-bit (eg. 4096 bit RSA or 384 bit ECC) then you have to take a step back right before going into BIP32 and use a different key size in PBDKF2 when you derive the BIP-32 seed using the mnemonic, and use that derived key as the PGP private key.

This is what’s going to end up being done most of the time because a 256-bit ECC key is only as secure as 3072-bit RSA, and GPG creates 2048-bit RSA keys by default, with an option for 4096-bit.

Researchers have grouped together different asymmetric keys that have equivalent security. This table comes from a cryptography standard.



https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page67

512 bit ECC is equivalent to 15360 bit RSA, 384 bit ECC is equivalent to 7680 bit RSA, I wouldn’t recommend using the large RSA keys because they require so much more entropy than their ECC counterparts.

So I wouldn’t waste time with putting the private key bits into RSA, and just make a 512 bit key size in PBKDF2. After all everybody relies on AES256 and not AES192 so I don’t see why people should use 384 bit ECC key sizes especially since we are making a PGP private key out of them.

[AdolfinWolf]

There's a blog about deterministic PGP key generation at https://blog.summitto.com/posts/deterministic_pgp_deep_post/, which links to this software https://github.com/summitto/pgp-key-generation
I don't try it since there's no guide how to compile it, but according to https://github.com/summitto/pgp-key-generation/blob/master/src/generate_derived_key/generate_derived_key.cpp#L49, you can enter custom recovery seed which could be anything (including bitcoin seed/private key)

If you're gonna use a third-party library, - I'd opt for something like this https://github.com/skeeto/passphrase2pgp

Although this seems password based, so for deriving "multiple" keys from a seed you'll need to write some additional stuff. basically the workflow would be that you take a seed, derive a key, use the key as a password.

As long as you remember the seed and derivation path, you should be able to regen your PGP keys, no? Admittedly, it's less than ideal.

[pooya87]

As long as you remember the seed and derivation path, you should be able to regen your PGP keys, no? Admittedly, it's less than ideal.

using one seed to generate everything (your bitcoin keys, PGP key, etc.) also adds an additional risk that if you lose or leak that seed you will lose everything.

[PrimeNumber7]

As long as you remember the seed and derivation path, you should be able to regen your PGP keys, no? Admittedly, it's less than ideal.

using one seed to generate everything (your bitcoin keys, PGP key, etc.) also adds an additional risk that if you lose or leak that seed you will lose everything.

Typically people will store their various keys together in the same mediums, and store backups together. So if something happens such that you lose access to one set of keys, chances are you will lose access to all your keys.

IMO, the greater risk is that a seed might get exposed due to cryptographic weaknesses that one set of keys uses, and this weakness would end up exposing all of your keys. For example, if a hypothetical weakness in ECDSA allowed someone to determine a bitcoin private key, and to use a bitcoin private key to determine your seed, then your PGP keys would be exposed if you are using the same seed for both your PGP key and your bitcoin keys.

[pooya87]

IMO, the greater risk is that a seed might get exposed due to cryptographic weaknesses that one set of keys uses, and this weakness would end up exposing all of your keys. For example, if a hypothetical weakness in ECDSA allowed someone to determine a bitcoin private key, and to use a bitcoin private key to determine your seed, then your PGP keys would be exposed if you are using the same seed for both your PGP key and your bitcoin keys.

when you derive a key using KDFs (like the second part of my initial comment) or if the key was derived using a hardened path in BIP32 scheme then everything is irreversible and even if any child private keys were leaked the master key (or the seed) will never be revealed. it is simply impossible because the process which consists of mostly SHA512 hashes is not reversible, ever.

[NotATether]

IMO, the greater risk is that a seed might get exposed due to cryptographic weaknesses that one set of keys uses, and this weakness would end up exposing all of your keys. For example, if a hypothetical weakness in ECDSA allowed someone to determine a bitcoin private key, and to use a bitcoin private key to determine your seed, then your PGP keys would be exposed if you are using the same seed for both your PGP key and your bitcoin keys.

That means any bit size larger than 256 bits for ECDSA won’t improve the overall security of the PGP key since a bitcoin private key is made from 256 bits of entropy, unless the PBKDF2 salt is randomized, but even then would it provide the required number of entropy bits (384-256=128) to make it equivalent to a 384 bit ECDSA key? I don’t think it will if the derivation path decides the KDF salt because it’s capped to 2^31 numbers. Then it would usually take a shorter time to attack the seed phrase if several bits of it were leaked, and then attack the salt than to directly attack a PGP private key even if the same number of bits were leaked.

That means security is capped at 256 bits of entropy and for this reason so it leads me to think it’s safer to generate entropy for larger ECDSA keys directly instead of relying on seed phrases and key stretching.

when you derive a key using KDFs (like the second part of my initial comment) or if the key was derived using a hardened path in BIP32 scheme then everything is irreversible and even if any child private keys were leaked the master key (or the seed) will never be revealed. it is simply impossible because the process which consists of mostly SHA512 hashes is not reversible, ever.

It’s probably better to use child keys with a hardened derivation path than the master key or the seed phrase because they’d still have to guess the derivation path or KDF salt that was used to derive the child key, since all of these processes are irreversible.

[PrimeNumber7]

The inability to calculate x with a given y is based on currently known theorems. It is always possible that currently accepted theorems are disproven with additional research and new methods of breaking cryptography (or parts thereof) are invented.

In my example, the cryptography behind ECDSA is broken, and in this example, someone with a single seed used to generate keys that use both ECDSA and other cryptography methods would have their keys secured by other cryptography methods compromised if ECDSA is broken.

I would point out that after ~7 years, a billion dollars worth of Silk Road coins were seized by the DOJ. How did the feds obtain the private keys to seize these coins? I don't know. It could be that Ulbrights' PGP key was compromised. I think it would be more likely that methods to crack Steganography were improved, and the keys were found in a hidden file. In any case, previous methods intended to keep information private is no longer useful in keeping information private.

[pooya87]

~

key derivation from a parent entropy uses hash algorithms not ECDSA and you can never reverse hashes because there isn't exactly any math involved in hash algorithms, they are more like chaotic operations that toss bits around that have no way of being reversed.

[odolvlobo]

I would point out that after ~7 years, a billion dollars worth of Silk Road coins were seized by the DOJ. How did the feds obtain the private keys to seize these coins? ...

The person with the private key agreed to forfeit the money.