[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] GSoC 17 | Name System API for Tor Onion Services



On 03/21/2017 10:54 AM, Pickfire wrote:
> I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I am
> interested particapate in Google Summer of Code 2017 under tor organization. I
> am interested to see Proposal 224 coming along but I would really like to see
> [Proposal 272][0] and hope that tor hidden services can be more user-friendly.
> 
> What do you think of the projects? Is the proposal too immature? I had looked
> into [OnioNS][1] as well and like the idea of having different types of DNS
> records for tor hidden services, how does it integrate with [Proposal 272][0]?
> 
> [0]: https://lists.torproject.org/pipermail/tor-dev/2016-October/011524.html
> [1]: https://lists.torproject.org/pipermail/tor-dev/2015-May/008826.html

Hi Ivan,

I am the author and the main developer behind the Onion Name System
(OnioNS) project, which I see you referenced above. You may be
interested in reading my paper here: [0]. Development is on Github and I
think that I have a very solid codebase, but I haven't commit anything
recently as I've been busy with a full-time job as a pen tester and
various other side projects that have occupied my time.

In my mind, there are a couple of issues that impact naming systems:
1) The SHAttered attack against SHA-1. This certainly affects current
onion services, and I'm personally a hesitant to enhance them with a
naming system, since a SHA-1 collision would undermine the security of
any naming system.
2) Prop224 is in the works and is still being finalized. Since the
addresses are much larger, we certainly want to have a good naming
system by the time it's ready to go, as this also encourages the
transition to the new system. The naming system API ties into this.

I would be very happy if you were to help implement the naming system
API. It's currently possible to redirect the streams by sending commands
to the tor control port, but an API would be much cleaner.

[0]:
https://www.degruyter.com/downloadpdf/j/popets.2017.2017.issue-1/popets-2017-0003/popets-2017-0003.pdf

-- 
Jesse

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev