Import Private Key

[llbster]

Currently, as I understand, the only way to import a wallet is with the bip39 mnemonic. When I need to create a transaction from the rubble of post-blast New York, I don't want to have to mess around with laptops and bip39 to make that vital 'let me out' transaction from my emergency wallet.

I suggest the process be something like: Retrieve the digits of the private key from wherever they are tattooed onto your body. Import the raw private key into AirGap. (Option: Sweep the coins into a new wallet, or use the existing wallet in AirGap wallet.) Pay the Duke for permission to leave. ...

[AndreasGassmann]

Hi, thanks for reaching out to us.

I do see the benefit of providing a way to import private keys / paper wallets to do a one time transaction. This was discussed also here: https://github.com/airgap-it/airgap-vault/issues/16. At the moment we sadly don't have any resources to work on this though. We are currently busy with many other improvements, such as segwit support.

A PR would be highly appreciated if you have time to look into this.

That being said, I don't fully understand your argument of why private key support would be better in this post apocalyptic scenario.

[...] I don't want to have to mess around with laptops and bip39 [...]

If you were to use our wallet for the recovery, a laptop wouldn't be necessary because bip39 is fully supported. So there is no benefit of using private keys over bip39 mnemonics. I would actually argue that a bip39 mnemonic tattoo would be easier to recover in case you have any injuries and some letters become illegible. You might be able to reconstruct it with the help of a wordlist, rather than having to brute force the missing characters.

[llbster]

There are some issues with retrieving the wallet address from the bip39 mnemonic. e.g. using the derivation path shown in common JS bip39 web implementations does not return the same wallet as in airgap (and electrum).

Finally, "a bip39 mnemonic tattoo would be easier to recover" sadly irrelevant if you already have the private-key tattooed onto your dingus... ;)

[AndreasGassmann]

e.g. using the derivation path shown in common JS bip39 web implementations does not return the same wallet as in airgap (and electrum).

This is because electrum is not using the bip39 standard (by default): https://electrum.readthedocs.io/en/latest/seedphrase.html#motivation

We'll keep this issue open and update it if we have any developments in this area.

[crcdng]

If you were to use our wallet for the recovery, a laptop wouldn't be necessary because bip39 is fully supported. So there is no benefit of using private keys over bip39 mnemonics. I would actually argue that a bip39 mnemonic tattoo would be easier to recover in case you have any injuries and some letters become illegible. You might be able to reconstruct it with the help of a wordlist, rather than having to brute force the missing characters.

As far as I know, when a user imports an account into Temple (Tezos) wallet, exporting the Temple wallet ("Reveal seed phrase") only contains the accounts created within Temple - not included that imported key (if I am not missing something with an alternate derivation path). In this scenario the only way to import this account would be to export its private key ("Reveal private key"). And that key cannot be imported into Airgap Vault.

I believe the reason is that it is more convenient and familiar for users to export / import one key per account than to fumble with derivation keys.

[AndreasGassmann]

I don't know what different key formats Temple Wallet supports, but if you import a standard BIP39 mnemonic into both AirGap Vault and Temple Wallet (select "Default Account" when importing), you will get the same address.

[crcdng]

I don't know what different key formats Temple Wallet supports, but if you import a standard BIP39 mnemonic into both AirGap Vault and Temple Wallet (select "Default Account" when importing), you will get the same address.

Thanks for the quick reply. Because Temple also allows import (see screenshot) and export from a secret key there might be accounts for which you have the secret key but not the mnemonic.

.

[AndreasGassmann]

The only places where I have seen private keys used is either during the fundraiser, or during development. The most widely adopted standard is definitely BIP39. Because AirGap Vault is focussed on security, we do not recommend users migrate any kind of private key to AirGap Vault because chances are high that they were generated or used in a more insecure environment. So we recommend generating a new, standard BIP39 mnemonic in AirGap Vault for the best security.

[crcdng]

The only places where I have seen private keys used is either during the fundraiser, or during development. The most widely adopted standard is definitely BIP39. Because AirGap Vault is focussed on security, we do not recommend users migrate any kind of private key to AirGap Vault because chances are high that they were generated or used in a more insecure environment. So we recommend generating a new, standard BIP39 mnemonic in AirGap Vault for the best security.

Just to note that it is not uncommon at all, as both Temple and Galleon wallet support exporting private keys, Galleon supports import via a keyfile (as does Kukai), Temple lets you import accounts via private key as mentioned. Fundraisers do not use private keys, but key phrases. Possibly the approaches of others might be more insecure. The lack of common practice is a bit frustrating, but I understand the reasoning.

[d10r]

I can see more reasons for why PK import would be useful:

There's cases where no passphrase exists (e.g. accounts created in Ethereum wallet format years ago) and sweeping would be very expensive and cumbersome (tthink many tokens, staked in various protocols, possibly with timelocks...)

On a more fundamental level it seems to me that having BIP39 passphrase as only option kind of defies BIP-32.
The Motivation section of BIP32 reads: ... However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. ... Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains.

This is great and would allow me e.g. to have one mnemonic which I'd make the effort to store in my brain, from which multiple purpose specific (and security level specific) keypair chains are derived and used in different places / on different devices.
The main problem with that approach currently is that a lot of applications (this one included) don't work with private keys as input, thus one still can't use such keypair chains and we're back at the all-or-nothing problem mentioned by BIP32.
Instead an application like this one could allow to also import private keys - ideally even allow to derive further keys from user provided paths.

To give an example, lets say I have an mnemonic with 2 top level sub-trees aka purposes in BIP43 lingo:

1. m/1337'
2. m/7331'

Lets say I want to use the 7331 sub-tree in a less secure environment.
If I could import the private key of that node to a wallet and derive from there, I could e.g. derive from path m/0' in order to get the key I'd get at m/7331'/0' from the master key.
If however the wallet insists on getting a mnemonic, I have no choice but to expose the master key (and thus all sub-trees) to that application, rendering the whole exercise pointless (at least regarding security). To achieve that isolation, I must instead use and manage distinct mnemonics, giving away much of the potential benefits of BIP32.

Even just private key import (without the ability to derive other keys on that sub-tree) would imo be very helpful for that use case. One could easily use a helper application for the derivations from the sub-trees - UX would be less smooth, but the security level similar (no need to expose the master key).

I understand if this is not a priority. Still, I'm genuinely interested if my train of thought has some flaw, because I really struggle to understand why no HW wallet or vault type application (none I'm aware of) provides an option to import private keys.

[AndreasGassmann]

@d10r I think what you are looking for is BIP-85.

BIP-85 allows you to deterministically derive mnemonics from a "master mnemonic". Those "child mnemonics" can then be used on other, potentially less secure, applications. AirGap Vault supports BIP-85: https://support.airgap.it/features/bip85/

---

In my opinion, there are 2 main reasons why end-user wallets do not generally support private keys:

1. The point of having mnemonics is that they are human readable and can easily be backed up. Raw private keys are less "usability friendly" and were often used in older applications, so they are considered legacy (in the context of end users, they are obviously still widely used in a technical context).
2. Adding support for private keys might not be trivial due to the architecture of the wallets.

For AirGap Vault, both of those points apply. There is also a third reason, which is that we don't really want people to import their old keys, because chances are that it was generated / used in an insecure environment (not air-gapped). So having users set up a new mnemonic is a security feature.

That being said, if we could simply "switch a flip" to enable private key imports, we would probably do that and hide it behind an advanced flag. But the architecture we have revolves around mnemonics, so it would require a lot of changes to make it work (eg. currently, every mnemonic is compatible with all currencies, if we allowed private key imports, it would be specific for one currency, changing the whole flow of our applications).

[d10r]

@AndreasGassmann thx, I wasn't aware of BIP-85, that indeed seems to be a viable solution. Also, I now better understand the reasons for not supporting pk import, thx for taking the time to explain!