On 06 May (19:28:38), teor wrote: > > > > Date: Tue, 5 May 2015 18:49:39 -0500 > > From: Tom Ritter <tom@xxxxxxxxx> > > > > On 5 May 2015 at 07:53, Fabian Keil <freebsd-listen@xxxxxxxxxxxxx> wrote: > >> Great. > >> > >> A couple of comments (about v1.3): > > > > Thanks! I made the changes and put up a 1.4 > > > >> Page 141 and 142 seem to suggest that parsing strings is more > >> likely to be vulnerable than parsing binary data. Is that intended? > > > > No but mostly yes. It's more a surprise factor: when I tell people tor > > uses HTTP to upload and download things, they're not surprised - when > > I tell them it has its own HTTP server implementation that does all > > the parsing of the requests, they're much more surprised. I'm not > > saying tor's code is insecure (I put up a $bounty inside my company > > with my own money to anyone who finds a bug in it actually) - but > > implementing your own HTTP server is not a recommended action. :) > > > >> Is the source of the PDF available under a free license? > >> > >> I'm currently preparing a (German) presentation about location > >> hidden block storage and could reuse the HS-related parts: > >> http://chaos.cologne/Fahrplan/events/6653.html > > > > It's (now) http://creativecommons.org/licenses/by-sa/4.0/ > > > > As far as the sources.... well, I made it in keynote. Yes, I know I'm > > a bad person. I can export it as powerpoint, html, images, or pdf and > > send you any one of those five. (Or all of them.) > > Hi Tom, > > Some further feedback: > > Page 20: > Can you explain why you say that consensuses are valid for 24 hours, and not 3 hours? Indeed, according to dir-spec.txt, see section "1.4 Voting timeline", there is an explanation. The current tor code actually randomize some of those values to be in a specific range that is not more than 3 hours (iirc). > > Page 113: > I think there are 3 relays between the client and introduction point, not 2. > In new_route_len(), each circuit with an endpoint chosen by another relay gets an extra hop, and the hidden service chooses the introduction point, not the client. > > I could be wrong about this - the path code has a few special cases that I haven't quite got my head around. Yes you are right. Not only that but if the first introduction point fails (client side), the circuit is re-extended to the second intro point and so on until it works or the the maximum limit of 7 hops is reached. That's maybe a bit too deep to explain in the slides so I guess 4 hops Client <-> Intro is good enough. :) Tom, those slides are great! Impressive job! Thanks for this. David > > teor > > teor2345 at gmail dot com > pgp 0xABFED1AC > https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 > > teor at blah dot im > OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 > > -- > tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Attachment:
signature.asc
Description: Digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk