When freenet's java uses NSS (from dev-libs/nss), algorithms are almost twice as fast? We should probably give the freenet ebuild an "nss" USE option, and perhaps have it enabled by default -- although it would pull in dev-libs/nss. Or perhaps an "einfo" notification to inform users that things will probably be faster if nss is enabled? (We'll also need to add wrapper.java.additional.5=-Dfreenet.jce.use.NSS=true to /etc/freenet-wrapper.conf to enable it.) __ wrapper.log with nss __ SHA1 (SunPKCS11-NSScrypto version 1.7): 1442711ns SHA1 (SUN version 1.7): 2859580ns SHA1: using SunPKCS11-NSScrypto version 1.7 MD5 (SunPKCS11-NSScrypto version 1.7): 854229ns MD5 (SUN version 1.7): 909822ns MD5: using SunPKCS11-NSScrypto version 1.7 SHA-256 (SunPKCS11-NSScrypto version 1.7): 2954424ns SHA-256 (SUN version 1.7): 4604429ns SHA-256: using SunPKCS11-NSScrypto version 1.7 SHA-384 (SunPKCS11-NSScrypto version 1.7): 5118176ns SHA-384 (SUN version 1.7): 9684614ns SHA-384: using SunPKCS11-NSScrypto version 1.7 SHA-512 (SunPKCS11-NSScrypto version 1.7): 5119436ns SHA-512 (SUN version 1.7): 9683145ns SHA-512: using SunPKCS11-NSScrypto version 1.7 AES/CTR/NOPADDING (SunPKCS11-NSScrypto version 1.7): 4303133ns AES/CTR/NOPADDING (BC version 1.49): 6873217ns Using JCA cipher provider: SunPKCS11-NSScrypto version 1.7 __ without nss __ SHA1: using SUN version 1.7 MD5: using SUN version 1.7 SHA-256: using SUN version 1.7 SHA-384: using SUN version 1.7 SHA-512: using SUN version 1.7 AES/CTR/NOPADDING (SunJCE version 1.7): 7170327ns AES/CTR/NOPADDING (BC version 1.49): 6865750ns Reproducible: Always
At least with 0.7.5_p1462 your suggested changes dont result in freenet using nss for me, so maybe this has changed since you made this suggestion?
to be more verbose: it finds nss, as it says during startup: SunPKCS11-NSS: SunPKCS11-NSS version 1.7 but afterwards, it seems to only use the normal sun and bc providers for the speed test, not the nss version: AES/CTR/NOPADDING (SunJCE version 1.7): 2133076ns AES/CTR/NOPADDING (BC version 1.49): 1963845ns Using JCA cipher provider: BC version 1.49
It still works here for me with build 1462, with the additional wrapper setting. Perhaps it's a bug upstream -- why isn't it speed testing NSS too? On my side, SunJCE isn't being tested, for the AES/CTR/NOPADDING, although it is for HmacSHA256. (And NSS is slightly faster for that.) Hmmm.
Or perhaps the whole point of that setting, was to replace JCE with NSS :p... wrapper.java.additional.5=-Dfreenet.jce.use.NSS=true Are you sure you have that, with the proper number incremented? Maybe it's not "additional.5" for you?
FWIW, after upgrading icedtea-bin (to dev-java/icedtea-bin-3.2.0), without adding that NSS=true line to my freenet-wrapper.conf file (ie. with NSS disabled), icedtea would crash, SIGSEGV, with: Problematic frame: C [libfreebl3.so+0x39e34] (which is a dev-libs/nss file).
Well, icedtea(-bin) should not SIGSEGV independent from the settings for freenet or what input it gets from freenet. So if there is no such open bug, please open a bug for icedtea about the SIGSEGV.
During a new test, freenet was partly using nss, so i added the nss USE flag to 0.7.5_p1984
