Adding encrypted/decrypted pin (used in LNURLPoS/LNURLVend) workflow to protocol?

[arcbtc]

LNURLPoS and LNURLVend encrypt a pin on each payment, which is passed to server through an LNURL-pay, then decrypted and sent back in the receipt upon completion of payment. The crypto was elegantly written by @stepansnigirev and using readily available bitcoin crypto.

On LNURLPoS the encrypted pin is added to LNURL here: https://github.com/arcbtc/LNURLPoS/blob/40cb199c4599d9f6c64b7e372a5c7938b75a83f0/LNURLPoS/LNURLPoS.ino#L232

On LNbits server side, it is decrypted and sent back as a receipt here:
https://github.com/lnbits/lnbits-legend/blob/a2bb34060102d049e07766436359e9526e3d8aab/lnbits/extensions/lnurlpos/lnurl.py#L37

Bleskomat uses practically the same method, but for LNURL-withdraws and their offline ATM.

If we made encrypting a confirmation pin and passing through LNURL, then sending back decrypted pin in the receipt, part of the LNURL protocol, then a service like OpenNode could support it directly and LNURLPoS, LNURLVend, Bleskomat, etc would be compatible native with their platform.

[fiatjaf]

Bleskomat is very different. It's not using encrypted anything, it is using an HMAC to ensure the amount can be safely withdrawn. See #91.

[karliatto]

Yes, Bleskomat works using HMAC signature for the withdrawRequest but the workflow described here can be used to integrate payRequest with the offline device.

I think it would be a great improvement in the way LNURLPoS works right now and for similar workflow projects if there would be something like successMessage sent from the LN Service to the LN WALLET after point 9 described in LUD06 - Wallet to service interaction flow

So when LN Service verifies the invoice has been paid it responds to the LN WALLET with the decrypted pin (or potentially other data), and then the LN WALLET displays it to the user. Making not necessary to have a web page that will show the decrypted pin once the payment is done.

[arcbtc]

The Bleskomat concept is similar, in that it uses a secret to prove the LNURL was generated from a legitimate source. I'm sure these projects can find a common workflow so a generic standard can be added to LNURL.

I'm looking forward to using the improved successaction workflow once it has greater support across wallets

[Kixunil]

One problem I see with the idea of displaying arbitrary data is it's an attack vector for phishing. ("Upgrade the wallet to receive the token") A pretty good solution would be to just enforce that the wallet displays it either as hex or decimal number. Thus any text would be scrambled and unreadable for common user.

There's another problem which I disclosed to @arcbtc privately. Since he said the code is not used in the wild, I'm thinking of publishing it.

[arcbtc]

Please do, although can you wait until we have patched.
If creating a standard Bleskomat and LNURLPoS/LNURLVend can share involves a change to how we encrypt the pin, the benefit will far outweigh any inconvenience

[Kixunil]

OK, I'll wait. Please ping me once it's patched.

[fiatjaf]

I'm not seeing these benefits. What are the benefits? If OpenNode wants to support LNURLPoS why can't it just implement the LNURLPoS backend? Bleskomat is completely unrelated.

[chill117]

I'm not seeing these benefits. What are the benefits? If OpenNode wants to support LNURLPoS why can't it just implement the LNURLPoS backend? Bleskomat is completely unrelated.

There is benefit to creating a standard for a common and useful design pattern - especially one involving cryptographic functions. It's better than having a bunch of slightly different implementations floating around each with their own potential vulnerabilities. One standard that has been well tested and vetted by many eyes - that's desirable.

And the current iteration of Bleskomat uses only an HMAC to secure the signed lnurl-withdraw flow. But we could implement a similar flow as the LnurlPOS or LnurlVend using a signed lnurl-pay with encrypted PIN. This can make all kinds of offline hardware possible using Lightning.

[Kixunil]

Exactly, cryptography can be very subtle and very dangerous to implement without review and experience.