Could you elaborate on the clear disadvantages of Shamir's Secret Sharing? The only downside I see is the complexity of the implementation, which leaves room for error and can decrease security if not implemented right. For this reason, we will also add other schemes like SeedXOR and Hamming Backups, which are much simpler and leave less room for error.

In my personal opinion, the reason that SLIP39 did not get a lot of traction was because it is not compatible with BIP39. What I mean by this is that it's not possible to take a BIP39 mnemonic, then split it up into SLIP39 shares and get back your BIP39 mnemonic (=> no "roundtrips" are possible). SSKR is compatible with BIP39 mnemonics. From a wallet developer perspective, adding SLIP39 is more work because it often isn't compatible with the existing architecture of the app. But SSKR can basically just be added as a small add-on, then once the BIP39 mnemonic is recovered, the app can be used as usual. But I guess only time will tell what happens around adoption of those standards.


Multisig has advantages over Shamirs', the most important is that there is no one "single point of failure", because the keys can be distributed while signing. The one important downside in this context is that multisig isn't chain agnostic. Bitcoin supports multisig "natively", but for most other chains, smart contracts have to be used for multisig. So it's not possible to have a generic multisig implementation, but it is possible with Shamirs' because it works on a mnemonic level.

AirGap Vault does support multisig because it supports signing PSBTs. To do this, you'll have to use it with a watch-only wallet like Sparrow, Specter or BlueWallet. Please note that we didn't officially announce the support for multisig just yet, because we would like to add some additional functionality to make it more secure (eg. being able to register co-signers in the Vault to verify change addresses, which currently can't be done). This is on our roadmap and will hopefully come sometime in Q1.

Lack of clear standards was indeed a problem. But the new SSKR standard is here to solve that. While it's currently not widely used, there are multiple implementations available in case one project shuts down. And adoption will probably improve over time (it's a very new standard).

The use cases for passphrases and Shamir's are very different. But even if you could somehow "replicate" some kind of social recovery feature by using passphrases, that wouldn't be a standard either, and you then have to make sure you remember how to recover it.

And you have to differentiate between not being able to recover your seed in case a project ceases to exist, and having to put some effort into recovering your seed. Our code is open source, so you will always be able to recover it, it's just not as easy as downloading a different app.

But as I said, we do want to build on standards, and now that there is one (SSKR), we'll add support for it in the near future.

I'm not sure what exactly you mean. I'm not very familiar with how emulators or VMs work, but if the device doesn't have a secure element chip, then it also applies, no matter what kind of emulator you use.


Once I have time I can look into it again, but it has been a few years, so I don't remember how much it space it uses.

But just to make it clear, as I mentioned earlier, I don't see many advantages of running AirGap Vault in a VM. The distro we made isn't supposed to be run as a VM, but rather on a dedicated computer that doesn't have an operating system installed. Our AirGap distro will be the operating system on that system. Once you boot, it boots directly into AirGap Vault and has no other functionality and does not use any persistent storage.

The code of our apps is completely open source and the part of the social recovery is only a few lines of code. I would recommend that you use an old deployed version of the app (eg. an APK from GitHub). You could also run the project yourself, or someone could build a standalone version of the recovery feature.


SSKR is a completely separate standard, so it is not compatible with our implementation. Once we add SSKR, the generation part will be replaced completely, so going forward it will only be possible to create SSKR shares. But our apps will always support recovery of "old" social recovery setups, we'll never remove that.

Hi. I'm Andy, one of the developers on the AirGap project.


There are 2 reasons why we called the feature "Social Recovery" instead of "Shamir's Secret Sharing".

1. The term "Shamir's Secret Sharing" is known in some parts of the community, but because of the lack of a clear standard (at least at the time when we added the feature many years ago), we didn't want users to make false assumptions, eg. regarding compatibility with other implementations (there were a few CLI tools but they were not compatible with our implementation).
2. The term "Social Recovery" is clearer for less technical users.

As already mentioned above, our scheme is not compatible with any other implementation, eg. Trezor or Keystone. The main reason is that our implementation is older than the finalised SLIP-39 standard, which is used by Trezor and Keystone.

The reason we did not change to the SLIP-39 standard after it was finalised is because SLIP-39 does not allow to split up an existing 12 / 24 word mnemonic. So it does not allow you to go from BIP39 mnemonic => Shamir Shares => BIP39 mnemonic. With our implementation, this is possible.

But now that the SSKR standard was defined by blockchain commons, we are planning to adopt it in the near future.


You are right, SSS does not remove the single point of failure regarding mnemonic usage, but it does solve the single point of failure regarding secret backup and storage.


As far as I know, only Coldcard supports Seed XOR at the moment. Hopefully more wallets will follow soon.


As mentioned above, the Social Recovery feature is just a name we use for our implementation of the Shamir's Secret Sharing scheme. I don't know much about Threshold Signatures or Multi-Party computation so I can't talk about them. But from what I've heard they sound very interesting and could solve a few problems.

Hi. Andy here, one of the developers on the AirGap project.


I would recommend using TailsOS because it encrypts the persistent storage by default. Just make sure you use a very strong password.


Ideally, you run AirGap Vault on a device that does not have any networking capabilities (eg. a PC without WIFI card).

A while ago, we created an AirGap Vault Linux Distro https://github.com/airgap-it/airgap-distro, which removes any networking capabilities from the OS. At the time, there was only minimal demand for it, so we discontinued it. But we would be happy to revive the project if there is demand for it again. We'd welcome any PRs that would automate the process of adding the latest AirGap Vault version to the Linux Distribution.


As others have pointed out, this is a tricky problem to solve because you do need some kind of input device to interact with the application, but in theory, and keyboard or mouse could send malicious inputs.

---

There were a few comments here about running AirGap Vault in an Android Emulator or VM.

The security when running AirGap Vault on a mobile device (Android or iOS) comes from the built in secure element hardware chip. It allows for strong encryption that the user can unlock easily using biometrics or the PIN code. If you run AirGap Vault in an emulator, this secure chip will be emulated, so you don't really gain security.

It kind of depends what you want to protect yourself from. If you run AirGap Vault inside a VM, you are basically trying to create a secure and isolated environment in a potentially insecure environment. If your host OS has internet access and is infected with malware, setting up a "secure" VM on that system doesn't really help you, because the malware on the host can just read the keyboard inputs when you enter the mnemonic, or it can read the storage of the VM / emulator. So I don't really see the point in doing that, because it's not an air-gapped setup if the host has internet access.

The only reason I can see for trying to create such an isolated environment is if you don't trust that AirGap Vault won't try to somehow leak the keys over the network. In this case, it makes sense to run it in a sandbox.

But if you want the full advantages of an air-gapped setup, you should run AirGap Vault on a fully air-gapped system, without any networking capabilities.