Marek Marcola wrote:
Many applications generate a static one, can the same exact key be
re-used without any security considerations for unrelated sessions ?
Should a highly secure application generate a new one for every connection?
In this case (export restriction) generating RSA 512 bit key is not
very secure, so probably using this key on one or more sessions
make no big difference :-)
Because this key is used to exchange pre_master_secret from client
to server, breaking or revealing this key leads to ability to
decrypt SSL session. In first case we have no choice as for example
CPU power increases from time to time. In second case we should
not save such key for example in software, just destroy after
program exit. There may be other problems witch may leads to reveal
RSA private key - RSA timing attacks for example.
But this key generation here is caused by export restriction, in normal
circumstances server RSA key (for example 2048 bits long) is used
to exchange pre_master_secret - send to client in certificate form.
(public part of course).
Revealing such key, reveals all "saved" by attacker SSL sessions.
Maybe I have not paid much attention to export restricted modes as my
territory is not restricted, but I would like the enforce best security
practices with most interoperability.
My situation is that I have a long-running application (that does not
exit after every session). How can I best protect it when clients have
export restrictions enabled ?
The application is serving multiple SSL connections at the same time and
many sessions during the applications lifetime (which maybe into weeks).
Would key re-generation and rotation make any sense for me ? If so what
are the best practices when dealing with the tmp_rsa key.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
