For this API server I got an idea I would like to hear opinions on.
By the nature of how the API server works it could log all requests and IP addresses. To get better anonymity it is possible to use Tor. Maybe it is possible to improve anonymity particularly for normal users by hiding their actual requests among other random requests.
The server could with every answer include a handful of names that the client could than more or less randomly request.
Problem: all fog request come from the server so if it is really compromised it could serve unused names. Maybe we could simply include a large list with the client...
Just an unfinished idea I am pondering about. I am not sure whether it is worth the effort.
RFC: API Server "Fog of Requests"
Forum rules
Warning !
Avoid using binary softwares from untrusted users.
Prefer compiling it yourself and verify sources.
Warning !
Avoid using binary softwares from untrusted users.
Prefer compiling it yourself and verify sources.
Re: RFC: API Server "Fog of Requests"
This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.phelix wrote:by hiding their actual requests among other random requests.
If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
Re: RFC: API Server "Fog of Requests"
If you allow one specific server to perform this checking, then the hijacked server can give correct data only to that server.cassini wrote:This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.phelix wrote:by hiding their actual requests among other random requests.
If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
If you allow any server to perform this checking, then you may DDoS-ed that way.
If the API server runs in a container or VM, you could checksum its file(s) and periodically recheck (from the host system) to make sure none have been tampered with. This won't help if the attacker's code resides in the app's RAM.
Why not allow "loglevel=0" where 0 means none?
Re: RFC: API Server "Fog of Requests"
True. Depending on the implementation it might be used to see if someone is still online for example.cassini wrote:This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.phelix wrote:by hiding their actual requests among other random requests.
Data integrity will be "proven" by PoW (to some extent).If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.
I don't quite follow. Are you talking about server configuration?somename wrote: Why not allow "loglevel=0" where 0 means none?
Re: RFC: API Server "Fog of Requests"
Yes.phelix wrote: I don't quite follow. Are you talking about server configuration?
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: RFC: API Server "Fog of Requests"
Generally agreed, people should be using Tor if they don't want to be surveilled. Generating a bunch of extra requests is usually easily foiled by statistical attacks. Note that for Tor to work properly, you need stream isolation, otherwise the server can surveil users by pseudonyms. Unfortunately, I don't actually know of any Bitcoin clients that support stream isolation fully. (Bitcoin Core uses stream isolation of different peers, but not different pseudonyms.)cassini wrote:This looks a bit like security by obscurity which is never a good idea. In worst case it can even backfire, e.g. those random requests could yield important clues for statistical analysis attacks.phelix wrote:by hiding their actual requests among other random requests.
FWIW, I'm still unclear on exactly what benefit this API server has over something like Electrum. Electrum is *very* lightweight, and also does PoW checks.
Note that if the API server were compromised, it could selectively lie only to real clients (unless the integrity check client is *very* well disguised as a real client, which is hard to do). For example, if the same IP address queries all names in order, then it's obviously the integrity check.cassini wrote:If you do want to put some effort in security-related issues then I suggest you add a system that permanently checks the integrity of the API server. This could be an external bot that periodically requests all name entries from the API server and compares the data with its own namecoind data. If it encounters inconsistencies it sends out a notification to the dev team.