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

[Tor Bug Tracker & Wiki]

#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 nickm):

 Your master branch is screwed up.  All your branches these days seem to
 have this junk at the root:
 {{{
 commit 0c11230a55cfac45bfd81d3ad353638255484b77
 Merge: 90ca87d 53dac6d
 Author: George Kadianakis <desnacked at gmail.com>
 Date:   Sat Nov 19 23:12:05 2011 +0100

     Merge branch 'master' of git://git.torproject.org/tor

 commit 90ca87db46431bf38fb3886f4f398285f72676f0
 Merge: af12a7a 45307ff
 Author: George Kadianakis <desnacked at gmail.com>
 Date:   Sat Nov 19 23:11:56 2011 +0100

     Merge branch 'master' of gitorious.org:mytor/mytor

 commit 45307ff98038b2bed7263194c8d5cf56d87f4de4
 Author: George Kadianakis <desnacked at gmail.com>
 Date:   Mon Oct 17 22:46:44 2011 +0200

     Port managed proxy launching code to the new subprocess API.
 }}}

 This has nothing to do with this feature.  The patch is only half as big
 when I ignore these commits.

 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.

 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.

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

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

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

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4548#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online