From mark.anson at io.net.au Tue Mar 7 01:38:22 2017 From: mark.anson at io.net.au (Mark Anson) Date: Tue, 7 Mar 2017 17:38:22 +1100 Subject: [Cryptography-dev] Elliptic Curve Documentation Message-ID: Coming from Java and BouncyCastle, I'm having trouble learning how to implement EC using Cryptography. Is there a comprehensive tutorial anywhere? The issue I am trying to resolve is how to implement ECDH and encrypt the text of a message. Mark Anson -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at johnpacific.com Tue Mar 7 02:14:09 2017 From: me at johnpacific.com (John Pacific) Date: Tue, 7 Mar 2017 00:14:09 -0700 Subject: [Cryptography-dev] Elliptic Curve Documentation In-Reply-To: References: Message-ID: Well, ECDH is just a way to establish a shared secret. You will have to implement the encryption method yourself. When you say ECDH, I'm going to assume you mean plain ECDH while ECDHE (ephemeral) is what you're really going to want to use due to its security features (forward secrecy, etc). With that said, there is a hazmat primitive for ECDH, but I would strongly recommend that you figure out how you would implement ECDHE with it before you try to build anything. This primitive is: `cryptography.hazmat.primitives.asymmetric.ec.ECDH`. >From that, you'll get a shared secret that you can use. On Mar 6, 2017 23:38, "Mark Anson" wrote: Coming from Java and BouncyCastle, I'm having trouble learning how to implement EC using Cryptography. Is there a comprehensive tutorial anywhere? The issue I am trying to resolve is how to implement ECDH and encrypt the text of a message. Mark Anson _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.anson at io.net.au Tue Mar 7 17:05:30 2017 From: mark.anson at io.net.au (Mark Anson) Date: Wed, 8 Mar 2017 09:05:30 +1100 Subject: [Cryptography-dev] Cryptography-dev Digest, Vol 44, Issue 1 In-Reply-To: References: Message-ID: John thanks for the feedback. I spent a few hours exploring different solutions and worked out a solution that I will be able to use. Many thanks, Mark [MarkAnson:ENCRYPTIC.NET ;Curve:secp521r1] ----BEGIN PUBLIC KEY----- MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQBvDNxSKWXATRo4UGaDf09pwwlrjGg UnZNNO_GLgJfo1_qDBPEMEWMywsQe7OjjgymaR00k4G3MrTi3JwPFi4Y6-AB0n-q MAnZhYCU1RmQzLhRdOE1qfmhcl_gPynWHFOtyHXl7mUWXm1CwnFAztrF95BCSYqc 3R0BZGI8HzIvVpLxIoo. -----END PUBLIC KEY----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Thu Mar 9 23:09:53 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 9 Mar 2017 20:09:53 -0800 Subject: [Cryptography-dev] PyCA cryptography 1.8 (and 1.8.1) released Message-ID: PyCA cryptography 1.8 (and 1.8.1) has been released to PyPI. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy. Changelog: 1.8.1 * Fixed macOS wheels to properly link against 1.1.0 rather than 1.0.2. 1.8 * Added support for Python 3.6. * Windows and macOS wheels now link against OpenSSL 1.1.0. * macOS wheels are no longer universal. This change significantly shrinks the size of the wheels. Users on macOS 32-bit Python (if there are any) should migrate to 64-bit or build their own packages. * Changed ASN.1 dependency from pyasn1 to asn1crypto resulting in a general performance increase when encoding/decoding ASN.1 structures. Also, the ``pyasn1_modules`` test dependency is no longer required. * Added support for update_into on CipherContext. * Added DHPrivateKeyWithSerialization.private_bytes. * Added DHPublicKeyWithSerialization.public_bytes * load_pem_private_key and load_der_private_key now require that ``password`` must be bytes if provided. Previously this was documented but not enforced. * Added support for subgroup order in Diffie-Hellman key exchange. Thanks to all the contributors on this release! -Paul Kehrer (reaperhulk) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidism at gmail.com Wed Mar 15 13:48:40 2017 From: davidism at gmail.com (David Lord) Date: Wed, 15 Mar 2017 10:48:40 -0700 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? Message-ID: Hello cryptography, Over at the Flask repos, we've had a number of requests to use SHA-256 instead of SHA-1 in a couple places. Werkzeug defaults to SHA-1 as part of PBKDF2 to generate password hashes. ItsDangerous defaults to SHA-1 as part of HMAC signatures. After some discussion I concluded that as used in those two methods, SHA-1's collision issues were not relevant. However, I'd like to get a second opinion from the cryptography experts. I can change the default to SHA-256, but if it's not actually making things more secure then that's just increasing time and space for no reason. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Mar 15 13:53:03 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 15 Mar 2017 13:53:03 -0400 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? In-Reply-To: References: Message-ID: Hi David, You're correct that HMAC's security is still fine when used with SHA-1, HMAC-MD5 is even secure believe it or not. That said, I'd generally recommend people migrate to HMAC-SHA-256 anyways, to make analyzing their software easier. Alex On Wed, Mar 15, 2017 at 1:48 PM, David Lord wrote: > Hello cryptography, > > Over at the Flask repos, we've had a number of requests to use SHA-256 > instead of SHA-1 in a couple places. > Werkzeug defaults to SHA-1 as part of PBKDF2 to generate password hashes. > ItsDangerous defaults to SHA-1 as part of HMAC signatures. > > After some discussion I concluded that as used in those two methods, > SHA-1's collision issues were not relevant. > However, I'd like to get a second opinion from the cryptography experts. > > I can change the default to SHA-256, but if it's not actually making > things more secure then that's just increasing time and space for no reason. > > Thanks, > David > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Wed Mar 15 17:14:17 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 15 Mar 2017 17:14:17 -0400 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? In-Reply-To: References: Message-ID: Echoing Alex's comments, SHA1's problems do not affect HMAC constructions so there's no current security issue. That said, optics in cryptography can be important (as you're seeing with your user requests now). You will save yourself a great deal of low grade noise in the future by simply switching now. On March 15, 2017 at 1:53:24 PM, Alex Gaynor (alex.gaynor at gmail.com) wrote: Hi David, You're correct that HMAC's security is still fine when used with SHA-1, HMAC-MD5 is even secure believe it or not. That said, I'd generally recommend people migrate to HMAC-SHA-256 anyways, to make analyzing their software easier. Alex On Wed, Mar 15, 2017 at 1:48 PM, David Lord wrote: > Hello cryptography, > > Over at the Flask repos, we've had a number of requests to use SHA-256 > instead of SHA-1 in a couple places. > Werkzeug defaults to SHA-1 as part of PBKDF2 to generate password hashes. > ItsDangerous defaults to SHA-1 as part of HMAC signatures. > > After some discussion I concluded that as used in those two methods, > SHA-1's collision issues were not relevant. > However, I'd like to get a second opinion from the cryptography experts. > > I can change the default to SHA-256, but if it's not actually making > things more secure then that's just increasing time and space for no reason. > > Thanks, > David > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Mar 15 17:16:54 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 15 Mar 2017 17:16:54 -0400 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? In-Reply-To: References: Message-ID: It's also worth noting that the correct time to switch is not when something is broken, it's well before then. Alex On Wed, Mar 15, 2017 at 5:14 PM, Paul Kehrer wrote: > Echoing Alex's comments, SHA1's problems do not affect HMAC constructions > so there's no current security issue. That said, optics in cryptography can > be important (as you're seeing with your user requests now). You will save > yourself a great deal of low grade noise in the future by simply switching > now. > > On March 15, 2017 at 1:53:24 PM, Alex Gaynor (alex.gaynor at gmail.com) > wrote: > > Hi David, > > You're correct that HMAC's security is still fine when used with SHA-1, > HMAC-MD5 is even secure believe it or not. > > That said, I'd generally recommend people migrate to HMAC-SHA-256 > anyways, to make analyzing their software easier. > > Alex > > On Wed, Mar 15, 2017 at 1:48 PM, David Lord wrote: > >> Hello cryptography, >> >> Over at the Flask repos, we've had a number of requests to use SHA-256 >> instead of SHA-1 in a couple places. >> Werkzeug defaults to SHA-1 as part of PBKDF2 to generate password hashes. >> ItsDangerous defaults to SHA-1 as part of HMAC signatures. >> >> After some discussion I concluded that as used in those two methods, >> SHA-1's collision issues were not relevant. >> However, I'd like to get a second opinion from the cryptography experts. >> >> I can change the default to SHA-256, but if it's not actually making >> things more secure then that's just increasing time and space for no reason. >> >> Thanks, >> David >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: D1B3 ADC0 E023 8CA6 > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at johnpacific.com Wed Mar 15 17:37:37 2017 From: me at johnpacific.com (John Pacific) Date: Wed, 15 Mar 2017 15:37:37 -0600 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? In-Reply-To: References: Message-ID: With that said, if performance is an issue, you might want to look into using SHA512 instead due to optimizations on 64bit platforms. On Mar 15, 2017 15:16, "Alex Gaynor" wrote: > It's also worth noting that the correct time to switch is not when > something is broken, it's well before then. > > Alex > > On Wed, Mar 15, 2017 at 5:14 PM, Paul Kehrer > wrote: > >> Echoing Alex's comments, SHA1's problems do not affect HMAC constructions >> so there's no current security issue. That said, optics in cryptography can >> be important (as you're seeing with your user requests now). You will save >> yourself a great deal of low grade noise in the future by simply switching >> now. >> >> On March 15, 2017 at 1:53:24 PM, Alex Gaynor (alex.gaynor at gmail.com) >> wrote: >> >> Hi David, >> >> You're correct that HMAC's security is still fine when used with SHA-1, >> HMAC-MD5 is even secure believe it or not. >> >> That said, I'd generally recommend people migrate to HMAC-SHA-256 >> anyways, to make analyzing their software easier. >> >> Alex >> >> On Wed, Mar 15, 2017 at 1:48 PM, David Lord wrote: >> >>> Hello cryptography, >>> >>> Over at the Flask repos, we've had a number of requests to use SHA-256 >>> instead of SHA-1 in a couple places. >>> Werkzeug defaults to SHA-1 as part of PBKDF2 to generate password hashes. >>> ItsDangerous defaults to SHA-1 as part of HMAC signatures. >>> >>> After some discussion I concluded that as used in those two methods, >>> SHA-1's collision issues were not relevant. >>> However, I'd like to get a second opinion from the cryptography experts. >>> >>> I can change the default to SHA-256, but if it's not actually making >>> things more secure then that's just increasing time and space for no reason. >>> >>> Thanks, >>> David >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> https://mail.python.org/mailman/listinfo/cryptography-dev >>> >>> >> >> >> -- >> "I disapprove of what you say, but I will defend to the death your right >> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) >> "The people's good is the highest law." -- Cicero >> GPG Key fingerprint: D1B3 ADC0 E023 8CA6 >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev >> >> > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: D1B3 ADC0 E023 8CA6 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From affensoldat at gmail.com Thu Mar 16 04:39:46 2017 From: affensoldat at gmail.com (davide alessio) Date: Thu, 16 Mar 2017 09:39:46 +0100 Subject: [Cryptography-dev] Is SHA-1 secure when used in HMAC and PBKDF2? In-Reply-To: References: Message-ID: On 15 March 2017 at 22:37, John Pacific wrote: > With that said, if performance is an issue, you might want to look into > using SHA512 instead due to optimizations on 64bit platforms. > Or Blake2 (https://blake2.net/) See the benchmark on the home page -------------- next part -------------- An HTML attachment was scrubbed... URL: From afrench at illumina.com Tue Mar 21 12:30:24 2017 From: afrench at illumina.com (French, Adam) Date: Tue, 21 Mar 2017 16:30:24 +0000 Subject: [Cryptography-dev] Elliptic curve ECIES implementation Message-ID: <412275EB-3987-4CCD-9E24-C587EFA6319E@illumina.com> Hi everyone, I?m currently working on a project where I need to use the cryptography library to encrypt/decrypt a message using an elliptic curve key pair. The ?Asymmetric algorithms? -> ?RSA? section of the official documentation includes sections on RSA encryption/decryption using the OAEP scheme. In contrast, the ?Asymmetric algorithms? -> ?Elliptic curve cryptography? section has no similar operations such as ECIES encryption and decryption. I?ve written an implementation of the ECIES scheme for elliptic curve key pairs which builds on the other primitives available through the cryptography library. My boss is happy for me to spend some time creating a pull request to share the implementation with the community. Do people feel there would be sufficient interest for this to be worthwhile? Is there a roadmap for elliptic curve functionality that I should be aware of? It would be great to know how the project intends to extend the elliptic curve interfaces in the future. Thank you very much for your help. Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Tue Mar 21 14:14:55 2017 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 21 Mar 2017 14:14:55 -0400 Subject: [Cryptography-dev] Elliptic curve ECIES implementation In-Reply-To: <412275EB-3987-4CCD-9E24-C587EFA6319E@illumina.com> References: <412275EB-3987-4CCD-9E24-C587EFA6319E@illumina.com> Message-ID: Hi Adam, Thanks for the offer! Our general criteria for inclusion of new hazmat modules is roughly: * It should be something people have a need for. This can be satisfied by showing specs/protocols/etc that are in use that utilize the scheme (either currently existing or upcoming and clearly relevant) * It should (subject to the caveat that we do need to support the use cases people have in real life) not be a giant footgun. Examples of things we'd love to *not* support in cryptography but are forced to due to popularity: RC4, PKCS1v1.5 padding, random obscure elliptic curves nobody uses. * There should be test vectors available to confirm correctness. Preferably from a source like NIST if possible, but worst case generated (and verified) via multiple alternate implementations (we have examples of this in our docs). * If it isn't directly implemented in OpenSSL then we need to have some degree of confidence it can be done safely (e.g. without introducing exploitable side channels) via composition. So what currently uses ECIES? -Paul On March 21, 2017 at 12:55:18 PM, French, Adam (afrench at illumina.com) wrote: Hi everyone, I?m currently working on a project where I need to use the cryptography library to encrypt/decrypt a message using an elliptic curve key pair. The ?Asymmetric algorithms? -> ?RSA? section of the official documentation includes sections on RSA encryption/decryption using the OAEP scheme. In contrast, the ?Asymmetric algorithms? -> ?Elliptic curve cryptography? section has no similar operations such as ECIES encryption and decryption. I?ve written an implementation of the ECIES scheme for elliptic curve key pairs which builds on the other primitives available through the cryptography library. My boss is happy for me to spend some time creating a pull request to share the implementation with the community. Do people feel there would be sufficient interest for this to be worthwhile? Is there a roadmap for elliptic curve functionality that I should be aware of? It would be great to know how the project intends to extend the elliptic curve interfaces in the future. Thank you very much for your help. Cheers, Adam _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Tue Mar 21 14:16:44 2017 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 21 Mar 2017 14:16:44 -0400 Subject: [Cryptography-dev] Elliptic curve ECIES implementation In-Reply-To: References: <412275EB-3987-4CCD-9E24-C587EFA6319E@illumina.com> Message-ID: I'd also add that any primitives we expose need to be standardized and interoperable. Does ECIES have a standard syntax/serialization/etc.? Alex On Tue, Mar 21, 2017 at 2:14 PM, Paul Kehrer wrote: > Hi Adam, > > Thanks for the offer! Our general criteria for inclusion of new hazmat > modules is roughly: > > * It should be something people have a need for. This can be satisfied by > showing specs/protocols/etc that are in use that utilize the scheme (either > currently existing or upcoming and clearly relevant) > * It should (subject to the caveat that we do need to support the use > cases people have in real life) not be a giant footgun. Examples of things > we'd love to *not* support in cryptography but are forced to due to > popularity: RC4, PKCS1v1.5 padding, random obscure elliptic curves nobody > uses. > * There should be test vectors available to confirm correctness. > Preferably from a source like NIST if possible, but worst case generated > (and verified) via multiple alternate implementations (we have examples of > this in our docs). > * If it isn't directly implemented in OpenSSL then we need to have some > degree of confidence it can be done safely (e.g. without introducing > exploitable side channels) via composition. > > So what currently uses ECIES? > > -Paul > > > On March 21, 2017 at 12:55:18 PM, French, Adam (afrench at illumina.com) > wrote: > > Hi everyone, > > I?m currently working on a project where I need to use the cryptography > library to encrypt/decrypt a message using an elliptic curve key pair. > > The ?Asymmetric algorithms? -> ?RSA? section of the official documentation > includes sections on RSA encryption/decryption using the OAEP scheme. In > contrast, the ?Asymmetric algorithms? -> ?Elliptic curve cryptography? > section has no similar operations such as ECIES encryption and decryption. > > I?ve written an implementation of the ECIES scheme for elliptic curve key > pairs which builds on the other primitives available through the > cryptography library. > > My boss is happy for me to spend some time creating a pull request to > share the implementation with the community. Do people feel there would be > sufficient interest for this to be worthwhile? Is there a roadmap for > elliptic curve functionality that I should be aware of? It would be great > to know how the project intends to extend the elliptic curve interfaces in > the future. > > Thank you very much for your help. > > Cheers, > Adam > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From readthedocs at readthedocs.org Wed Mar 22 22:56:56 2017 From: readthedocs at readthedocs.org (Read the Docs) Date: Thu, 23 Mar 2017 02:56:56 -0000 Subject: [Cryptography-dev] Failed: Cryptography (latest) Message-ID: <20170323025656.12276.74879@web04.servers.readthedocs.org> Build Failed for Cryptography (latest) You can find out more about this failure here: https://readthedocs.org/projects/cryptography/builds/5186794/ If you have questions, a good place to start is the FAQ: https://docs.readthedocs.org/en/latest/faq.html Keep documenting, Read the Docs -- http://readthedocs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From readthedocs at readthedocs.org Wed Mar 22 22:56:51 2017 From: readthedocs at readthedocs.org (Read the Docs) Date: Thu, 23 Mar 2017 02:56:51 -0000 Subject: [Cryptography-dev] Failed: Cryptography (latest) Message-ID: <20170323025651.21091.73987@web02.servers.readthedocs.org> Build Failed for Cryptography (latest) You can find out more about this failure here: https://readthedocs.org/projects/cryptography/builds/5186792/ If you have questions, a good place to start is the FAQ: https://docs.readthedocs.org/en/latest/faq.html Keep documenting, Read the Docs -- http://readthedocs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: