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

Re: [tor-dev] "old style" hidden services after Prop224



Hello Ivan,

Breaking existing (possibly automated) systems is a _very good reason_ IMHO :). Sure, warn the operators that they're using a legacy system, deprecate the option but don't disable it. https://trac.torproject.org/projects/tor/ticket/18054 sounds like a pretty sane solution btw.

Even if it's no longer officially supported, I think OnionCat in its current incarnation is a great proof of what could be done with the Tor network, other than privacy protection. I actually have this listed on one of my slides for SIM4Things - it's good for the Tor network, shows it can be used for a variety of things while putting very little stress on the network components. Very little traffic, potentially large PR impact (in a good way :) ).

Razvan

On Tue, Sep 13, 2016 at 1:29 AM, Ivan Markin <twim@xxxxxxxxxx> wrote:
Razvan Dragomirescu:
> Thank you Ivan! I still dont see a very good reason to _replace_ the
> current HS system with the one in Prop224 and not run the two in
> parallel.

For me it's because it would make overall system more complex and thus
error-prone and reasonably less secure. Is like using RC4, SHA1, 3DES in
TLS and be vulnerable downgrade attacks and all kind of stuff like
Sweet32 and LogJam (export-grade onions, haha).

> Why not let the client decide what format and security
> features it wants for its services?

It's like dealing with plethora of ciphers and hashes in GnuPG:

https://moxie.org/blog/gpg-and-me/:
> It’s up to the user whether the underlying cipher is SERPENT or IDEA
> or TwoFish. The GnuPG man page is over sixteen thousand words long;
> for comparison, the novel Fahrenheit 451 is only 40k words.

When system is complex in that way someone is going make huge
mistake(s). If crypto is bad, just put it into museum.

So I don't see _any_ reason to manage outdated and less secure system
while we have a better option (if we already deployed it).

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

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