David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-13 🗒️ Summary of this message: The sender is ...
📅 Original date posted:2023-08-13
🗒️ Summary of this message: The sender is concerned about the security of sharing the secret key in the payment URI and suggests using a different method. Another person raises the issue of potential security risks when posting payment URIs in public.
📝 Original message:
On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi Dan,
>A couple more more thoughts:
>
>> Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key.
>
>You're sending the symmetric secret key out of band; but isn't this obscuring the question of securely sharing the secret key? Did you consider DH-ing this as other protocols do? At the very least I would claim that it's likely that implementers might be sloppy here; at the most I would claim this is just insecure full stop.
Hi Dan,
After reading Adam's comments above and re-reading your draft BIP where it says the secret key is also used as the session identifier and that outputs can be modified, I'm wondering about the security of posting payment URIs anywhere someone can see them.
For example, if Alice posts her BIP21 URI for Bob to pay where Eve can see it, such as in a shared chatroom or via email or any cleartext protocol that gets relayed, can Eve establish her own session to the relay and frontrun Alice on receiving Bob's PSBT, modify the returned PSBT to include her (Eve's) output, and submit it for Bob to sign and broadcast?
The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, posting them where evesdroppers can see them poses a privacy risk but not a risk of loss of funds, so many users don't treat them as especially hazardous material. I don't think it would be practical to change that expectation, and I think a protocol where evesdropping didn't create a risk of funds loss would be much better than one where that risk was created.
(Apologies to Adam is this is exactly what he was saying with more subtly.)
-Dave
🗒️ Summary of this message: The sender is concerned about the security of sharing the secret key in the payment URI and suggests using a different method. Another person raises the issue of potential security risks when posting payment URIs in public.
📝 Original message:
On August 10, 2023 5:37:54 AM HST, AdamISZ via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi Dan,
>A couple more more thoughts:
>
>> Out of band, the receiver of the payment, shares a bitcoin URI with the sender including a <code>pj=</code> query parameter describing the relay subdirectory endpoint and <code>psk=</code> parameter with base64 encoded 256-bit secret key.
>
>You're sending the symmetric secret key out of band; but isn't this obscuring the question of securely sharing the secret key? Did you consider DH-ing this as other protocols do? At the very least I would claim that it's likely that implementers might be sloppy here; at the most I would claim this is just insecure full stop.
Hi Dan,
After reading Adam's comments above and re-reading your draft BIP where it says the secret key is also used as the session identifier and that outputs can be modified, I'm wondering about the security of posting payment URIs anywhere someone can see them.
For example, if Alice posts her BIP21 URI for Bob to pay where Eve can see it, such as in a shared chatroom or via email or any cleartext protocol that gets relayed, can Eve establish her own session to the relay and frontrun Alice on receiving Bob's PSBT, modify the returned PSBT to include her (Eve's) output, and submit it for Bob to sign and broadcast?
The way BItcoin users currently use BIP21 URIs and QR-encoded BIP21 URIs, posting them where evesdroppers can see them poses a privacy risk but not a risk of loss of funds, so many users don't treat them as especially hazardous material. I don't think it would be practical to change that expectation, and I think a protocol where evesdropping didn't create a risk of funds loss would be much better than one where that risk was created.
(Apologies to Adam is this is exactly what he was saying with more subtly.)
-Dave