<div dir="ltr"><div><div><div><div><br></div>Hi,<br><br></div>so you were right the databases were corrupt, but they shouldn't have been there in the first place. :-)<br><br><br></div><div>I didn't want to include large files in the git repo (~120mb in total), so there is a generation script in the tools directory (now added).<br><br>I added some instructions on the readme file too. Of course, this procedure is done only once.<br><br></div><div><br>I tried it and it should work now, but let me know if there is still a problem.<br><br>There is a plan to optimize the way the pre-computed values are used, 
and this could potentially shrink the size of the databases by a lot.<br><br></div></div>Vasilis<br><div class="gmail_extra"><br><div class="gmail_quote">On 17 October 2015 at 15:56, str4d <span dir="ltr"><<a href="mailto:str4d@i2pmail.org" target="_blank">str4d@i2pmail.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
</span>str4d wrote:<br>
<span>> Vasilios Mavroudis wrote:<br>
>> Hello,<br>
><br>
>> I would like to introduce our project "Crux", which enables the<br>
>> computation of privacy preserving statistics on sensitive data.<br>
>> The project was developed at University College London (UCL) by<br>
>> me, in close collaboration with George Danezis.<br>
><br>
</span><span>> This is fantastic work. Haven't read all of your thesis yet, but<br>
> it looks similar to the stats collection system that we ran for a<br>
> while inside I2P, but with the privacy protections that I wanted it<br>
> to have. Well done!<br>
><br>
><br>
</span><span>>> "Crux" was designed with Tor hidden services in mind (in<br>
>> accordance with this<br>
</span>>> <<a href="https://research.torproject.org/techreports/hidden-service-stats-201" rel="noreferrer" target="_blank">https://research.torproject.org/techreports/hidden-service-stats-201</a><br>
5<br>
><br>
>><br>
- -04-28.pdf><br>
<span>><br>
><br>
> Tor<br>
>> Tech Report), but it can be applied on various kinds of data<br>
>> (given an appropriate parser).<br>
><br>
</span><span>> Excellent. I want to use this in I2P :)<br>
><br>
><br>
</span><span>>> It supports three statistics (i.e. mean, median, variance) and<br>
>> its threat model is compatible Tor's (see technical document<br>
>> below).<br>
><br>
</span><span>> I will look into this, but I doubt there will be any<br>
> insurmountable incompatibilities with I2P's threat model.<br>
><br>
</span><span>>> Currently, we don't have a parser specific for the data<br>
>> collected by the Tor relays, but we plan to keep adding<br>
>> functionality.<br>
><br>
>> The source code can be found here:<br>
>> <a href="https://github.com/mavroudisv/Crux" rel="noreferrer" target="_blank">https://github.com/mavroudisv/Crux</a> The theoretical background,<br>
>> threat model, security argument and technical details can be<br>
</span>>> found here: link <<a href="http://mavroudisv.eu/files/thesis.pdf" rel="noreferrer" target="_blank">http://mavroudisv.eu/files/thesis.pdf</a>><br>
<span>><br>
><br>
>> Ideas, comments, feedback much appreciated!<br>
><br>
</span><span>> Firstly: needs more docs. I shouldn't have to read your entire<br>
> thesis in order to figure out how to run it :P The README is a good<br>
> start, but the command parameters need clarification/definitions,<br>
> and it is not at all obvious how the relays work. An XLS file is<br>
> also mentioned without explanation.<br>
<br>
</span>I have now tried running the code, but the "unit test" run by<br>
authority.py fails because bsbdb.btopen() returns an empty dict. I<br>
don't know if this is because the table files are broken or because of<br>
a local issue with my setup (I am using a virtualenv, but I get the<br>
same empty dict when I try to open the tables manually outside the<br>
virtualenv). I am not going to try and fix the latter on my own,<br>
because bsddb is deprecated since Python 2.6, so you shouldn't really<br>
be using it :) (But it must be something else, because I tried using<br>
bsddb3 instead and that also returns an empty dict).<br>
<br>
str4d<br>
<span><br>
><br>
> Secondly, you could probably simplify configuration by managing<br>
> hidden service connections yourself. I believe the Stem library can<br>
</span>> do this? I2P has a python library that can be used to listen on and<br>
<span>> connect to I2P Destinations, with a socket-like interface.<br>
><br>
> It's not clear to me from your thesis whether you plan to merge<br>
> the relay component into the Tor relay code (and have the Tor<br>
> relays talk directly to the query processors), or have your relays<br>
> running separately and interfacing with the Tor relays to fetch<br>
> stats. This will potentially alter how it would be used with other<br>
> networks. In I2P's case I'd imagine it would be easiest (in terms<br>
> of usability by those setting up relays) to write an I2P plugin in<br>
> Java that performs the relay role, but I wouldn't want to be<br>
> duplicating a lot of logic that subsequently needs to be kept<br>
> in-sync with upstream :)<br>
><br>
> str4d<br>
><br>
><br>
>> Vasilis<br>
><br>
><br>
><br>
</span><span>>> _______________________________________________ tor-dev mailing<br>
>> list <a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
>> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
><br>
> _______________________________________________ tor-dev mailing<br>
> list <a href="mailto:tor-dev@lists.torproject.org" target="_blank">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
><br>
</span>-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIcBAEBCgAGBQJWItIgAAoJEBO17ljAn7PglsQP/3tOrL9EZfYMb5fxxVI6/wJm<br>
qDvA8RpbEJDhoMjOc9sLNyMVgvGGPxEdma8I/R8H37yIPOp2GJg82MoXfUk+AGFe<br>
5ZIIXwf2EzHH0RFLRI5xaQ4DW3Ru1yIzH+E3vhuGclL87YRKnAM0xkMQcueR5xo5<br>
/ETe9TI7oPCdETI4J6iFoM+Ob9qsRiEVeuT5HEFFKwQhBvl0NSpfMHV9ftuxQHuu<br>
I2B9jomnBdzF9OXnSQrYXg3ho2rxX4hO1TZfQHg5DgHvkt8TQYQM3cwdGE7/rsqC<br>
d4+kBW2RuAz68wq+fLPeeZ2U2ff2QqmDLqVyUJvpP5RqeUcv66J/iYm7md886tTc<br>
palwVGodKiTJ6DBM0z1K97x6Sl1jJXEAkZQAr2yQ8jrC/BJqQRPu2vHeZILqbMEQ<br>
UU3JLjIk/Jc2RGK6zitvj4kTrLdfACEQMYy3brQUawZhaM42QNQgb3LQq1bJXzUo<br>
vISZckX/CVfF+R63oO085LYOO7oTLyY3EhA1PCXiV09Usl/To66Oh4AVYtz/lPLH<br>
6uoWR/ic5X9gFIXt1t+617+i/L/ILMfqkqN7GzoSbQ8QfyBJrjIikuj575M7AH3o<br>
RuhRYHUTmaCRL+9niDFG/mSVGBxBqiSfW1eS5pGE3hIAcLQd0eFT/38HRdonkfLP<br>
Ug5ihMFSKfKmCIljQ6mm<br>
=jDmS<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div>