📅 Original date posted:2013-10-26
📝 Original message:On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr <luke at dashjr.org> wrote:
> Is there any point to additional encryption over tor (which afaik is already
> encrypted end-to-end)? Is there a safe way to make this work through tor entry
> nodes/gateways?
The x.509 in the payment protocol itself is for authentication and
non-repudiation, not confidentiality.
It's used to sign the payment request so that later there is
cryptographic evidence in the event of a dispute:
"He didn't send me my alpaca socks!" "Thats not the address I told you to pay!"
"He told me he'd send my 99 red-balloons, not just one!" "No way,
that was the price for 1 red-balloon!"
Just using SSL or .onion (or whatever else) gets you confidentiality
and authentication. Neither of these things get you non-repudiation.
> It'd be nice to have a way to support namecoin-provided keys too...
The payment protocol is extensible, so I hope that someday someone
will support namecoin authenticated messages (but note: this requires
namecoin to support trust-free SPV resolvers, otherwise there is no
way to extract a compact proof that can be stuck into a payment
request) and GPG authenticated messages.
But those things will require a fair amount of code (even fixing the
namecoin protocol in the nmc case), and GPG could be done just by
externally signing the actual payment request like you'd sign any
file... and considering the sorry state of their _practical_
usability, I don't think they're worth doing at this time.
By contrast, I _think_ the tor onion support would require only a
relatively few lines of code since it could just be the existing x.509
mechanism with just a simple special validation rule for .onion, plus
a little tool to repack the keys. I think it would easily be more
widely used than namecoin (though probably both would not really be
used, as gavin notes).
w/ Gavin's comments I'll go check in with the tor folks and see if
anyone has ever though of doing this before and if there is already a
canonical structure for the x.509 certs used in this way.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:08:17
in reply to nevent1q…ua5r
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:08:17Event JSON
{
"id": "261e40ea238ded8bfe2b8161bd50a2de12aef4076aedbc747a7506e82208b030",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150497,
"kind": 1,
"tags": [
[
"e",
"742033471721f40b6d43cf4cd64612772c20a2675cdda10846c302155fc1bb24",
"",
"root"
],
[
"e",
"ddaa1581ca361283c876d847b99e471a147dfb7fceb6935a7f8b8e598900bbfd",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2013-10-26\n📝 Original message:On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e Is there any point to additional encryption over tor (which afaik is already\n\u003e encrypted end-to-end)? Is there a safe way to make this work through tor entry\n\u003e nodes/gateways?\n\nThe x.509 in the payment protocol itself is for authentication and\nnon-repudiation, not confidentiality.\n\nIt's used to sign the payment request so that later there is\ncryptographic evidence in the event of a dispute:\n\"He didn't send me my alpaca socks!\" \"Thats not the address I told you to pay!\"\n\"He told me he'd send my 99 red-balloons, not just one!\" \"No way,\nthat was the price for 1 red-balloon!\"\n\nJust using SSL or .onion (or whatever else) gets you confidentiality\nand authentication. Neither of these things get you non-repudiation.\n\n\u003e It'd be nice to have a way to support namecoin-provided keys too...\n\nThe payment protocol is extensible, so I hope that someday someone\nwill support namecoin authenticated messages (but note: this requires\nnamecoin to support trust-free SPV resolvers, otherwise there is no\nway to extract a compact proof that can be stuck into a payment\nrequest) and GPG authenticated messages.\n\nBut those things will require a fair amount of code (even fixing the\nnamecoin protocol in the nmc case), and GPG could be done just by\nexternally signing the actual payment request like you'd sign any\nfile... and considering the sorry state of their _practical_\nusability, I don't think they're worth doing at this time.\n\nBy contrast, I _think_ the tor onion support would require only a\nrelatively few lines of code since it could just be the existing x.509\nmechanism with just a simple special validation rule for .onion, plus\na little tool to repack the keys. I think it would easily be more\nwidely used than namecoin (though probably both would not really be\nused, as gavin notes).\n\nw/ Gavin's comments I'll go check in with the tor folks and see if\nanyone has ever though of doing this before and if there is already a\ncanonical structure for the x.509 certs used in this way.",
"sig": "2a42c891cbe80b2fc703026f590e4583435b04629c222f742aef40e9bf636916c3b1e896c4a0ffbbc21d75bc7f9794d38047e34a64a4f566acf73d733e614344"
}