Mailman 3 July 2024 - Cryptography-dev

Survey on PyPI Metadata: Why Authors and Maintainers Link (or Don’t Link) Their Libraries to Code Repositories
by Alexandros Tsakpinis July 26, 2024

July 26, 2024

Dear PyPI author, tl;dr: We are researching why PyPI authors link (or don't) link their libraries to code repositories. Therefore, please participate in our 5-minute survey: https://forms.office.com/e/b5uvsPdJLF We have a question regarding your 2 libraries published on PyPI where you are assigned as responsible author. More information about your published libraries can be found in the attached .txt file. As you probably know, it is possible to attach project URL information to a library published on PyPI. Adding, for instance, the associated repository URL to a library enables others depending on that library to analyze present and historical maintenance and development activities in more detail. To better understand why authors decide to assign a valid repository URL, but also to learn about the factors why some don't link their repositories, we kindly ask you to answer the following survey with your published library(ies) in mind. The survey should take about 5 minutes. If you are interested in participating in the survey you can access it under the following link: https://forms.office.com/e/b5uvsPdJLF Thank you for your time and participation! You will not receive any further e-mails regarding this survey. With best regards, Alexandros Tsakpinis Alexandros Tsakpinis Research Scientist @ CCE [cid:fortiss_logo.png] fortiss GmbH Landesforschungsinstitut des Freistaats Bayern für softwareintensive Systeme An-Institut Technische Universität München Guerickestraße 25, 80805 München, Germany T: +49 (89) 3603522 185<tel:+49893603522185> F: +49 (89) 3603522 50 tsakpinis(a)fortiss.org<mailto:tsakpinis@fortiss.org> www.fortiss.org<http://www.fortiss.org> fortiss Newsletter<http://newsletter.fortiss.org> Datenschutzerklärung<http://datenschutz.fortiss.org> Amtsgericht München: HRB: 176633 USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900 Rechtsform: gemeinnützige GmbH Sitz der Gesellschaft: München Geschäftsführer: Dr. Holger Pfeifer, Thomas Vallon Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter

1 0

PyCA cryptography 43.0.0 released
by Paul Kehrer July 20, 2024

July 20, 2024

PyCA cryptography 43.0.0 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, X.509, key derivation functions, and much more. We support Python 3.7+, and PyPy3 7.3.10+. Changelog (https://cryptography.io/en/latest/changelog/#v43-0-0) * BACKWARDS INCOMPATIBLE: Support for OpenSSL less than 1.1.1e has been removed. Users on older version of OpenSSL will need to upgrade. * BACKWARDS INCOMPATIBLE: Dropped support for LibreSSL < 3.8. * Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.3.1. * Updated the minimum supported Rust version (MSRV) to 1.65.0, from 1.63.0. * generate_private_key() now enforces a minimum RSA key size of 1024-bit. Note that 1024-bit is still considered insecure, users should generally use a key size of 2048-bits. * serialize_certificates() now emits ASN.1 that more closely follows the recommendations in RFC 2315. * Added new Decrepit cryptography module which contains outdated and insecure cryptographic primitives. CAST5, SEED, IDEA, and Blowfish, which were deprecated in 37.0.0, have been added to this module. They will be removed from the cipher module in 45.0.0. * Moved TripleDES and ARC4 into Decrepit cryptography and deprecated them in the cipher module. They will be removed from the cipher module in 48.0.0. * Added support for deterministic ECDSA (RFC 6979) * Added support for client certificate verification to the X.509 path validation APIs in the form of ClientVerifier, VerifiedClient, and PolicyBuilder build_client_verifier(). * Added Certificate public_key_algorithm_oid and Certificate Signing Request public_key_algorithm_oid to determine the PublicKeyAlgorithmOID Object Identifier of the public key found inside the certificate. * Added invalidity_date_utc, a timezone-aware alternative to the naïve datetime attribute invalidity_date. * Added support for parsing empty DN string in from_rfc4514_string(). * Added the following properties that return timezone-aware datetime objects: produced_at_utc(), revocation_time_utc(), this_update_utc(), next_update_utc(), revocation_time_utc(), this_update_utc(), next_update_utc(), These are timezone-aware variants of existing properties that return naïve datetime objects. * Added rsa_recover_private_exponent() * Added reset_nonce() for altering the nonce of a cipher context without initializing a new instance. See the docs for additional restrictions. * NameAttribute now raises an exception when attempting to create a common name whose length is shorter or longer than RFC 5280 permits. * Added basic support for PKCS7 encryption (including SMIME) via PKCS7EnvelopeBuilder. -Paul Kehrer (reaperhulk)

1 0

Re: [Cryptography-dev] Cryptographic recipes
by Alex Gaynor July 16, 2024

July 16, 2024

Hi Ben, Unfortunately OpenPGP is more or less the canonical example of something we would _not_ want to offer as a recipe. Going back to my original criteria: * It should comprehensively address a common use case: It may do this. * It should reflect current (and anticipated future) best practices: It absolutely does not do this, PGP has been extremely laggard in adopting things like AEADs, and most implementations have indefensible defaults like using CAST5 for encryption. * It should be misuse-resistant: PGP is not misuse resistant, in fact there are legions of papers on how users are incapable of using it correctly. * It should reflect an external standard so that we can interoperate with other libraries and ecosystems: This is true! * It should be parameter-free: PGP has innumerable configuration options and knobs. You've noted that one _library_ offers PGP with a preset options, but this is not the same as the standard and ecosystem as a whole being misuse resistant and parameter free. Alex On Wed, Jun 26, 2024 at 4:41 PM Benjamin W. Portner <webmaster(a)benjamin-portner.de> wrote: > > Hi Alex, > > Let me try again: How about PGPy's encryption implementation > (https://github.com/SecurityInnovation/PGPy/blob/master/pgpy/pgp.py#L1189)? > It is based on the OpenPGP standard, it can be used without additional > parameters (which prevents misuse), and it addresses a common use case > (message encryption). > > Cheers, > > Ben > > On 25-Jun-24 00:09, Alex Gaynor wrote: > > Mis-use resistant means that it should be impossible (or as close as > > is practicable) for developers to misuse the APIs. Put another way: > > it's never acceptable to say that a system is insecure because a > > developer was holding it wrong. (c.f. > > https://www.wired.com/2010/06/iphone-4-holding-it-wrong/). > > > > In terms of what a standard means: it means there needs to be an > > external reference that other people can use to implement it and > > articulates what the goals are, what the security properties are, and > > how to implement it. https://github.com/C2SP/C2SP is an effort to > > build a community repository of such specifications. > > > > The fact that something is widely used is not, by itself, sufficient > > for us to treat it as a standard. > > > > Alex > > > > On Mon, Jun 24, 2024 at 5:42 PM Ben Portner via Cryptography-dev > > <cryptography-dev(a)python.org> wrote: > >> Hi Alex, > >> > >> thanks for your swift reply. Let me try to map your conditions to the Ansible implementation: > >> > >> * It should comprehensively address a common use case > >> > >> Check. Use case is encryption of sensitive data, such as passwords, in version control systems. > >> > >> * It should reflect current (and anticipated future) best practices > >> > >> As a cryptography noob I am not sure about this one. Someone else would have to analyze the implementation. > >> > >> * It should be misuse-resistant > >> > >> Not entirely sure what misuse refers to here. It cannot be used by crypto gangs? User errors are minimzed? The latter would be a check. > >> > >> * It should reflect an external standard so that we can interoperate with other libraries and ecosystems > >> > >> Ansible's vault implementation follows no existing standard. However, Ansible is the most widely used config management tool so vault could be called a de-facto standard by transitive properties? > >> > >> * It should be parameter-free > >> > >> Check. > >> > >> > >> It seems that Ansible checks most of the boxes. What do you think? Is this enough to include Ansible's vault implementation in the recipes section? > >> > >> - Ben > >> > >> > >> On 21-Jun-24 16:03, Alex Gaynor wrote: > >> > >> Hi Ben, > >> > >> We are interested in having more cryptographic recipes, however we > >> have a number of things we want from a recipe: > >> > >> * It should comprehensively address a common use case > >> * It should reflect current (and anticipated future) best practices > >> * It should be misuse-resistant > >> * It should reflect an external standard so that we can interoperate > >> with other libraries and ecosystems > >> * It should be parameter-free > >> > >> Unfortunately there's been a real dearth of standardization of these > >> types of recipes in the cryptographic world. I continue to hope that > >> more will come into existence, and we'll add support for them though! > >> > >> Alex > >> > >> On Fri, Jun 21, 2024 at 9:56 AM Ben Portner via Cryptography-dev > >> <cryptography-dev(a)python.org> wrote: > >> > >> Dear Cryptography Developers, > >> > >> First off, thank you for developing the Cryptography package! The Python developer community is growing and robust cryptography is desperately needed to have a safe fundament to build on. > >> > >> TL;DR: Are more cryptographic recipes (AES256, KDF incl. parameter storage) going to come soon? > >> > >> In your package description you write that "cryptography is a package which provides cryptographic recipes and primitives". As a developer and cryptography noob, I am especially interested in the recipes. In your docs, there are code snippets for the Fernet algorithm, which are very helpful. I am wondering if you are planning to expand this section in the near future. For example, I would be interested in learning how to store the key derviation parameters (salt, length, rounds) with the encrypted cipher text to facilitate decryption later on. Also, a version with 256 bit keys would be interesting. I believe that such a "reference implementation" would also benefit other developers. Ansible already uses Cryptography for its vault implementation, however with "only" 10k rounds for the KDF. As a cryptography noob, I am not sure if this is safe enough for my application (archive encryption for offsite backups). Having a "first hand" implementation with safe defaults would help to reduce developer uncertainty and also prevent us from "reinventing the wheel". > >> > >> Thanks again and best regards. > >> > >> Ben > >> > >> _______________________________________________ > >> Cryptography-dev mailing list > >> Cryptography-dev(a)python.org > >> https://mail.python.org/mailman/listinfo/cryptography-dev > >> > >> > >> _______________________________________________ > >> Cryptography-dev mailing list > >> Cryptography-dev(a)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.

5 8