From andy.doran at sciencelogic.com Tue Mar 8 02:27:30 2022 From: andy.doran at sciencelogic.com (Doran, Andrew) Date: Tue, 8 Mar 2022 07:27:30 +0000 Subject: [Cryptography-dev] Certificates with RSASSA_PSS Message-ID: Hi, We are using the cryptography module with pyWinRM to run PowerShell scripts on Windows servers from Linux. We have a situation where this fails because of a certificate issue. If we edit oid.py to add:- SignatureAlgorithmOID.RSASSA_PSS: hashes.SHA256() to the dictionary _SIG_OIDS_TO_HASH, then everything works just fine. Are you planning to add this algorythm so that we can juts use an updated module? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Tue Mar 8 08:51:32 2022 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 8 Mar 2022 08:51:32 -0500 Subject: [Cryptography-dev] Certificates with RSASSA_PSS In-Reply-To: References: Message-ID: Hi Andrew, Unfortunately fully supporting PSS certificates is not merely a matter of adding a value to SIG_OIDS_TO_HASH. This is tracked in https://github.com/pyca/cryptography/issues/2850 and https://github.com/pyca/cryptography/issues/4858. However, if that PR works for you, then you can likely make do by using `cert.signature_algorithm_oid` instead of `cert.signature_algorithm` and mapping the OID to hash algorithm yourself. Alex On Tue, Mar 8, 2022 at 7:29 AM Doran, Andrew wrote: > > Hi, > > We are using the cryptography module with pyWinRM to run PowerShell scripts on Windows servers from Linux. We have a situation where this fails because of a certificate issue. If we edit oid.py to add:- > > SignatureAlgorithmOID.RSASSA_PSS: hashes.SHA256() > > to the dictionary _SIG_OIDS_TO_HASH, then everything works just fine. > > Are you planning to add this algorythm so that we can juts use an updated module? > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -- All that is necessary for evil to succeed is for good people to do nothing. From paul.l.kehrer at gmail.com Tue Mar 15 18:33:26 2022 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 16 Mar 2022 06:33:26 +0800 Subject: [Cryptography-dev] PyCA cryptography 36.0.2 released Message-ID: PyCA cryptography 36.0.2 has been released to PyPI. cryptography includes both high level recipes and low level interfaces to common cryptographic algorithms such as symmetric ciphers, asymmetric algorithms, message digests, X509, key derivation functions, and much more. We support Python 3.6+, and PyPy3. Changelog (https://cryptography.io/en/latest/changelog/#v36-0-2): * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 1.1.1n. -Paul Kehrer (reaperhulk) From cuu508 at monkeyseemonkeydo.lv Fri Mar 18 08:25:56 2022 From: cuu508 at monkeyseemonkeydo.lv (=?UTF-8?Q?P=C4=93teris_Caune?=) Date: Fri, 18 Mar 2022 14:25:56 +0200 Subject: [Cryptography-dev] Binary wheels for armv7l Message-ID: Hello, I'd like to bring up the topic of binary wheel packages for armv7l. They have already been discussed before, for example in this issue: https://github.com/pyca/cryptography/issues/6286 Quoting reaperhulk's comment from the issue: > Getting armv7l in hosted CI isn't really possible at this time and armv7l systems tend to be very low performance compared to their aarch64 brethren. We won't ship wheels for platforms we don't directly test, so that's the primary obstacle here. I develop a Python project which uses cryptography, and was revisiting the topic of building armv7l docker images that include cryptography. In the past I had resorted to using piwheels prebuilt wheels but looks like I managed to build it from source on GitHub Actions. Here's a quick summary on how it works: - My project is hosted on GitHub, and has a GHA workflow to automatically build and publish a docker docker image on every release - On GHA, you can build armv7l images by using docker buildx: https://github.com/docker/setup-buildx-action - But there's a bug in ... QEMU, if I understand correctly, which causes cryptography build to fail: https://github.com/rust-lang/cargo/issues/8719 - That bug is not fixed, but there is a workaround, which is even packaged up as a reusable GHA action: https://github.com/marketplace/actions/docker-on-tmpfs By using that workaround, I got cryptography to compile for armv7l with no errors. It took a long time to complete, but I'm not making releases often, so that's fine by me. For reference, here's my GHA workflow: https://github.com/healthchecks/healthchecks/blob/master/.github/workflows/publish_docker_image.yml I have no idea if it would be practical or feasible to integrate this technique in the cryptography build process (so an official wheel can be built), but I thought I would share this in case somebody is interested to investigate it. If there's no resources or interest to support this, I fully understand. P?teris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Fri Mar 18 08:57:13 2022 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 18 Mar 2022 20:57:13 +0800 Subject: [Cryptography-dev] Binary wheels for armv7l In-Reply-To: References: Message-ID: Thanks for providing a comprehensive post here. Compilation/testing under qemu is, unfortunately, too slow to be practical within our CI (which we've spent years getting to under 10 minutes cycle time). There's also a secondary challenge in that while armv7l tags are defined for manylinux on PyPI, the manylinux project does not itself ship armv7l containers. So official support from us has two primary prerequisites: 1) We need a way to run tests in CI against armv7l compiled code without affecting total cycle time. We already shard tests for Windows so maybe this would be possible by running armv7l containers on CircleCI aarch64 native runners? I know aarch32 exists for BC on armv8a, but I don't know how that interacts with the armv7l ABI. Is it possible to do this? 2) We need manylinux images to base our own wheel builder containers on top of. This isn't a hard blocker if #1 is possible, although it'd be best to contribute it upstream to pypa/manylinux and we just consume it. -Paul (reaperhulk) On Fri, Mar 18, 2022 at 8:26 PM P?teris Caune wrote: > > Hello, > > I'd like to bring up the topic of binary wheel packages for armv7l. They have already been discussed before, for example in this issue: https://github.com/pyca/cryptography/issues/6286 > > Quoting reaperhulk's comment from the issue: > > > Getting armv7l in hosted CI isn't really possible at this time and armv7l systems tend to be very low performance compared to their aarch64 brethren. We won't ship wheels for platforms we don't directly test, so that's the primary obstacle here. > > I develop a Python project which uses cryptography, and was revisiting the topic of building armv7l docker images that include cryptography. In the past I had resorted to using piwheels prebuilt wheels but looks like I managed to build it from source on GitHub Actions. Here's a quick summary on how it works: > > - My project is hosted on GitHub, and has a GHA workflow to automatically build and publish a docker docker image on every release > - On GHA, you can build armv7l images by using docker buildx: https://github.com/docker/setup-buildx-action > - But there's a bug in ... QEMU, if I understand correctly, which causes cryptography build to fail: https://github.com/rust-lang/cargo/issues/8719 > - That bug is not fixed, but there is a workaround, which is even packaged up as a reusable GHA action: https://github.com/marketplace/actions/docker-on-tmpfs > > By using that workaround, I got cryptography to compile for armv7l with no errors. It took a long time to complete, but I'm not making releases often, so that's fine by me. For reference, here's my GHA workflow: https://github.com/healthchecks/healthchecks/blob/master/.github/workflows/publish_docker_image.yml > > I have no idea if it would be practical or feasible to integrate this technique in the cryptography build process (so an official wheel can be built), but I thought I would share this in case somebody is interested to investigate it. If there's no resources or interest to support this, I fully understand. > > P?teris > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev From valerio7s at protonmail.com Thu Mar 24 01:54:13 2022 From: valerio7s at protonmail.com (valerio) Date: Thu, 24 Mar 2022 05:54:13 +0000 Subject: [Cryptography-dev] [Cryptography] yan-blockCipher (encryption base upon yan multiplication ) In-Reply-To: References: Message-ID: we develop new symmetric encryption algorithm this algorithm base upon yan theorem yan theorem a * b = u | l l/a = b 439 * 827 = 363 | 053 053 / 439 = 827 NOTE : yan block-cipher use yan 9 encryption algorithm (M+K1)*K2=C decryption algorithm (C/K2)-K1 = M we know that gcd(...) use to recover key in multiplication encryption K = gcd(C!,C2,C3,..) but gcd(...) don't work on yan division brute force attack work when you know one of them M, K otherwise you trap in yan cycle python program for testing purpose https://github.com/valerio7s/yan-crypto/blob/725e58ed5e907df6ae0901226f0409166463a87b/symmetricEncryption/yan-blockCipher_test.py manual cmd k for key e for encryption d for decryption default key 1 example >k 4567878764321761 4567878764321761 >e 1235464674897411 7753210264056092 >d 7753210264056092 1235464674897411 -------------- next part -------------- An HTML attachment was scrubbed... URL: