[openssl-users] [ANN] M2Crypto 0.25.0
Hi, everybody, after trials and tribulations I have the honor to announce new release of M2Crypto 0.25.0. This is an intermediary version on our way towards port to python 3 (or rather to the bi-versional state of both py2k and py3k compatibility). Particularly we have made these achievements (whole changelog since 0.21.1 follows, because I am not sure whether previous changes were properly announced). Of course any help on python3 porting branch (https://gitlab.com/m2crypto/m2crypto/merge_requests/65) is very welcome! Happy security hacking! Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Do not long for the night, when people vanish in their place. Be careful, do not turn to evil; for you have preferred this to affliction. -- Job 36:20f (NASB) = 0.25.0 - 2016-03-21 --- - More cleanups, removal of obsolete stuff, and moves towards py3k compatibility. - Add support for EC.get_builtin_curves() and use it for testing. - Enable AES CTR mode - Bundle-in six module v. 1.10.0 - add rand_file_name and rand_status - remove all LHASH fiddling - Extend Travis and GitLab CI configuration to test also py3k (with allowed_failures) and CentOS6 (on GitLab CI). - Add CONTRIBUTORS.rst. Thank you! - Add PEP-484 type hints in comments to all Python files (except for tests) - Use context managers for file handling wherever possible instead of leaking open file descriptors. - Improve defaults handling for SSL_CTX_new(). - Fix PGP tests to actually run 0.24.0 - 2016-03-21 --- - More cleanups, removal of obsolete stuff, and moves towards py3k compatibility. - Add DSA.pub_key_from_params() factory function (and m2.dsa_set_pub()). - Allow import/export of EC public key with binary values - Add EVP.load_key_string_pubkey() function, as well as helper functions - Add EVP.get_digestbyname() functionality. - Convert documentation to rST (and add instructions for building on Mac OS X) - Another round of fixing multiarch building. - Disable tests with weak ciphers on some platforms (Debain) 0.23.0 - 2016-01-29 --- - Add Travis and GitLab CI configurations - Allow building without SSLv2 - More cleanups and removing obsolete code - Fix README - Fix buffer overflow in pkcs5_pbkdf2_hmac_sha1 - First moves towards Python 3 compatibility - Removed rather large and completely unmaintained demo/ subdirectory (now in a separate repo https://gitlab.com/m2crypto/m2crypto_demo) - Automatically generated test data files - Finally fix building on multiarch systems - All objects derived from BIO.BIO now could work as context managers - Switch setup.py to setuptools 0.22.5 - 2015-10-13 --- - Add forgoteen SWIG/*.h among distributed files. 0.22.4 - 2015-10-13 --- - Matěj Cepl takes over leadership of the upstream maintenance - Fedora/RHEL distribution patches merged to the main development (mainly, but not only, upgrading to the more recent versions of OpenSSL, swig which is now at 3.0.5, but anything above 2.0.4 is supported as well, and python which now has to be at least 2.6). - Tons of cleaning up the code for obsolete constructs, PEP8ization, etc. 0.22.3 - 2014-01-22 --- (released by Martin Paljak, later development started on top of 0.21.1 with his improvements cherry picked to the new development branch) 0.21.1 - 2011-01-15 --- - Distribution fix signature.asc Description: OpenPGP digital signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl software failure for RSA 16K modulus
> We have cryptographic accelerators on cavium platforms which minimize CPU > usage. So our customers are looking for 16K support. Well, sorry, but by default most other sides won't be able to use them. Not sure anything else to say. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl software failure for RSA 16K modulus
Bonjour, Le 22 juil. 2016 à 08:44, Gupta, Saurabh mailto:saurabh.gu...@cavium.com>> a écrit : 1: I didn't get it, Why this behaviour is not coming for other ciphers while doing the server/client handshake? It should fail for other ciphers also. Ciphers: working DHE-RSA-AES128-SHA ECDHE-RSA-AES256-GCM-SHA384 .. etc Because the key exchange is performed using DHE or ECDHE here, and parameters are much smaller than your server authentication key. If you configure a 16k DH group and choose to use DHE as the key exchange algorithm, you’ll surely fall under the same error. Ciphers: Not working AES128-SHA AES256-SHA .. etc RSA key exchange. 2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack? 3: ECC cipher is not my main concerned. You should be concerned about the security provided by your choices, and not pure raw numbers. 4: I didn't face any issue like memory utilisation or CPU utilisation is more if I'm running more than one client in the case of 16k modulus. Your measuring tools are bad, change them ;) Signing with a 16k RSA key is way slower than with a 2048bits key, and again way slower than using ECC. According to NIST, equivalent « security levels »: RSA15360, DH15360, ECC512 (or 521) RSA7680, DH7680, ECC384 RSA3072, DH3072, ECC256 Measurements done on my machine: Signing with ECDSA over the P521 curve is 600x faster than signing with a 15kRSA key. Performing a key exchange with ECDH over the P521 curve is about 180x faster than decrypting with a 15k RSA key. Using the P384 curve and a 7kRSA key, the numbers are 180x faster and 50x faster. Using the P256 curve and a 4kRSA key, numbers are about 90x faster for both operations. I don’t have any measurements for DH key exchange, but it should cost twice more than doing a private RSA operation, and also impacts the client, and when used within TLS it comes in addition to an RSA signing operation. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl software failure for RSA 16K modulus
> The DoS issue is still there. How can you prevent the "other side" from > consuming all your CPU with a large key? > Who needs 16K RSA keys, such that openssl by default should support that for > everyone? We have cryptographic accelerators on cavium platforms which minimize CPU usage. So our customers are looking for 16K support. Regards, Saurabh -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl software failure for RSA 16K modulus
> 2: if anyway I want to use 16k modulus, Do we have solution to avoid this > issue so that it won't harm to other application or create any new attack? No. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
