" Try to avoid using keys larger then 1024 bytes. Large keys significantly slow down the TLS connection handshake, thus limiting the maximum SIP-router TLS connection rate. "
Is this still a valid recommendation? Based on which size of CPU/system?
/O
On Samstag, 10. Oktober 2009, Olle E. Johansson wrote:
" Try to avoid using keys larger then 1024 bytes. Large keys significantly slow down the TLS connection handshake, thus limiting the maximum SIP-router TLS connection rate. "
Is this still a valid recommendation? Based on which size of CPU/system?
Hi Olle,
i'd think that today we should suggest a larger key. I've found this page: http://www.keylength.com/en/compare/
according to it newer sources suggest a value of at least 1536 bits for asymmetric keys.
Regards,
Henning
On Oct 13, 2009 at 12:57, Henning Westerholt henning.westerholt@1und1.de wrote:
On Samstag, 10. Oktober 2009, Olle E. Johansson wrote:
" Try to avoid using keys larger then 1024 bytes. Large keys significantly slow down the TLS connection handshake, thus limiting the maximum SIP-router TLS connection rate. "
Is this still a valid recommendation? Based on which size of CPU/system?
Hi Olle,
i'd think that today we should suggest a larger key. I've found this page: http://www.keylength.com/en/compare/
according to it newer sources suggest a value of at least 1536 bits for asymmetric keys.
IMHO 1024 keys are more then enough for normal SIP trafic.
The recommandation of using smaller keys is still valid. Even on modern system encryption will eat a lot of CPU, and if you need to support several hundreds encrypted connections in the same time you'll quickly run into problems.
Andrei
On Dienstag, 13. Oktober 2009, Andrei Pelinescu-Onciul wrote:
Try to avoid using keys larger then 1024 bytes. Large keyssignificantly slow down the TLS connection handshake, thus limiting the maximum SIP-router TLS connection rate. "
Is this still a valid recommendation? Based on which size of CPU/system?
Hi Olle,
i'd think that today we should suggest a larger key. I've found this page: http://www.keylength.com/en/compare/
according to it newer sources suggest a value of at least 1536 bits for asymmetric keys.
IMHO 1024 keys are more then enough for normal SIP trafic.
The recommandation of using smaller keys is still valid. Even on modern system encryption will eat a lot of CPU, and if you need to support several hundreds encrypted connections in the same time you'll quickly run into problems.
Hi Andrei,
ok, if you look at a really busy system then probably this will need to much performance. And keeping the recommendations aside, its probably easier to work around the crypto (i.e. bribe some admin, hack into the PC) in most cases then to try to break it.
Regards,
Henning
13 okt 2009 kl. 13.23 skrev Andrei Pelinescu-Onciul:
On Oct 13, 2009 at 12:57, Henning Westerholt <henning.westerholt@1und1.de
wrote: On Samstag, 10. Oktober 2009, Olle E. Johansson wrote:
" Try to avoid using keys larger then 1024 bytes. Large keys significantly slow down the TLS connection handshake, thus limiting the maximum SIP-router TLS connection rate. "
Is this still a valid recommendation? Based on which size of CPU/ system?
Hi Olle,
i'd think that today we should suggest a larger key. I've found this page: http://www.keylength.com/en/compare/
according to it newer sources suggest a value of at least 1536 bits for asymmetric keys.
IMHO 1024 keys are more then enough for normal SIP trafic.
The recommandation of using smaller keys is still valid. Even on modern system encryption will eat a lot of CPU, and if you need to support several hundreds encrypted connections in the same time you'll quickly run into problems.
Well, one has to consider when these keys are used. It's not for encryption of SIP traffic at all. The keys are used to authenticate and to do key exchange. The actual encryption is done with much weaker keys.
I personally think this is an old recommendation, but have nothing against keeping it at this point. I'll just reserve the right to come back after X*Y months about it when we have more CPU in the default server ;-)
/O :-)
-
Andrei Pelinescu-Onciul -
Henning Westerholt -
Olle E. Johansson