📅 Original date posted:2015-07-23
📝 Original message:I've looked at IT-PIR for Libbitcoin. It's certainly more elegant than
onion routing for query privacy, but doesn't improve on the collusion
problem. As a result the related directory problem would also remain.
"This protocol sacrifices some level of privacy to gain robustness.
Because of this we need to assume that there is no collusion between
some number of servers. In some settings, it is unclear how this
requirement can be enforced or detected. This uncertainty may make this
protocol less desirable than others with different privacy guarantees."
http://www.cypherpunks.ca/~iang/pubs/hybridpir-pets.pdf
From the same source, regarding aforementioned options:
"An assumption used in many PETs, including mix networks, secret
sharing, onion routing and some voting protocols, is that no more than
some threshold of agents are colluding against the user to discover the
private information."
Another option is computationally-bounded CPIR, but from the same source:
"The main problem with the CPIR protocols already discussed is that
they do not generally perform queries faster than the trivial protocol."
Where the "trivial protocol" in our problem is full blockchain download.
WRT an alternative CPIR proposed in 2007:
"The idea behind their protocol is to add noise to the query in a way
that the server cannot discover which record the client is interested
in, but with the secret information that the client has, she can remove
the noise from the server’s response."
This is the idea behind stealth prefix queries:
https://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-stealth
From our perspective, another important objective of query privacy is
allowing the caller make the trade-off between the relative levels of
privacy and performance - from absolute to non-existent. In some cases
privacy is neither required nor desired.
Prefix filtering accomplishes the client-tuning objective. It also does
not suffer server collusion attacks nor is it dependent on computational
bounds. The primary trade-off becomes result set (download) size against
privacy.
e
On 07/23/2015 05:23 AM, Stefan Richter wrote:
> This looks like a prime application for this PIR
> library: http://percy.sourceforge.net/apidocs/index.html
>
> Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> schrieb am Do., 23. Juli
> 2015 um 02:07 Uhr:
>
> This is a good point. I didn't delve into the specifics of
> implementation due to the larger issues that I raised. Libbitcoin Server
> uses CurveZMQ, an implementation of CurveCP.
>
> http://curvecp.org
> http://curvezmq.org
> https://en.bitcoin.it/wiki/Libbitcoin_Server
>
> e
>
> On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:
> > Why RSA?
> >
> >>
> >> Here is an idea, inspired by TOR, on which I would like to have some
> >> feedback: We create an anonymous routing layer between Electrum
> servers
> >> and clients.
> >>
> >> * Each server S publishes a RSA public key, KS
> >> * Each client receives a list of available servers and their pubkeys
> >> * For each wallet address, addr_i, a client chooses a server S_i,
> and a
> >> RSA keypair (K_addr_i, k_addr_i)
> >> * The client creates a list of encrypted requests. Each request
> contains
> >> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> >> * The client chooses a main server M, and sends the list of encrypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding servers S_i
> >> (without the client's IP address.)
> >> * Each server decrypts the requests it receives, performs the
> request,
> >> and encrypts the result with K_addr_i
> >> * M receives encrypted responses, and forwards them to the client.
> >> * The client decrypts the encrypted response with k_addr_i
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7613c6a2/attachment.sig>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 15:42:46
in reply to nevent1q…ts4r
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:42:46Event JSON
{
"id": "575947c67e415c14bbf83926bd369daa479fbb07f168c1b0bca15b49bb204be3",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686152566,
"kind": 1,
"tags": [
[
"e",
"118b9de54e189b18402c92d943ea538ff30d5f541b4aeaba9bb62ae15123b652",
"",
"root"
],
[
"e",
"5e7d5ecb49a2fe7fc3b6f7608fc3473e8176ac63579c83736615c2576e45f0ef",
"",
"reply"
],
[
"p",
"2a67fa9c85955362b9fd51ebb032020693c0873f0054bc192f847df2d3ac6af9"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:I've looked at IT-PIR for Libbitcoin. It's certainly more elegant than\nonion routing for query privacy, but doesn't improve on the collusion\nproblem. As a result the related directory problem would also remain.\n\n\"This protocol sacrifices some level of privacy to gain robustness.\nBecause of this we need to assume that there is no collusion between\nsome number of servers. In some settings, it is unclear how this\nrequirement can be enforced or detected. This uncertainty may make this\nprotocol less desirable than others with different privacy guarantees.\"\n\nhttp://www.cypherpunks.ca/~iang/pubs/hybridpir-pets.pdf\n\nFrom the same source, regarding aforementioned options:\n\n\"An assumption used in many PETs, including mix networks, secret\nsharing, onion routing and some voting protocols, is that no more than\nsome threshold of agents are colluding against the user to discover the\nprivate information.\"\n\nAnother option is computationally-bounded CPIR, but from the same source:\n\n\"The main problem with the CPIR protocols already discussed is that\nthey do not generally perform queries faster than the trivial protocol.\"\n\nWhere the \"trivial protocol\" in our problem is full blockchain download.\n\nWRT an alternative CPIR proposed in 2007:\n\n\"The idea behind their protocol is to add noise to the query in a way\nthat the server cannot discover which record the client is interested\nin, but with the secret information that the client has, she can remove\nthe noise from the server’s response.\"\n\nThis is the idea behind stealth prefix queries:\n\nhttps://github.com/libbitcoin/libbitcoin-explorer/wiki/bx-fetch-stealth\n\nFrom our perspective, another important objective of query privacy is\nallowing the caller make the trade-off between the relative levels of\nprivacy and performance - from absolute to non-existent. In some cases\nprivacy is neither required nor desired.\n\nPrefix filtering accomplishes the client-tuning objective. It also does\nnot suffer server collusion attacks nor is it dependent on computational\nbounds. The primary trade-off becomes result set (download) size against\nprivacy.\n\ne\n\nOn 07/23/2015 05:23 AM, Stefan Richter wrote:\n\u003e This looks like a prime application for this PIR\n\u003e library: http://percy.sourceforge.net/apidocs/index.html\n\u003e \n\u003e Eric Voskuil via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e schrieb am Do., 23. Juli\n\u003e 2015 um 02:07 Uhr:\n\u003e \n\u003e This is a good point. I didn't delve into the specifics of\n\u003e implementation due to the larger issues that I raised. Libbitcoin Server\n\u003e uses CurveZMQ, an implementation of CurveCP.\n\u003e \n\u003e http://curvecp.org\n\u003e http://curvezmq.org\n\u003e https://en.bitcoin.it/wiki/Libbitcoin_Server\n\u003e \n\u003e e\n\u003e \n\u003e On 07/22/2015 04:11 PM, gb via bitcoin-dev wrote:\n\u003e \u003e Why RSA?\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Here is an idea, inspired by TOR, on which I would like to have some\n\u003e \u003e\u003e feedback: We create an anonymous routing layer between Electrum\n\u003e servers\n\u003e \u003e\u003e and clients.\n\u003e \u003e\u003e\n\u003e \u003e\u003e * Each server S publishes a RSA public key, KS\n\u003e \u003e\u003e * Each client receives a list of available servers and their pubkeys\n\u003e \u003e\u003e * For each wallet address, addr_i, a client chooses a server S_i,\n\u003e and a\n\u003e \u003e\u003e RSA keypair (K_addr_i, k_addr_i)\n\u003e \u003e\u003e * The client creates a list of encrypted requests. Each request\n\u003e contains\n\u003e \u003e\u003e addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i\n\u003e \u003e\u003e * The client chooses a main server M, and sends the list of encrypted\n\u003e \u003e\u003e requests to M\n\u003e \u003e\u003e * M dispatches the client's requests to the corresponding servers S_i\n\u003e \u003e\u003e (without the client's IP address.)\n\u003e \u003e\u003e * Each server decrypts the requests it receives, performs the\n\u003e request,\n\u003e \u003e\u003e and encrypts the result with K_addr_i\n\u003e \u003e\u003e * M receives encrypted responses, and forwards them to the client.\n\u003e \u003e\u003e * The client decrypts the encrypted response with k_addr_i\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/7613c6a2/attachment.sig\u003e",
"sig": "a14d90d1b4510be2a9b890f85ccfdfa1c9a8d568af70884dfbd6308d991b5227297f9468246feed9026f3dc61f585fb62b3a641c8dfd442238003c311b45db64"
}