Discussion:
TLS handshakes take very long
Martin Körper
2014-07-30 09:15:43 UTC
Permalink
Hi,

I'm using bouncycastle 1.51 with latest openjdk 1.7 shipped with
opensuse 13.1.

I was doing some tests with TlsServerProtocol and noticed that since bc
1.51 TLS handshakes take very long (4-5 seconds after the 10th
connection attempt in my case).

I tracked it down to AbstractTlsContext line 34:
this.nonceRandom.addSeedMaterial(secureRandom.generateSeed(32));

Maybe someone has an idea how to fix this?

Thank you.

Regards,
Martin Körper
Eckenfels. Bernd
2014-07-30 10:29:37 UTC
Permalink
Hello,

Using generateSeed is rather unfortunate, this enforces to shortcut the PRNG and will in most cases directly query the native /dev/random provider. I think it is enough to use the normal random numbers - especially when the SecureRandom can be configured.

Anyway, in your case you need to ensure a full entropy pool. In case of SUSE it is normally not a problem when havegd daemon is running, which would be my recommendation.

Bernd
________________________________________
From: Martin Körper [martin.koerper-***@public.gmane.org]
Sent: Wednesday, July 30, 2014 11:15
To: dev-crypto-***@public.gmane.org
Subject: [dev-crypto] TLS handshakes take very long

Hi,

I'm using bouncycastle 1.51 with latest openjdk 1.7 shipped with
opensuse 13.1.

I was doing some tests with TlsServerProtocol and noticed that since bc
1.51 TLS handshakes take very long (4-5 seconds after the 10th
connection attempt in my case).

I tracked it down to AbstractTlsContext line 34:
this.nonceRandom.addSeedMaterial(secureRandom.generateSeed(32));

Maybe someone has an idea how to fix this?

Thank you.

Regards,
Martin Körper









SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/Registered Office: Bernd Seeburger, Axel Haas, Michael Kleeberg
Edisonstr. 1
D-75015 Bretten Vorsitzender des Aufsichtsrats/Chairperson of the Seeburger Supervisory Board:
Tel.: 07252 / 96 - 0 Dr. Franz Scherer
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info-***@public.gmane.org HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.
Peter Dettman
2014-08-25 05:11:46 UTC
Permalink
FYI, AbstractTlsContext has now been changed so that it doesn't call
SecureRandom.generateSeed anymore, but just nextBytes.
Post by Eckenfels. Bernd
Hello,
Using generateSeed is rather unfortunate, this enforces to shortcut the PRNG and will in most cases directly query the native /dev/random provider. I think it is enough to use the normal random numbers - especially when the SecureRandom can be configured.
Anyway, in your case you need to ensure a full entropy pool. In case of SUSE it is normally not a problem when havegd daemon is running, which would be my recommendation.
Bernd
________________________________________
Sent: Wednesday, July 30, 2014 11:15
Subject: [dev-crypto] TLS handshakes take very long
Hi,
I'm using bouncycastle 1.51 with latest openjdk 1.7 shipped with
opensuse 13.1.
I was doing some tests with TlsServerProtocol and noticed that since bc
1.51 TLS handshakes take very long (4-5 seconds after the 10th
connection attempt in my case).
this.nonceRandom.addSeedMaterial(secureRandom.generateSeed(32));
Maybe someone has an idea how to fix this?
Thank you.
Regards,
Martin Körper
Loading...