Edita 2015-12-23Wed. : Ya no estoy contento con esta respuesta. Si bien sigo pensando que 8k DHParams son un esfuerzo equivocado y una exageración (y es mejor que estén con EC DH), la explicación que di fue falsa. Se convirtió en el modo "Community Wiki" por ahora. Puede volver a trabajar en el futuro. Publicación anterior a continuación.
1) ¿es una exageración y es 4096 suficiente por ahora?
En general, sí. No creo que haya mucho uso para hacer que la clave sea más larga que la clave en su certificado. Y 8k certs son muy infrecuentes en este momento. 2k o 4k son la norma.
Una suite de cifrado usa varios mecanismos criptográficos conectados. (Claves públicas para el intercambio efímero. Claves públicas para los certificados. Funciones hash / funciones MAC para el certificado. Funciones hash / funciones MAC para el cifrado de la sesión. Criptografía simétrica para el cifrado de la sesión, etc.) Funcionan como enlaces en un cadena. Y como una cadena: lo que cuenta es el eslabón más débil. Cualquier esfuerzo dedicado a endurecer el eslabón no débil es un esfuerzo perdido.
(Ahora, las varias partes criptográficas que forman un conjunto de cifrado no son comparables de inmediato, pero existe un consenso aproximado. KeyLength.com ofrece una calculadora para eso).
(Creo que incluso hay una palabra para el enfoque "hacer que cada enlace sea igual de difícil" . Pero no lo recuerdo en este momento).
2) ¿Puedo hacer openssl dhparam corrido en múltiples núcleos?
No tengo idea. No lo pienses Pero tampoco creo que necesites hacerlo. Así que la bala 1.