Re: [tor-bugs] #4548 [Tor Bridge]: Implement dynamic (rakshasa) primes (part of proposal 179)

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#4548: Implement dynamic (rakshasa) primes (part of proposal 179)
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:                    
     Type:  defect      |         Status:  needs_review      
 Priority:  normal      |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Bridge  |        Version:                    
 Keywords:              |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by asn):

 Let's try this again. Branch `bug4548_take2`.

 Replying to [comment:3 nickm]:
 > Your master branch is screwed up.  All your branches these days seem to
 have this junk at the root:
 > ...
 > This has nothing to do with this feature.  The patch is only half as big
 when I ignore these commits.
 >

 Fixed my master. Should be fine now.

 > This patch series also seems to include the serial number hackery, which
 isn't part of this feature.  (It might not belong at all: to conform with
 the goal of being able to include user-provided certs, we probably can't
 actually include that at all, unless somebody has a brilliant idea.)  It's
 also got some time fuzzing, which doesn't belong.
 >

 Hmm, true. Didn't include these in
 edec9409e85ba4a8b5d0575b23046d83d7562b87 this time.

 > Exposing BIGNUM outside of crypto.c is not so good; the point of
 crypto.c and tortls.c is to isolate OpenSSL structures from the rest of
 Tor as much as possible.
 >

 Sloppy me! Fixed.

 > When loading a new prime, we probably want to double-check that it makes
 a good DH group of not-too-small size.

 Done. If we find a corrupted stored dynamic DH modulus, what should we do?
 Should we unlink() the file and rewrite it with a new one? I'm currently
 simply logging the event. This should '''not''' happen, and if it ever
 happens it would be good to have the corrupted file to see the error.

 > For compatiblity, also, we might want to just save the whole parameter
 set, not just the >prime, in case we want to have it support non-2
 generators as well.
 >

 Didn't do this one. Couldn't find OpenSSL functions that will store/load
 DH parameters to disk.
 `DHparams_print_fp()` and `d2i_DHparams()` don't work together. If for
 some reason we ever decide to move away from `2`, we can discard all
 'dynamic_dh_modulus` files with the old format. It's not like relays have
 a special connection to their dynamic DH modulus.

 > DynamicDHGroups is probably a better name.  There are lots of primes
 used for lots of stuff.
 >

 Done.

 > Generating groups is expensive; do we log "generating DH prime for TLS;
 it might take a while" before we start?
 >

 We did in log_info. We now do in log_notice.

 > How often does this patch regenerate the DH group, if ever?  "Never" is
 I think an acceptable answer, unless we decide that bridges need to regen
 it whenever their IP changes.

 We don't rotate our dynamic DH modulus atm. Do you think we should rotate
 it every time the bridge IP changes?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4548#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs