Si bien actualmente no se conoce ningún ataque en caso de que se use un relleno correcto, los exponentes pequeños tienen más probabilidades de generar exploits en caso de errores de implementación. Y los errores de implementación lamentablemente siguen siendo una amenaza. P.ej. this es una vulnerabilidad que fue bastante "popular". (Nota, esto es para firmas. Solo quiero mostrar que incluso el software comercial puede tener errores graves.)
Si tiene que tomar atajos, debe tener en cuenta las implicaciones potenciales de sus acciones. Es decir. elegir un pequeño módulo o un pequeño exponente ambos tienen sus propios inconvenientes.
Si elige un módulo pequeño (1024 bit), no puede asumir que sus datos pueden mantenerse confidenciales durante décadas.
Si elige un exponente pequeño, es posible que sea más susceptible a errores de implementación.
En el primer caso, sabes muy bien cuando tus secretos están en peligro, ya que es bastante fácil seguir el progreso en el factoring. (Esto supone por supuesto que las agencias que no publican, por ejemplo, NSA, no son su enemigo). En el segundo caso (errores de implementación), no sabe cuándo cometió un error. Puede estar seguro usando e = 3 o podría haber cometido un gran error. Es decir. en un caso, tiene una forma bastante buena de estimar su riesgo y, en el otro caso, no.
Por lo tanto, yo recomendaría no utilizar e = 3 en absoluto. Utilizaría más margen de seguridad frente a las amenazas que son difíciles de predecir, que aquellas amenazas que se publicitan ampliamente.
Si toma una tarjeta de crédito y aumenta la potencia, no podrá completar 2048 bit. 17 no debe usarse tampoco. –
Tienes razón. Es solo que estoy usando openssl para generar la clave y desde 0.9.8 no soporta el uso de ningún otro exponentes. – safsaf32
Tenga en cuenta también que "un dispositivo de hardware teórico denominado TWIRL y descrito por Shamir y Tromer en 2003 cuestionó la seguridad de las claves de 1024 bits. Actualmente se recomienda que n tenga al menos 2048 bits de longitud". http://en.wikipedia.org/wiki/RSA#Security_and_practical_considerations –