Add Encryption Manager

[nopara73]

Functionality should be the same as in Electum.

It should be accessible from Tools/Encryption Manager.
It should have the same layout as Tools/Wallet Manager.
Right Menu Tabs: Sign Message, Verify Message, Encrypt Message, Decrypt Message

The Sign Message's layout should look somehow like this:

The Verify Message is the opposite. The Encrypt/Decrypt Message tabs should be the same, too.

[molnard]

related: zkSNACKs/zIPs#40

[nopara73]

@lontivero Can you implement encrypt-decrypt message to NBitcoin?

@NicolasDorier had this to say about it:

[lontivero]

Sure. Nico is right, it has to calculate a shared key with DH and use a symmetric encryption algorithm (it uses to be AES).
Q: has this a highier priority than #1117?

[nopara73]

@lontivero Priority is up to you. @molnard encountered issues with Avalonia with multiline textbox, so the feature will stall for a while.

[lontivero]

PR tho NBitcoin is done (but it is still a WIP because I have to test compatibility with electrum) MetacoSA/NBitcoin@master...lontivero:Encrypt-Message

[MaxHillebrand]

@bitcoinops newsletter #54 has an interesting section about Message Signing Support for Bech32.
It is referring to BIP 322, a standard that does support both native Segwit, and also future Schnorr taproot keys. See also the mailing list announcement of BIP 322.
I believe Wasabi is in a good position to, again, pioneer the implementation of Bech32!

[tphyahoo]

It should be better than electrum. Nudge things in a direction of replacing pgp. Produce ascii armored texts that sign and/or encrypt messages, suitable for emailing or forum postings. Allow metadata such as name/email to addresses, and maybe the gap can close quick.

[MaxHillebrand]

I don't think we should spearhead a complete new standard with a bunch of stuff...

Rather, we should stick to BIP322 and work on interoperability. Now, I do not know how exactly BIP322 is structured, maybe it addresses your problems @tphyahoo, if it does - great, cause I want that too. But I don't think we should bend over backwards to make it happen...

[nopara73]

Sorry guys, but I'm closing this. As @luke-jr pointed out (#1127 (comment)) there are way too many issues with end user using encryption like this. We didn't want to give up the work just yet, because we invested too much time into this, but "what's true is already so, owning up to it doesn't make it worse."
Not sure about the specifics, but maybe the main UX issue is that a Bitcoin address doesn't know about the pubkey.

Not even talking about that, this feature is outside of the scope of Wasabi and nobody would be using it.

[molnard]

I'll be back.

[MaxHillebrand]

Government regulation of several jurisdictions require users of custodial wallets to proof ownership of the withdrawal address. In for example the Netherlands and Switzerland, this can either be done by providing a screenshot of the address in the wallet [which can leak other sensitive information like total wallet balance], OR by providing a cryptographic signature over a challenge message with the key of the address. In order to make the live of citizens more miserable, I foresee that eventually providing a screenshot is no longer sufficient.

Some of our users are now forced to provide this information to custodians, but Wasabi still cannot sign messages, making Wasabi an unusable wallet for these harassed users.

For me this is sufficient to justify spending developer time to implement this encryption manager.

[lontivero]

Should we go in that direction? I think we should go in the exact opposite direction, after all helping to comply with ridiculous government idiots requirements is not something we should feel proud of.

From the technical point of view, how do exchanges expect the the cryptographic proof to work? What is the protocol? (There is not such a thing as "just sign the fu*** message with the public key"). Are they going to encrypt with the address' pubkey and then ask the client to decrypt the challenge? What if the address correspond to a P2SH/P2WSH? What if it is a P2WPKH? We know nothing about it.

This had my ACK time ago but i think we did well in not merging it. Now that the govts want to use this against users I change my ACK to NACK.

[NicolasDorier]

Just dropping my bit here: Such regulation has been attempted in the past, I think in Isle of man.
This brought so much friction and support from exchange that they pressured against regulators to repel this.
And in the end it got repelled.

The point is: If you make effort to make the life of exchanges and regulators easier, then they have no incentive to push back on idiotic requirements. If you keep friction, they have no choice but to adapt or suffer big loss.

[MaxHillebrand]

leaving this for future reference, @apoelstra has a nice update/rewrite/clarification of BIP322

https://github.com/apoelstra/bips/blob/2020-12--bip322-overhaul/bip-0322.mediawiki