How do I import/export key as bytes array?

[CMEONE]

I would like to export the private key as an array of bytes and then import that into another private key. For this specific usecase, I would need an array of bytes, not an ascii-armored string. Additionally, I would want this array of bytes to be small, preferably under length 64 (which is why I cannot just convert the ascii-armored string to bytes). And, I want to be able to both export from a key and import this to create the identical key later.

Is this possible within openpgpjs? I have a feeling that it's somewhere in the Key class, but I'm not entirely sure which property it is and how to import it back into a new key object.

[tomholub]

Here's a snippet we use. It would be good to have this in the library 👍

  public static dearmor = async (text: string): Promise<{ type: OpenPGP.enums.armor, data: Uint8Array }> => {
    const decoded = await opgp.armor.decode(text);
    const data = await Stream.readToEnd(decoded.data);
    return { type: decoded.type, data };
  }

[CMEONE]

Ah, interesting, this is helpful... but I don't want to just convert the ascii-armored string to bytes. I would like a bytes array of under length 64. I guess that this would be the initial derivation bytes used to derive the key. I was thinking this might be the Key.keyPacket.keyMaterial array, but I'm not 100% sure and also I don't know how to use that to load an identical key later on.

[tomholub]

I didn't read your whole message. I was just referring to exporting it as unarmored bytes, nothing else. Sorry for confusion.

[CMEONE]

@twiss Do you know a solution? Is Key.keyPacket.keyMaterial the derivation bytes? And can these bytes be used to rederive the key using openpgpjs? If not, is there any other bytes array of under length 64 that can be used to export/import a key?

[CMEONE]

@larabr @twiss Any updates on whether Key.keyPacket.keyMaterial can be used to rederive a key, and if so, how?

[twiss]

Hey @CMEONE 👋 No, this isn't really possible, sorry. For one, to encrypt or decrypt messages, you also need the subkey material. Then, for it to be the same OpenPGP key, you also need a bunch of metadata (creation time, etc). If you want something short, it might be better to use a raw ECDH key. E.g. see https://github.com/dchest/tweetnacl-js. Obviously this won't be compatible with OpenPGP, though.

[CMEONE]

@twiss Ah, I see. Will there be any sort of deterministic key generation in the future (besides loading an armored private key), perhaps in v6 or later? Something like 12 word / 24 word seed phrases to load in a key (similar to how cryptocurrencies work)? I mean I can allow users to create a backup using a keyfile which stores the armored private key, but from a UX perspective, I would prefer the 12/24 word seed phrase approach (using a length 2048 words list as described in BIP39).

I prefer PGP over NaCl, is it possible to do any sort of deterministic keygen through OpenPGP.js, or will that be added sometime in the future?

If not, any way to manually create these keys with lossy conversion (I'm totally fine losing metadata such as userids or creation time and just upon key generation, regenerating with the lossy version)?

[twiss]

No, nothing like this is planned, sorry. You could offer to host the key encrypted (on the client) with the seed phrase or a key derived from that, and allow them to download and decrypt it when they want to retrieve their data.

[CMEONE]

Right, my plan was to offer hosted encrypted backup on the server or just give them the encrypted keyfile containing the armored private key. I was just wondering if high-entropy brainwallet was possible with this lib or would be possible at some point is all.

[CMEONE]

Hey @twiss, just wanted to follow up here because I had a different idea. By looking through the Key constructor, I found there is a way to manually generate a new Key based on a key packet. Is this true, and if so, how do i create the key packet? What information needs to be supplied? I don't really care too much about the metadata of the key (creation time, user ids, etc.), but I would like to have access to the openpgp.js features from that Key (decrypt, sign, etc.). Is this possible?

[twiss]

Maybe, but you do you have to pass the metadata (creation time, user ids, etc) for OpenPGP.js to consider it a valid key.

I prefer PGP over NaCl

Could you elaborate on this? It sounds like PGP is not the right tool for the job you want to do, tbh.

[CMEONE]

@twiss I can pass in a dummy creation time or user ids or store that data on server, but I preferably do not want the server ever touching the private key (encrypted or not). I also want to make it easy for someone to backup, with a 12 word or 24 word phrase. The phrase can be randomly generated based on openpgp.js random or Web Crypto API and the BIP39 word list, then to derive key the words are hashed along with an optional nonce/index (allowing generation of many keys), then converted to bytes which can then be used to derive a key manually by creating a new Key object, which can have the extraneous data passed in from the server or have dummy data instead.

I'd prefer using PGP, I can use NaCl and that's not an issue but I'd much rather use PGP since I'm more comfortable with it. NaCl is newer, and I'm not as familiar with it. Since I'm working with cryptography, I'd better be dead sure I'm doing everything right.

[twiss]

I preferably do not want the server ever touching the private key (encrypted or not).

Hmhm, I understand. However - are you planning to encrypt files with this key-derived-from-words, and store those on the server? If so, it means you're trusting the encryption. Adding an extra intermediary step (encrypting them with a key which you encrypt with the bip39 mnemonic) doesn't meaningfully reduce the security, and makes it easier to change the mnemonic, if needed.

I'd prefer using PGP, I can use NaCl and that's not an issue but I'd much rather use PGP since I'm more comfortable with it. NaCl is newer, and I'm not as familiar with it. Since I'm working with cryptography, I'd better be dead sure I'm doing everything right.

IMHO, you're more likely mess something up when (ab)using PGP in a weird way, than using NaCl in the normal way. In either case, getting it reviewed by a cryptographer would be ideal. Even when using an integrated solution such as PGP, it's possible to mess up the security of the application.

[CMEONE]

@twiss Ok, looks like NaCl might be better suited for what I'm trying to do. I'll look into the repo you posted earlier. Thanks so much for your help!

[twiss]

No problem, good luck!

[AndreasGassmann]

@CMEONE Were you able to get this to work somehow, or did you abandon the idea? I opened a related discussion, here a summary:

BIP85 describes a way how entropy can be derived deterministically from a BIP32 root key, for example a BIP39 mnemonic (24 words) commonly used in cryptocurrency wallets.

In our app, AirGap Vault, we would like to add the functionality to let users derive GPG keys from their seeds using BIP85. The python reference implementation includes an example how it is done: https://github.com/ethankosakovsky/bip85/blob/7892bbddc51f498d1a693cca3f6d642b75cb3373/bip85/tests/test_bip85rsa.py

See full post here: #1309

It looks like BIP85 defines how the metadata has to be handled (eg. creation timestamp), addressing the concerns of @twiss. BIP85 is still a fairly new standard, but it is slowly gaining adoption in the cryptocurrency world.

The use case I had in mind sounds similar to what @CMEONE wanted to do. Basically, it would allow you to deterministically generate a PGP key using your mnemonic. The big advantage of this is that you ONLY have to securely back up your seed, (eg. using Shamir's Secret Sharing), you don't have to worry about backing up anything else.

As @twiss pointed out, one option would also be to simply generate a new keypair, encrypt it using the mnemonic and then backing it up to a server. While I would personally prefer if none of my secrets ever touched the internet, security wise, there is no issue with this approach. However, it does provide worse UX than deriving the keypair directly from the mnemonic. The user now additionally has to transfer the encrypted key out of the secure device, back it up and make sure he doesn't lose access to it. Whereas with the first approach, you could have a simple button that would generate a new PGP key that the user can always recover if he has to.

Besides the fact that it is currently not possible in openpgpjs or with webcrypto, is there anything wrong with this approach? Are there any easy "workarounds" that could be used for a proof-of-concept in a non-production environment?

As to the question why PGP instead of NaCl: One thing I would like to do is allow users to use our offline app (AirGap Vault) to sign git commits in an air-gapped fashion while their key is on an offline device. And as far as I understand, for that, the user needs a PGP/GPG key.

[larabr]

I quickly skimmed through BIP85, and while it does address how to set the creation date, it still looks like there is no way to preserve UserIDs and certifications. Whether this is an issue really depends on how the key will be used, so I cannot comment much on that.

[AndreasGassmann]

I don't understand enough about PGP to comment on the specifics. But on a high level, if you control the entropy that is used during the generation of a keypair, shouldn't it be possible to generate everything deterministically? Even things like the creation time and userIDs could be derived from the initial entropy if necessary.

I can reach out to the creator of BIP85 and ask those questions. Maybe the specifications have to be adjusted to handle some additional cases regarding PGP.

In general, I feel like BIP85 could provide an improvement in user experience for both cryptocurrency and PGP users. So in the long term, I hope this is something that can be properly specified (maybe in BIP85) and supported across a wide range of libraries.

[larabr]

It's true that a long enough seed lets you generate whatever you like, but note that ECC OpenPGP keys are actually fairly short on their own, so at some point, it might be easier to think of a way of converting a [decrypted?] armored key into mnemonics, and store those (i.e. changing key encoding rather than expanding randomness).

[AndreasGassmann]

One of the BIP85 derivations actually defines a pseudo random output of arbitrary length, so that shouldn't be an issue.

I'm sure the PGP keys could be converted into mnemonics. But unless they are a specific length, they couldn't be used as a BIP39 mnemonic. And I'm assuming if all the metadata (date, userIDs, certifications, etc.) would have to be encoded as a mnemonic, that would be a pretty long one, basically defeating the potential UX improvements I mentioned.

I guess the best solution at the moment is to generate and back them up separately. I hope as time goes on, a standard will emerge that solves this.

Anyway, thanks for your help!