From ralienpp at gmail.com Fri May 2 14:31:28 2014 From: ralienpp at gmail.com (Alex) Date: Fri, 2 May 2014 15:31:28 +0300 Subject: [Cryptography-dev] HSM and other algorithms Message-ID: Hi, Having reviewed the documentation of `cryptography` and looked through the available examples, I still have some unanswered questions. 1. how to use an HSM for private key storage? Are there any high-level features for this purpose, or is one expected to be familiar with how a specific backend deals with it? 2. are there plans to introduce high-level primitives for XAdES or PAdES signatures? Or is it outside the scope of the library (and we're supposed to do it ourselves via hazmat)? 3. what's the preferred method of requesting new things? Say, I would be interested in a sample that covers "how to produce PKCS7 signatures?", do I just open an issue on Github? I have previously used other Python crypto libraries, and `cryptography` looks clean and organized; it is certainly a step forward from having to fish for answers in OpenSSL code to figure out how a wrapper calls it. It is great that you have examples embedded in the documentation itself, that will be greatly appreciated by people who are looking for starting points. Alex p.s. eagerly waiting to find out which directions will be chosen with respect to parsing ASN1 structures :-) From paul.l.kehrer at gmail.com Fri May 2 16:16:33 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Fri, 2 May 2014 09:16:33 -0500 Subject: [Cryptography-dev] HSM and other algorithms In-Reply-To: References: Message-ID: Hi Alex, answers inline. On May 2, 2014 at 7:31:38 AM, Alex (ralienpp at gmail.com) wrote: Hi,? Having reviewed the documentation of `cryptography` and looked through? the available examples, I still have some unanswered questions.? 1. how to use an HSM for private key storage? Are there any high-level? features for this purpose, or is one expected to be familiar with how? a specific backend deals with it?? At the moment there is no support for HSMs. We have long-term plans for adding support for PKCS11 (and KMIP), and we may also expose the OpenSSL engine system more directly. Some of the work we?re undertaking for the next major release (there is one going out today/tomorrow) is focused on reworking the structure of our asymmetric key objects to be better suited for HSMs. 2. are there plans to introduce high-level primitives for XAdES or? PAdES signatures? Or is it outside the scope of the library (and we're? supposed to do it ourselves via hazmat)?? Our guiding principle for what is in scope for this library is that we want to be known as the cryptographic standard library for Python. XAdES and PAdES fit within that remit, so I?d support their inclusion (although I am not the only vote obviously!). They are quite different from what we?ve implemented so far in that we won?t get the construction for ?free? from the underlying library, and building a robust unit test suite may be challenging. If and when we start implementing constructions like this it will be interesting to see if we want them to still live in hazmat or if they?re high enough level that we?d feel comfortable exposing them as recipes (like Fernet). 3. what's the preferred method of requesting new things? Say, I would? be interested in a sample that covers "how to produce PKCS7? signatures?", do I just open an issue on Github?? Yes, opening an issue on GitHub is perfect. That?s how we track most of our work. We also hang out in IRC at #cryptography-dev so more informal discussions take place there all the time. I have previously used other Python crypto libraries, and? `cryptography` looks clean and organized; it is certainly a step? forward from having to fish for answers in OpenSSL code to figure out? how a wrapper calls it.? It is great that you have examples embedded in the documentation? itself, that will be greatly appreciated by people who are looking for? starting points.? We?re always interested in perspectives from consumers on how we can improve the docs, so if you?ve got ideas file an issue or make a PR and we?ll be happy to review/merge it! Alex? p.s. eagerly waiting to find out which directions will be chosen with? respect to parsing ASN1 structures :-)? _______________________________________________? 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 paul.l.kehrer at gmail.com Sat May 3 17:05:44 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 3 May 2014 10:05:44 -0500 Subject: [Cryptography-dev] 0.4 Released Message-ID: cryptography 0.4 has been released to pypi! Thanks to all the contributors for their hard work getting this release ready in the past week. You can see a high level changelog in the docs (https://cryptography.io/en/latest/changelog/) or view the entire diff on GitHub (https://github.com/pyca/cryptography/compare/e0d2e1ea7367e05197634c8c869678b7b169c102...0520c2973509f6a45d2ad06dc2d84a85958887b3). Master will be reopening shortly for development on the fifth release. -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From _ at lvh.io Sat May 3 17:06:33 2014 From: _ at lvh.io (Laurens Van Houtven) Date: Sat, 3 May 2014 10:06:33 -0500 Subject: [Cryptography-dev] 0.4 Released In-Reply-To: References: Message-ID: Thank you! On May 3, 2014 10:05 AM, "Paul Kehrer" wrote: > cryptography 0.4 has been released to pypi! > > Thanks to all the contributors for their hard work getting this release > ready in the past week. You can see a high level changelog in the docs ( > https://cryptography.io/en/latest/changelog/) or view the entire diff on > GitHub ( > https://github.com/pyca/cryptography/compare/e0d2e1ea7367e05197634c8c869678b7b169c102...0520c2973509f6a45d2ad06dc2d84a85958887b3 > ). > > Master will be reopening shortly for development on the fifth release. > > -Paul > > _______________________________________________ > 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 radix at twistedmatrix.com Sat May 3 21:33:15 2014 From: radix at twistedmatrix.com (Christopher Armstrong) Date: Sat, 3 May 2014 14:33:15 -0500 Subject: [Cryptography-dev] TLS-API update Message-ID: I spent the last few hours going over all of the current feedback on the proposed TLS API. The current version is here:?https://github.com/radix/cryptography/pull/1/files Major changes: - I got rid of ?negotiate? - ClientTLS.start now begins negotiation. - This made ClientSession and ServerSession identical, so I merged them into one class, ?Session?. - A lot of error behavior has now been better described. I specifically want to call into question the existence of the ?alert? method. I think it?s too low level for the common use case, and we should just relegate TLS alerts to an implementation detail. If necessary, we can add some contract to verify_callback to make e.g. certain exceptions raised translate to TLS alerts sent to the peer. Any thoughts? Another thing is we need to figure out some more APIs around certificates, like what methods ?Certificate? should have, and how we should allow the user to construct Certificates. (I need to spend some time looking at the new Python ?pem? module). Any input here will help. Please leave any comments you have! --? Christopher Armstrong http://twitter.com/radix http://wordeology.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Sat May 3 21:58:08 2014 From: glyph at twistedmatrix.com (Glyph) Date: Sat, 3 May 2014 12:58:08 -0700 Subject: [Cryptography-dev] TLS-API update In-Reply-To: References: Message-ID: <33E94E58-78C3-4FFC-AE5E-2F1A7BDCF7CD@twistedmatrix.com> On May 3, 2014, at 12:33 PM, Christopher Armstrong wrote: > - This made ClientSession and ServerSession identical, so I merged them into one class, ?Session?. Woot. This was sticking out for me. > I specifically want to call into question the existence of the ?alert? method. I think it?s too low level for the common use case, and we should just relegate TLS alerts to an implementation detail. If necessary, we can add some contract to verify_callback to make e.g. certain exceptions raised translate to TLS alerts sent to the peer. Any thoughts? If this is a library that is designed to expose the TLS specification to application code in a way which faithfully respects the spec's intent, then you can't relegate "alert" to an "implementation detail"; it's a part of the spec and therefore a part of the interface in some way. If this is a library that is designed to provide transport security (which might also use, say, NaCl) and not particularly expose all of the TLS specification, then it should have a layer which faithfully exposes the TLS specification below it and then have an abstract API which might paper over things like alerts. In either case you can't call an alert an implementation detail unless you are trying to construct a deliberately incomplete API. ;-) And you can't just stuff it into verify_callback because alerts can be sent later in the stream than the handshake, right? > Another thing is we need to figure out some more APIs around certificates, like what methods ?Certificate? should have, and how we should allow the user to construct Certificates. (I need to spend some time looking at the new Python ?pem? module). Any input here will help. The 'pem' module is for splitting up strings in one particular format and thus would not be a great rubric for a generalized constructing/loading/saving API for certificates. The thing you want to look at is the "Certificate" object in Twisted's API, which is what pem uses for building something that looks like an object. Remember Twisted, it's a library you used to work on? :-) In case I haven't been clear about this, I would very much like the stuff in twisted/internet/_sslverify.py to align as much as possible with the API being specified here. First off, it would be great to get rid of as many OpenSSL-isms as possible, and secondly, the more that our existing implementation can be made to approximate this, the easier it should be for Twisted to get out of the business of doing TLS at all (eventually). -g -------------- next part -------------- An HTML attachment was scrubbed... URL: From radix at twistedmatrix.com Sat May 3 23:05:52 2014 From: radix at twistedmatrix.com (Christopher Armstrong) Date: Sat, 3 May 2014 16:05:52 -0500 Subject: [Cryptography-dev] TLS-API update In-Reply-To: <33E94E58-78C3-4FFC-AE5E-2F1A7BDCF7CD@twistedmatrix.com> References: <33E94E58-78C3-4FFC-AE5E-2F1A7BDCF7CD@twistedmatrix.com> Message-ID: On May 3, 2014 2:59 PM, "Glyph" wrote: > > On May 3, 2014, at 12:33 PM, Christopher Armstrong < radix at twistedmatrix.com> wrote: > >> - This made ClientSession and ServerSession identical, so I merged them into one class, ?Session?. > > > Woot. This was sticking out for me. > >> I specifically want to call into question the existence of the ?alert? method. I think it?s too low level for the common use case, and we should just relegate TLS alerts to an implementation detail. If necessary, we can add some contract to verify_callback to make e.g. certain exceptions raised translate to TLS alerts sent to the peer. Any thoughts? > > > If this is a library that is designed to expose the TLS specification to application code in a way which faithfully respects the spec's intent, then you can't relegate "alert" to an "implementation detail"; it's a part of the spec and therefore a part of the interface in some way. > > If this is a library that is designed to provide transport security (which might also use, say, NaCl) and not particularly expose all of the TLS specification, then it should have a layer which faithfully exposes the TLS specification below it and then have an abstract API which might paper over things like alerts. > > In either case you can't call an alert an implementation detail unless you are trying to construct a deliberately incomplete API. ;-) Fair call: "implementation detail" isn't the right phrase to use. However, I emphatically do not want to faithfully respect the full flexibility of TLS, personally. So far, I'm thinking a good acid test for whether a feature should be included in this API is: has this ever been requested by a user of Twisted, or, say, the ssl module? I don't *think* that's the case for alerts, but maybe I'm wrong. > > And you can't just stuff it into verify_callback because alerts can be sent later in the stream than the handshake, right? > >> Another thing is we need to figure out some more APIs around certificates, like what methods ?Certificate? should have, and how we should allow the user to construct Certificates. (I need to spend some time looking at the new Python ?pem? module). Any input here will help. > > > The 'pem' module is for splitting up strings in one particular format and thus would not be a great rubric for a generalized constructing/loading/saving API for certificates. The thing you want to look at is the "Certificate" object in Twisted's API, which is what pem uses for building something that looks like an object. Remember Twisted, it's a library you used to work on? :-) > > In case I haven't been clear about this, I would very much like the stuff in twisted/internet/_sslverify.py to align as much as possible with the API being specified here. First off, it would be great to get rid of as many OpenSSL-isms as possible, and secondly, the more that our existing implementation can be made to approximate this, the easier it should be for Twisted to get out of the business of doing TLS at all (eventually). > > -g > > > _______________________________________________ > 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 donald at stufft.io Mon May 12 20:25:09 2014 From: donald at stufft.io (Donald Stufft) Date: Mon, 12 May 2014 14:25:09 -0400 Subject: [Cryptography-dev] What's in a name? Message-ID: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Our name continues to cause mass confusion and i?m pretty sure we all regret it. So let?s change it, or if not, why not? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From radix at twistedmatrix.com Mon May 12 20:40:20 2014 From: radix at twistedmatrix.com (Christopher Armstrong) Date: Mon, 12 May 2014 14:40:20 -0400 Subject: [Cryptography-dev] What's in a name? In-Reply-To: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Message-ID: Well, if we do end up splitting up the project into multiple parts, it may be an okay time to change the name too? --? Christopher Armstrong http://twitter.com/radix http://wordeology.com/ On May 12, 2014 at 2:25:36 PM, Donald Stufft (donald at stufft.io) wrote: Our name continues to cause mass confusion and i?m pretty sure we all regret it. So let?s change it, or if not, why not? ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ 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 jarret.raim at RACKSPACE.COM Mon May 12 22:28:39 2014 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Mon, 12 May 2014 20:28:39 +0000 Subject: [Cryptography-dev] What's in a name? In-Reply-To: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Message-ID: I would be fine with a name change, people get grumpy about it. I think dreid and alex were passionate about the current name? Jarret On 5/12/14, 11:25 AM, "Donald Stufft" wrote: >Our name continues to cause mass confusion and i?m pretty sure we all >regret it. > >So let?s change it, or if not, why not? > >----------------- >Donald Stufft >PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >DCFA > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5551 bytes Desc: not available URL: From dreid at dreid.org Mon May 12 23:02:44 2014 From: dreid at dreid.org (David Reid) Date: Mon, 12 May 2014 14:02:44 -0700 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Message-ID: Passion is not the right word to use there. I like saying `pip install cryptography`, but I don't have a strong attachment to the name 'cryptography'. I'm also very aware of the many problems with the name 'cryptography' most obviously the confusion that comes when talking about cryptography while also talking about cryptography. But then there is also the confusion of talking about cryptography or while NOT talking about cryptography, not to mention talking about cryptography while not talking about cryptography. Then there is the new user perspective. User: Hi I would like to encrypt something Experienced Person: Use cryptography. User: Well yes I would like to encrypt something, is there a library. Experienced Person: Yes cryptography! User: Uhh ok, I'm gonna go over there now. And another? User: Google 'python encryption' Google: [image: Inline image 1] User: oh look the standard lib? It says I should use PyCrypto. Oh PyCrypto Looks good to me. Experienced Person: Search github.com "ECB" :( But on the other hand? User: pip search crypto pip: ? pycryptopp - Python wrappers for a few algorithms from the Crypto++ library Coins - Tools for Bitcoin & other cryptocurrencies (incl. Litecoin, Namecoin, Peercoin, Primecoin, Dogecoin, Worldcoin, Megacoin, Anoncoin, Feathercoin, Terracoin, and Novacoin). M2Crypto - M2Crypto: A Python crypto and SSL toolkit peep - A "pip install" that is cryptographically guaranteed repeatable pycrypto - Cryptographic modules for Python. INSTALLED: 2.6.1 (latest) cryptoapy - Python/C++ wrapper for Microsoft cryptoapi services (currently, Russian GOST algorithms only) seccure - SECCURE compatible Elliptic Curve cryptography cspkeyset - CSP keyset management (currently Linux CryptoPro CSP hdimages only) simplecrypto - Simple cryptographic library for hashing and encrypting wheezy.security - A lightweight security/cryptography library pyelliptic - Python OpenSSL wrapper. For modern cryptography with ECC, AES, HMAC, Blowfish, ... worldcoin - Python API for the Worldcoin cryptocurrency. coinkit - Tools for Bitcoin & other cryptocurrencies (incl. Litecoin, Namecoin, Peercoin, Primecoin, Dogecoin, Worldcoin, Megacoin, Anoncoin, Feathercoin, Terracoin, and Novacoin). pyhash - Python Non-cryptographic Hash Library CommonCryptoLite - CommonCrypto ecdsa - ECDSA cryptographic signature library (pure python) INSTALLED: 0.10 LATEST: 0.11 cryptography - cryptography is a package which provides cryptographic recipes and primitives to Python developers. cryptocoin - Cryptocurrencies for Humans PyNaCl - Python binding to the Networking and Cryptography (NaCl) library qrypto - Crypto cipher to make it easier to encrypt and decrypt using Blowfish, This module also works with qrypto perl and PHP5 modules pycryptopan - A python implementation of Crypto-PAn a ip anonymization algorithm hobonickels - Python API for the Hobonickels cryptocurrency. Cryptotrade - Cryptocurrency trading API wrapper; MtGox and Tradehill cryptobox - NaCL-like toolkit using FIPS ciphers. CryptoIM - Crypto Instant Messenger python-keyczar - Toolkit for safe and simple cryptography beefish - simple file encryption using pycrypto persistent_crypto_dict - UNKNOWN Bcryptor - Python wrapper for bcrypt winrandom - Access to Cryptographic API random generator django-pgcryptoauth - Django hasher for pgcrypto encoded passwords. basic_crypto - Wrapper around PyCrypto providing basic symmetric key encryption with AES in CFB mode. pycogworks.crypto - Crypto functions used in the CogWorks lab. simplersa - A simple wrapper for M2Crypto's RSA functionality pkcs11 - Python object-oriented wrapper for PKCS11 (Cryptoki) dlls stanczyk - Client software for the exercises in Crypto 101, the introductory book on cryptography. py-secobj - A simple object encryptor and decryptor jaraco.crypto - UNKNOWN django-pgcrypto - Python and Django utilities for encrypted fields using pgcrypto. pcr - Python 3 Cryptography Toolkit django-crypto - Simple 2-way crypto functions for use with Django. leocornus.plonecrypto - Plone Cryptographic Toolkit pbp - simple crypto tool crypto - Simply tool for cryptography python_hashes - Library of interesting (non-cryptographic) hashes in pure Python. cryptography-vectors - Test vectors for the cryptography package. django-cryptocoin - A Django app to organize accepting bitcoin, litecoin, novacoin and other cryptocoins. SecureString - Clears the contents of strings containing cryptographic material crypto_primitives - Package contains basic crypto constructions used further by projects yawPyCrypto - yawPyCrypto wrapper library for PyCrypto CommonCrypto - Common Crypto bindings for Python desurveil - a cryptography tool with support for RSA and OAEP ancientsolutions-crypttools - Python Cryptography Utilities Cryptonet - Blockchain and Cryptonet Framework hybrid-crypto - Python module which exposes a simple hybrid cryptography abstraction on top of KeyCzar and pycrypto. pycube2crypto - An implementation of the cube2 cryptography functions in pure python. arthur - Software for the exercises in Crypto 101, the introductory book on cryptography. pycrypto-on-pypi - Cryptographic modules for Python. cryptotools - UNKNOWN ecc - Pure Python implementation of an elliptic curve cryptosystem based on FIPS 186-3 CryptoCoinChartsApi - Python API for www.cryptocoincharts.info PyECC - PyECC is a simple Python module for performing Elliptical Curve Cryptography cryptopy - Pure Python Cryptograpgy cryptobox-server - webinterface for handling encrypted disks Products.BastionCrypto - Zope/Plone PKI Suite asym - some tools and algorithms for asymetric cryptography m2ext - M2Crypto Extensions cryptoPNG - Read or write secret message hidden from/to PNG image. syscon-nc - syscon without cryptography EzCrypto - Easy to use wrapper around ryptographic libraries for Python User: Oh look, PyCrypto is already installed? So? while I think the name cryptography itself is very confusing? no one has ever suggested a better name. At least cryptography has the advantage that it is a word that someone is likely to type into a browser or other search box when looking for things related to cryptography. Often they will even type it after a python. I don't think we should be concerned that Zooko finds it confusing. Calling it wobblynonce doesn't help make it discoverable to people who just think they want to AES or RSA a thing. If we're going to change the name I'd like to have a good reason, something we can point to and say, these are some objective criteria for a name that is friendly to new users and here is a name that qualifies. Maybe such a thing doesn't exist though. -David On Mon, May 12, 2014 at 1:28 PM, Jarret Raim wrote: > I would be fine with a name change, people get grumpy about it. > > I think dreid and alex were passionate about the current name? > > Jarret > > On 5/12/14, 11:25 AM, "Donald Stufft" wrote: > > >Our name continues to cause mass confusion and i?m pretty sure we all > >regret it. > > > >So let?s change it, or if not, why not? > > > >----------------- > >Donald Stufft > >PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > >DCFA > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-05-12 at 1.48.32 PM.png Type: image/png Size: 83575 bytes Desc: not available URL: From donald at stufft.io Mon May 12 23:20:49 2014 From: donald at stufft.io (Donald Stufft) Date: Mon, 12 May 2014 17:20:49 -0400 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Message-ID: On May 12, 2014, at 5:02 PM, David Reid wrote: > So? while I think the name cryptography itself is very confusing? no one has ever suggested a better name. At least cryptography has the advantage that it is a word that someone is likely to type into a browser or other search box when looking for things related to cryptography. Often they will even type it after a python. > > I don't think we should be concerned that Zooko finds it confusing. Calling it wobblynonce doesn't help make it discoverable to people who just think they want to AES or RSA a thing. > > If we're going to change the name I'd like to have a good reason, something we can point to and say, these are some objective criteria for a name that is friendly to new users and here is a name that qualifies. Maybe such a thing doesn't exist though. I think a good reason is that every time cryptography is brought up it sounds like ?Who's on First?? where first you have to go through this protocol of well which cryptography do you mean. Yes we?ll lose some google juice from it but I think the benefit of removing the confusion of what the hell ?cryptography? means is well worth it. I don?t think the name actually matters that much for discoverability. If it did then Django, Twisted, six, fabric, paramiko, Werkzeug, etc would never be found. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alexs at prol.etari.at Mon May 12 23:30:17 2014 From: alexs at prol.etari.at (Alex Stapleton) Date: Mon, 12 May 2014 22:30:17 +0100 Subject: [Cryptography-dev] What's in a name? In-Reply-To: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> Message-ID: <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> I do quite like the name despite its failings. Maybe we should push the PyCA brand more than the individual packages? It would probably make searching a bit easier. On 12 May 2014 19:25:35 Donald Stufft wrote: > Our name continues to cause mass confusion and i?m pretty sure we all > regret it. > > So let?s change it, or if not, why not? > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > From glyph at twistedmatrix.com Tue May 13 00:14:21 2014 From: glyph at twistedmatrix.com (Glyph) Date: Mon, 12 May 2014 15:14:21 -0700 Subject: [Cryptography-dev] What's in a name? In-Reply-To: <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: > I do quite like the name despite its failings. Maybe we should push the PyCA brand more than the individual packages? It would probably make searching a bit easier. Would it make sense to then change the headings in the documentation and such to "PyCA's Cryptography Package"? -g From terrycwk1994 at gmail.com Tue May 13 04:51:13 2014 From: terrycwk1994 at gmail.com (Terry Chia) Date: Tue, 13 May 2014 10:51:13 +0800 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: I like the cryptography name although I'll be open to changing it. Is there any suggestions at all currently or is this a vague "we should change this so people won't get confused" thing? I like the idea of pushing PyCA more though. On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: > On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: > >> I do quite like the name despite its failings. Maybe we should push the PyCA brand more than the individual packages? It would probably make searching a bit easier. > > Would it make sense to then change the headings in the documentation and such to "PyCA's Cryptography Package"? > > -g > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev From paul.l.kehrer at gmail.com Tue May 13 05:01:17 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Mon, 12 May 2014 23:01:17 -0400 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: I do like the idea of making the pyca branding more prominent without necessarily changing the actual library?s name. Does the sentence "Download pyca?s cryptography, which is a library for python cryptography? sound unambiguous and reasonable? On May 12, 2014 at 10:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: I like the cryptography name although I'll be open to changing it. Is there any suggestions at all currently or is this a vague "we should change this so people won't get confused" thing? I like the idea of pushing PyCA more though. On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: > On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: > >> I do quite like the name despite its failings. Maybe we should push the PyCA brand more than the individual packages? It would probably make searching a bit easier. > > Would it make sense to then change the headings in the documentation and such to "PyCA's Cryptography Package"? > > -g > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From _ at lvh.io Tue May 13 11:41:22 2014 From: _ at lvh.io (Laurens Van Houtven) Date: Tue, 13 May 2014 11:41:22 +0200 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: Absolutely, except for the part where you suggest you can download (& presumably install) Python packages ;-) Just kidding. I think you're on the money :-) On May 13, 2014 5:01 AM, "Paul Kehrer" wrote: > I do like the idea of making the pyca branding more prominent without > necessarily changing the actual library?s name. Does the sentence "Download > pyca?s cryptography, which is a library for python cryptography? sound > unambiguous and reasonable? > > On May 12, 2014 at 10:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: > > I like the cryptography name although I'll be open to changing it. Is > there any suggestions at all currently or is this a vague "we should > change this so people won't get confused" thing? I like the idea of > pushing PyCA more though. > > On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: > > On May 12, 2014, at 2:30 PM, Alex Stapleton > wrote: > > > >> I do quite like the name despite its failings. Maybe we should push the > PyCA brand more than the individual packages? It would probably make > searching a bit easier. > > > > Would it make sense to then change the headings in the documentation and > such to "PyCA's Cryptography Package"? > > > > -g > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 terrycwk1994 at gmail.com Tue May 13 12:03:53 2014 From: terrycwk1994 at gmail.com (Terry Chia) Date: Tue, 13 May 2014 18:03:53 +0800 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: +1 for what Paul said. dreid brought up an interesting point. how difficult will it be to get the python stdlib documentation to mention us? On Tue, May 13, 2014 at 6:01 PM, Terry Chia wrote: > +1 for what Paul said. > > dreid brought up an interesting point. how difficult will it be to get > the python stdlib documentation to mention us? > > On Tue, May 13, 2014 at 5:41 PM, Laurens Van Houtven <_ at lvh.io> wrote: >> Absolutely, except for the part where you suggest you can download (& >> presumably install) Python packages ;-) >> >> Just kidding. I think you're on the money :-) >> >> On May 13, 2014 5:01 AM, "Paul Kehrer" wrote: >>> >>> I do like the idea of making the pyca branding more prominent without >>> necessarily changing the actual library?s name. Does the sentence "Download >>> pyca?s cryptography, which is a library for python cryptography? sound >>> unambiguous and reasonable? >>> >>> On May 12, 2014 at 10:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: >>> >>> I like the cryptography name although I'll be open to changing it. Is >>> there any suggestions at all currently or is this a vague "we should >>> change this so people won't get confused" thing? I like the idea of >>> pushing PyCA more though. >>> >>> On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: >>> > On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: >>> > >>> >> I do quite like the name despite its failings. Maybe we should push the >>> >> PyCA brand more than the individual packages? It would probably make >>> >> searching a bit easier. >>> > >>> > Would it make sense to then change the headings in the documentation and >>> > such to "PyCA's Cryptography Package"? >>> > >>> > -g >>> > _______________________________________________ >>> > 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 >>> >>> >>> _______________________________________________ >>> Cryptography-dev mailing list >>> Cryptography-dev at python.org >>> https://mail.python.org/mailman/listinfo/cryptography-dev >>> >> From ralienpp at gmail.com Mon May 19 17:38:54 2014 From: ralienpp at gmail.com (Alex) Date: Mon, 19 May 2014 18:38:54 +0300 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: Hi, I was just looking for some code examples and the query "python cryptography pkcs7" reminded me of this thread. > So? while I think the name cryptography itself is very confusing? no one > has ever suggested a better name. Since `cryptography` is supposed to be the definitive answer to all our cryptographic needs, I would say `omnicrypto`. The Latin "omnia" means "all" or "every", and "crypto" has to be there to make the package easy to find via search engines. An alternative could be `pancrypto`, from the Greek "pan" = "all"; though it might be interpreted as something related to frying pans :-) > Would it make sense to then change the headings in the > documentation and such to "PyCA's Cryptography Package"? Will it not end up as something like "Linux" vs "GNU/Linux"? The path of least resistance is to omit all but the minimum needed to uniquely identify the target. If the bare minimum is too long, people will shorten it anyway (to something you might be unable to control). From randall.leeds at gmail.com Mon May 19 23:28:40 2014 From: randall.leeds at gmail.com (Randall Leeds) Date: Mon, 19 May 2014 14:28:40 -0700 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: On May 19, 2014 11:38 AM, "Alex" wrote: > > Since `cryptography` is supposed to be the definitive answer to all > our cryptographic needs, I would say `omnicrypto`. > > The Latin "omnia" means "all" or "every", and "crypto" has to be there > to make the package easy to find via search engines. An alternative > could be `pancrypto`, from the Greek "pan" = "all"; though it might be > interpreted as something related to frying pans :-) "crypto" is from the Greek so pancrypto would be more consistent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dreid at dreid.org Mon May 19 23:52:03 2014 From: dreid at dreid.org (David Reid) Date: Mon, 19 May 2014 14:52:03 -0700 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: ITYM pankryptos. On Mon, May 19, 2014 at 2:28 PM, Randall Leeds wrote: > On May 19, 2014 11:38 AM, "Alex" wrote: > > > > Since `cryptography` is supposed to be the definitive answer to all > > our cryptographic needs, I would say `omnicrypto`. > > > > The Latin "omnia" means "all" or "every", and "crypto" has to be there > > to make the package easy to find via search engines. An alternative > > could be `pancrypto`, from the Greek "pan" = "all"; though it might be > > interpreted as something related to frying pans :-) > > "crypto" is from the Greek so pancrypto would be more consistent. > > _______________________________________________ > 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 paul.l.kehrer at gmail.com Tue May 20 00:10:49 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Mon, 19 May 2014 17:10:49 -0500 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: I (along with Alex Gaynor) tried out ?PyCA cryptography? at the OpenStack Summit and it seemed to work reasonably well. I?m inclined to go with that for now. Do others agree/should we update our docs to use that as disambiguation? On May 12, 2014 at 9:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: I like the cryptography name although I'll be open to changing it. Is there any suggestions at all currently or is this a vague "we should change this so people won't get confused" thing? I like the idea of pushing PyCA more though. On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: > On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: > >> I do quite like the name despite its failings. Maybe we should push the PyCA brand more than the individual packages? It would probably make searching a bit easier. > > Would it make sense to then change the headings in the documentation and such to "PyCA's Cryptography Package"? > > -g > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From terrycwk1994 at gmail.com Tue May 20 05:59:22 2014 From: terrycwk1994 at gmail.com (Terry Chia) Date: Tue, 20 May 2014 11:59:22 +0800 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: +1 for what Paul said. On Tue, May 20, 2014 at 6:10 AM, Paul Kehrer wrote: > I (along with Alex Gaynor) tried out ?PyCA cryptography? at the OpenStack > Summit and it seemed to work reasonably well. I?m inclined to go with that > for now. Do others agree/should we update our docs to use that as > disambiguation? > > On May 12, 2014 at 9:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: > > I like the cryptography name although I'll be open to changing it. Is > there any suggestions at all currently or is this a vague "we should > change this so people won't get confused" thing? I like the idea of > pushing PyCA more though. > > On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: >> On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: >> >>> I do quite like the name despite its failings. Maybe we should push the >>> PyCA brand more than the individual packages? It would probably make >>> searching a bit easier. >> >> Would it make sense to then change the headings in the documentation and >> such to "PyCA's Cryptography Package"? >> >> -g >> _______________________________________________ >> 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 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > From glyph at twistedmatrix.com Tue May 20 06:48:42 2014 From: glyph at twistedmatrix.com (Glyph) Date: Mon, 19 May 2014 21:48:42 -0700 Subject: [Cryptography-dev] What's in a name? In-Reply-To: References: <7846F5D7-8F4A-4656-96DC-9528DC74F6C1@stufft.io> <145f254fbf8.2771.91731227630488f1d17e3e780e9eb50a@prol.etari.at> Message-ID: <46201E5D-F14F-49BE-AD10-AB4889725ACB@twistedmatrix.com> This is what I've been experimentally shifting my nomenclature to as well. It sounds reasonably clear, it's unambiguous, and if someone doesn't know what "PyCA" is, they ask - as opposed to thinking they know what "cryptography" is and then getting real confused ;-). -g On May 19, 2014, at 8:59 PM, Terry Chia wrote: > +1 for what Paul said. > > On Tue, May 20, 2014 at 6:10 AM, Paul Kehrer wrote: >> I (along with Alex Gaynor) tried out ?PyCA cryptography? at the OpenStack >> Summit and it seemed to work reasonably well. I?m inclined to go with that >> for now. Do others agree/should we update our docs to use that as >> disambiguation? >> >> On May 12, 2014 at 9:58:40 PM, Terry Chia (terrycwk1994 at gmail.com) wrote: >> >> I like the cryptography name although I'll be open to changing it. Is >> there any suggestions at all currently or is this a vague "we should >> change this so people won't get confused" thing? I like the idea of >> pushing PyCA more though. >> >> On Tue, May 13, 2014 at 6:14 AM, Glyph wrote: >>> On May 12, 2014, at 2:30 PM, Alex Stapleton wrote: >>> >>>> I do quite like the name despite its failings. Maybe we should push the >>>> PyCA brand more than the individual packages? It would probably make >>>> searching a bit easier. >>> >>> Would it make sense to then change the headings in the documentation and >>> such to "PyCA's Cryptography Package"? >>> >>> -g >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 From dreid at dreid.org Thu May 22 02:04:11 2014 From: dreid at dreid.org (David Reid) Date: Wed, 21 May 2014 17:04:11 -0700 Subject: [Cryptography-dev] Reducing the impact of Backends on higher level APIs. Message-ID: In PyCA's Cryptography the backend is the object responsible for providing one of many lowest common denominator APIs to binding specific interfaces. ``CipherBackend`` for example provides methods for interogating the support ciphers, and creating encryption or decryption ``CipherContext`` objects. It notably does NOT contain any methods for encrypting or decrypting bytes, it instead returns a ``CipherContext`` provider, whose interface is designed to ONLY care about transforming bytes. It does not even indicate in which direction bytes should be transformed. This makes it possible to construct APIs which are not aware of our backend/binding infrastructure at all, and to simply provide atlernative methods for getting ``CipherContext`` objects. For instance a trivial implementation of a ``ROT13CipherContext`` is: .. code-block:: python import codecs class ROT13CipherContext(object): def update(self, data): str_data = data.decode('ascii') rot13 = codecs.encode(str_data, 'rot13') return rot13.encode('ascii') def finalize(): return b"" This ``CipherContext`` provider can be passed to any code that expects a ``CipherContext`` and no backends need to be provided. This is desirable because the backends are a lowest common denominator and are now free from the burden of being indefinitely extensible, after all nothing says that only a ``CipherBackend`` can produce a ``CipherContext``. A more realistic example of using this capability is PyNACL, which has support for symmetric encryption but does not expose algorithms or modes and so does not fit easily into the ``Cipher(algorithm, mode, backend)`` API. Instead PyNACL could expose a new object, ``SecretCipher(key, nonce)`` .. code-block:: python class SecretCipherContext(object): def __init__(self, operator, nonce): self._operator = operator self._nonce = nonce self._message = [] def update(self, data): self._message.append(data) return b"" def finalize(self): return self._operator(b"".join(self._message), self._nonce) class SecretCipher(object): def __init__(self, key, nonce): self._box = SecretBox(key) self._nonce = nonce def encryptor(self): return SecretCipherContext(self._box.encrypt, self._nonce) def decryptor(self): return SecretCipherContext(self._box.decrypt, self._nonce) It would be cumbersome to try to fit this construction into `CipherBackend`, requiring a custom backend that provided synthetic algorithm and mode objects which are only used for activating the NaCL backend. Or a `NaCLBackend` interface which is effectively implemented as above despite there being no other providers. However the above demonstrates that there is still a compatible API that PyNaCl can expose to allow it to be a drop-in replacement for ``CipherContext`` objects created by the ``CipherBackend``. The conclusion I've drawn from this is that not every feature requires interfaces at both the primitives and the backend layer. Perhaps more importantly not every feature SHOULD provide interfaces at both the primitives and the backend layer, something we have already demonstrated in our PKCS7 padding implementation. At this point we must consider the application of these ideas to the body of Asymmetric Backends. The ``AsymmetricSignatureContext`` and the ``AsymmetricVerificationContext`` interfaces are obviously analagous to the ``CipherContext`` above, it is clear how they might be easily used in code that is both unaware of any particular backend interfaces and unaware of the particular asymmetric algorithms being used, and how alternative mechanisms for producing these providers might not involve a backend at all. In fact PyNaCl could easily expose NaCl's signature APIs as the above contexts with little trouble and no need for a separate backend layer (implementation left as an exercise for the reader). To reiterate, the important property is not that any specific provider is unaware of backends, but that the interfaces do not force any particular object to be concerned about the existence of backends. Knowledge of backends stays firmly rooted in the construction of a few objects which produce the objects that perform actual operations, and not all producers of the operation contexts need to know about backends. It is worth noting at this point that with the exception of ``RSAPrivateKey``, ``RSAPublicKey``, and the DSA equivalents, no methods exist in the primitive interfaces that take a backend argument. This startling departure would seem to indicate a problem with our understanding of the purpose of objects that provide this interface. ``RSABackend`` specifically exposes a set of methods whose only job is to be called from a concrete provider of the ``RSAPrivateKey`` to produce the above ``*Context`` interfaces. I would propose instead that operations in our asymmetric interfaces can be separated into two categories, operations you invoke to get a key (such as generation or deserialization) and operations that you invoke with a key (such as acquiring a signature or verification contexts and serialization). Further I would suggest that only operations in the first category ever need to potentially be aware of a backend. Operations performed with a key in contrast only ever need to know that they have a key. The fact that the key may have originated from a particular backend does not affect the user (except in that some algorithms or serialization formats may not be supported by all backends, and therefor all keys produces by all backends.) Ignoring for a moment the representation of keys as python integers, and the ability to use a key produced by one backend with another, the RSA interfaces could begin to look like this:: RSABackend | +-generate_rsa_key(public_exponent, key_size) -> RSAPrivateKey RSAPrivateKey | +-public_key() -> RSAPublicKey | +-signer(padding, algorithm) -> AsymmetricSignatureContext | +-decrypt(ciphertext, padding) -> bytes RSAPublicKey | +-verifier(padding, algorithm) -> AsymmetricVerificationContext | +-encrypt(plaintext, padding) -> bytes Now you can see that you only need the backend for getting the key, and the beyond that it is assumed you have a backend specific ``RSAPrivateKey`` provider that just uses that backend to perform the desired operations. Other mechanisms for getting a private key for a specific backend would be deserialization, which I imagine would be achieved by a specific backend provider, implementing one of several asymmetric algorithm agnostic backend interfaces, such as a ``PKCS8Backend`` or the ``TraditionalOpenSSLSerializationBackend``. As for the handling of key serialization I think it is best treated as an operation you perform with a key, and therefor a method on a particular key provider communicated via an optional key interface. For instance since the OpenSSL backend supports both RSA and PKCS8 it would produce objects that provide both the ``RSAPrivateKey`` interface, and some PKCS8 specific interface like:: PKCS8Key | +-pkcs8_der() -> bytes | +-pkcs8_pem(passphrase, algorithm, mode) -> bytes Another proposal for serialization APIs might be that there are functions for performing serialization that take keys, and that keys would then need a standard interface for accessing their raw data (likely as python integers) and it means that at serialization time you would need access to a backend. Either for constructing a serializer object, or being passed directly to the function for serializing the data alongside the key. Much more discussion needs to happen about the exact details of any serialization API, I currently favor the ``PKCS8Key`` API however. I'd now like to address the ability to use a key on multiple backends, which was one of the driving factors (in addition to the test vectors) behind our earlier decision to include the python integers that make up the components of an RSA key on our RSA specific interfaces. It is not clear to me that there is actual value in such a feature. So I would like to officially propose that we do not plan to support it in the near future. However it is clear that the way decided to represent keys to hypothetically support that feature has made some things more complicated. It has resulted in many more methods on the backend (because a key once loaded or generated, is now unrelated to a backend) and it has resulted in a proliferation of properties on the key interface to expose the key as python integers for the purpose of later conversion to backend specific objects. This repeated conversion has both performance and security implications and is not trivially mitigated without violating the key abstraction by attaching private content to it or by utilizing a weakref cache of keys to backend specific objects. I believe the benefits of avoiding this repeated conversion and simplifying the backend APIs by removing extra methods, and removing backend awareness from the private key, outweight the immediate downsides of losing the ability to use a key loaded with one backend to perform an operation on another. Transitioning to backend specific keys and removing the properties that expose key components as integers from the key objects also has the side effect of making the ``RSAPrivateKey`` the lowest common denominator interface for a keys stored in memory and keys potentially stored in some HSM or other agent that does not provide direct access to key components. It is however still useful to take a series of integers and load them as a key. Most immediately it is useful for the test vectors which are in a non-standardized format that provides little value outside of testing multiple backend implementations of the algorithms. To facilitate this testing, it seems clear that any ``RSABackend`` would need to be able to create a backend specific keys from these numbers. However this situations is complicated by the fact that not all backend providers use the same set of numbers to represent a key, meaning significant transformation may need to be done by the backend to turn the set of numbers in the vectors into the set of numbers that can be loaded by the backend, or that the backend may need to convert the numbers to some intermediate standard serialization that the backend under test already knows how to load. I believe it's important to support this representation and that it by treating it as a (de)serialization problem we can solve it relatively easily in the above framework (incidentally this may provide a path towards supporting multi-backend supporting keys but I don't want to focus on that). What is needed to support these is: 1. An in memory representation of the key components. 2. A backend method for loading this representation into a backend specific key. 3. An optional method for converting a backend specific key to this representation. In a series of pull requests I've started to lay out a migration path towards this format however the desired end result is somewhat obscured by the method of preserving compatibility. So to lay out what I expect will be the end result: An in memory representation:: RSAPrivateNumbers | +-public_numbers() -> RSAPublicNumbers | +- RSAPublicNumbers | +- It seems necessary given the reliance of our testing infrastructure on this representation that you should always be able to load it, thus it seems like it should be part of the previously specified ``RSABackend``:: RSABackend | +-load_rsa_numbers(rsa_numbers) -> RSAPrivateKey | RSAPublicKey I've chosen to support loading both objects in one method for the symmetry with other deserialization APIs where you do not necessarily know if you have a private or a public key. However it seems harder to avoid knowing that you have an RSA key so perhaps this attempt at preserving symmetry is in vain. And much like the above ``PKCS8Key`` proposal it is expected that an ``RSABackend`` will sometimes produce keys which can be turned back into this format (though it is not required as in the case of supporting an HSM.):: RSANumbersKey | +-rsa_numbers() -> RSAPrivateNumbers | RSAPublicNumbers Though my previous pull request specified too interfaces, I think I am leaning more towards one interface and one method that returns either a public or private representation for symmetry with both the loading API and the other serialization format proposal. I have no spent nearly 6 hours writing this email. I hope it either successfully convinces everyone who wishes to be involved or that it is a useful starting point for further conversation. More specifically I hope I have effectively communicated: 1) Why I think backend specific keys are desirable. 2) How I think they should be exposed to the user. 3) How this approach is more consistent with our other interfaces. 4) Why these properties are desirable in our other interfaces and should be mimiced in our asymmetric interface. 5) That backends are a necessary public api for cryptography to function, but an implementation detail of cryptography that is not necessary for useful levels of compatibility with cryptography. -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Thu May 22 18:12:59 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 22 May 2014 11:12:59 -0500 Subject: [Cryptography-dev] Reducing the impact of Backends on higher level APIs. In-Reply-To: References: Message-ID: So I have let this marinate in my brain all night and my only response is: you?ve convinced me. On May 21, 2014 at 7:04:23 PM, David Reid (dreid at dreid.org) wrote: In PyCA's Cryptography the backend is the object responsible for providing one of many lowest common denominator APIs to binding specific interfaces. ``CipherBackend`` for example provides methods for interogating the support ciphers, and creating encryption or decryption ``CipherContext`` objects. It notably does NOT contain any methods for encrypting or decrypting bytes, it instead returns a ``CipherContext`` provider, whose interface is designed to ONLY care about transforming bytes. It does not even indicate in which direction bytes should be transformed. This makes it possible to construct APIs which are not aware of our backend/binding infrastructure at all, and to simply provide atlernative methods for getting ``CipherContext`` objects. For instance a trivial implementation of a ``ROT13CipherContext`` is: .. code-block:: python ? ? import codecs ? ? class ROT13CipherContext(object): ? ? ? ? def update(self, data): ? ? ? ? ? ? str_data = data.decode('ascii') ? ? ? ? ? ? rot13 = codecs.encode(str_data, 'rot13') ? ? ? ? ? ? return rot13.encode('ascii') ? ? ? ? def finalize(): ? ? ? ? ? ? return b"" This ``CipherContext`` provider can be passed to any code that expects a ``CipherContext`` and no backends need to be provided. This is desirable because the backends are a lowest common denominator and are now free from the burden of being indefinitely extensible, after all nothing says that only a ``CipherBackend`` can produce a ``CipherContext``. A more realistic example of using this capability is PyNACL, which has support for symmetric encryption but does not expose algorithms or modes and so does not fit easily into the ``Cipher(algorithm, mode, backend)`` API. Instead PyNACL could expose a new object, ``SecretCipher(key, nonce)`` .. code-block:: python ? ? class SecretCipherContext(object): ? ? ? ? def __init__(self, operator, nonce): ? ? ? ? ? ? self._operator = operator ? ? ? ? ? ? self._nonce = nonce ? ? ? ? ? ? self._message = [] ? ? ? ? def update(self, data): ? ? ? ? ? ? self._message.append(data) ? ? ? ? ? ? return b"" ? ? ? ? def finalize(self): ? ? ? ? ? ? return self._operator(b"".join(self._message), self._nonce) ? ? class SecretCipher(object): ? ? ? ? def __init__(self, key, nonce): ? ? ? ? ? ? self._box = SecretBox(key) ? ? ? ? ? ? self._nonce = nonce ? ? ? ? def encryptor(self): ? ? ? ? ? ? return SecretCipherContext(self._box.encrypt, self._nonce) ? ? ? ? def decryptor(self): ? ? ? ? ? ? return SecretCipherContext(self._box.decrypt, self._nonce) It would be cumbersome to try to fit this construction into `CipherBackend`, requiring a custom backend that provided synthetic algorithm and mode objects which are only used for activating the NaCL backend. Or a `NaCLBackend` interface which is effectively implemented as above despite there being no other providers. However the above demonstrates that there is still a compatible API that PyNaCl can expose to allow it to be a drop-in replacement for ``CipherContext`` objects created by the ``CipherBackend``. The conclusion I've drawn from this is that not every feature requires interfaces at both the primitives and the backend layer. Perhaps more importantly not every feature SHOULD provide interfaces at both the primitives and the backend layer, something we have already demonstrated in our PKCS7 padding implementation. At this point we must consider the application of these ideas to the body of Asymmetric Backends. The ``AsymmetricSignatureContext`` and the ``AsymmetricVerificationContext`` interfaces are obviously analagous to the ``CipherContext`` above, it is clear how they might be easily used in code that is both unaware of any particular backend interfaces and unaware of the particular asymmetric algorithms being used, and how alternative mechanisms for producing these providers might not involve a backend at all. In fact PyNaCl could easily expose NaCl's signature APIs as the above contexts with little trouble and no need for a separate backend layer (implementation left as an exercise for the reader). To reiterate, the important property is not that any specific provider is unaware of backends, but that the interfaces do not force any particular object to be concerned about the existence of backends. Knowledge of backends stays firmly rooted in the construction of a few objects which produce the objects that perform actual operations, and not all producers of the operation contexts need to know about backends. It is worth noting at this point that with the exception of ``RSAPrivateKey``, ``RSAPublicKey``, and the DSA equivalents, no methods exist in the primitive interfaces that take a backend argument. This startling departure would seem to indicate a problem with our understanding of the purpose of objects that provide this interface. ``RSABackend`` specifically exposes a set of methods whose only job is to be called from a concrete provider of the ``RSAPrivateKey`` to produce the above ``*Context`` interfaces. I would propose instead that operations in our asymmetric interfaces can be separated into two categories, operations you invoke to get a key (such as generation or deserialization) and operations that you invoke with a key (such as acquiring a signature or verification contexts and serialization). Further I would suggest that only operations in the first category ever need to potentially be aware of a backend. ?Operations performed with a key in contrast only ever need to know that they have a key. ?The fact that the key may have originated from a particular backend does not affect the user (except in that some algorithms or serialization formats may not be supported by all backends, and therefor all keys produces by all backends.) Ignoring for a moment the representation of keys as python integers, and the ability to use a key produced by one backend with another, the RSA interfaces could begin to look like this:: ? ? RSABackend ? ? ?| ? ? ?+-generate_rsa_key(public_exponent, key_size) -> RSAPrivateKey ? ? RSAPrivateKey ? ? ?| ? ? ?+-public_key() -> RSAPublicKey ? ? ?| ? ? ?+-signer(padding, algorithm) -> AsymmetricSignatureContext ? ? ?| ? ? ?+-decrypt(ciphertext, padding) -> bytes ? ? RSAPublicKey ? ? ?| ? ? ?+-verifier(padding, algorithm) -> AsymmetricVerificationContext ? ? ?| ? ? ?+-encrypt(plaintext, padding) -> bytes Now you can see that you only need the backend for getting the key, and the beyond that it is assumed you have a backend specific ``RSAPrivateKey`` provider that just uses that backend to perform the desired operations. Other mechanisms for getting a private key for a specific backend would be deserialization, which I imagine would be achieved by a specific backend provider, implementing one of several asymmetric algorithm agnostic backend interfaces, such as a ``PKCS8Backend`` or the ``TraditionalOpenSSLSerializationBackend``. As for the handling of key serialization I think it is best treated as an operation you perform with a key, and therefor a method on a particular key provider communicated via an optional key interface. For instance since the OpenSSL backend supports both RSA and PKCS8 it would produce objects that provide both the ``RSAPrivateKey`` interface, and some PKCS8 specific interface like:: ? ? PKCS8Key ? ? ?| ? ? ?+-pkcs8_der() -> bytes ? ? ?| ? ? ?+-pkcs8_pem(passphrase, algorithm, mode) -> bytes Another proposal for serialization APIs might be that there are functions for performing serialization that take keys, and that keys would then need a standard interface for accessing their raw data (likely as python integers) ?and it means that at serialization time you would need access to a backend. Either for constructing a serializer object, or being passed directly to the ?function for serializing the data alongside the key. Much more discussion needs to happen about the exact details of any serialization API, I currently favor the ``PKCS8Key`` API however. I'd now like to address the ability to use a key on multiple backends, which was one of the driving factors (in addition to the test vectors) behind our earlier decision to include the python integers that make up the components of an RSA key on our RSA specific interfaces. It is not clear to me that there is actual value in such a feature. So I would like to officially propose that we do not plan to support it in the near future. However it is clear that the way decided to represent keys to hypothetically support that feature has made some things more complicated. It has resulted in many more methods on the backend (because a key once loaded or generated, is now unrelated to a backend) and it has resulted in a proliferation of properties on the key interface to expose the key as python integers for the purpose of later conversion to backend specific objects. This repeated conversion has both performance and security implications and ?is not trivially mitigated without violating the key abstraction by attaching private content to it or by utilizing a weakref cache of keys to backend specific objects. I believe the benefits of avoiding this repeated conversion and simplifying the backend APIs by removing extra methods, and removing backend awareness from the private key, outweight the immediate downsides of losing the ability to use a key loaded with one backend to perform an operation on another. Transitioning to backend specific keys and removing the properties that expose key components as integers from the key objects also has the side effect of making the ``RSAPrivateKey`` the lowest common denominator interface for a keys stored in memory and keys potentially stored in some HSM or other agent that does not provide direct access to key components. It is however still useful to take a series of integers and load them as a key. Most immediately it is useful for the test vectors which are in a non-standardized ?format that provides little value outside of testing multiple backend implementations of the algorithms. To facilitate this testing, it seems clear that any ``RSABackend`` would need to be able to create a backend specific keys from these numbers. However this situations is complicated by the fact that not all backend providers use the same set of numbers to represent a key, meaning significant transformation may need to be done by the backend to turn the set of numbers in the vectors into the set of numbers that can be loaded by the ?backend, or that the backend may need to convert the numbers to some intermediate standard serialization that the backend under test already knows how to load. I believe it's important to support this representation and that it by treating it as a (de)serialization problem we can solve it relatively easily in the above framework (incidentally this may provide a path towards supporting multi-backend supporting keys but I don't want to focus on that). What is needed to support these is: 1. An in memory representation of the key components. 2. A backend method for loading this representation into a backend specific key. 3. An optional method for converting a backend specific key to this representation. In a series of pull requests I've started to lay out a migration path towards this format however the desired end result is somewhat obscured by the method of preserving compatibility. So to lay out what I expect will be the end result: An in memory representation:: ? ? RSAPrivateNumbers ? ? ?| ? ? ?+-public_numbers() -> RSAPublicNumbers ? ? ?| ? ? ?+- ? ? RSAPublicNumbers ? ? ?| ? ? ?+- It seems necessary given the reliance of our testing infrastructure on this representation that you should always be able to load it, thus it seems like it should be part of the previously specified ``RSABackend``:: ? ? RSABackend ? ? ?| ? ? ?+-load_rsa_numbers(rsa_numbers) -> RSAPrivateKey | RSAPublicKey I've chosen to support loading both objects in one method for the symmetry with other deserialization APIs where you do not necessarily know if you have a private or a public key. ?However it seems harder to avoid knowing that you have an RSA key so perhaps this attempt at preserving symmetry is in vain. And much like the above ``PKCS8Key`` proposal it is expected that an ``RSABackend`` will sometimes produce keys which can be turned back into this format (though it is not required as in the case of supporting an HSM.):: ? ? RSANumbersKey ? ? ?| ? ? ?+-rsa_numbers() -> RSAPrivateNumbers | RSAPublicNumbers Though my previous pull request specified too interfaces, I think I am leaning more towards one interface and one method that returns either a public or private representation for symmetry with both the loading API and the other serialization format proposal. I have no spent nearly 6 hours writing this email. ?I hope it either successfully convinces everyone who wishes to be involved or that it is a useful starting point for further conversation. More specifically I hope I have effectively communicated: 1) Why I think backend specific keys are desirable. 2) How I think they should be exposed to the user. 3) How this approach is more consistent with our other interfaces. 4) Why these properties are desirable in our other interfaces and should ? ?be mimiced in our asymmetric interface. 5) That backends are a necessary public api for cryptography to function, ? ?but an implementation detail of cryptography that is not necessary for ? ?useful levels of compatibility with cryptography. -David _______________________________________________ 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 alexs at prol.etari.at Thu May 22 18:44:28 2014 From: alexs at prol.etari.at (alexs) Date: Thu, 22 May 2014 17:44:28 +0100 Subject: [Cryptography-dev] Reducing the impact of Backends on higher level APIs. In-Reply-To: References: Message-ID: First off, thanks for the detailed write up. I broadly agree with this and some of the simplifications you've suggested will be great :) On 22.05.2014 01:04, David Reid wrote: > I would propose instead that operations in our asymmetric interfaces can be > separated into two categories, operations you invoke to get a key (such as > generation or deserialization) and operations that you invoke with a key (such > as acquiring a signature or verification contexts and serialization). > > Further I would suggest that only operations in the first category ever need to > potentially be aware of a backend. Operations performed with a key in contrast > only ever need to know that they have a key. The fact that the key may have > originated from a particular backend does not affect the user (except in that > some algorithms or serialization formats may not be supported by all backends, > and therefor all keys produces by all backends.) > > Ignoring for a moment the representation of keys as python integers, and the > ability to use a key produced by one backend with another, the RSA interfaces > could begin to look like this:: > > RSABackend > | > +-generate_rsa_key(public_exponent, key_size) -> RSAPrivateKey > > RSAPrivateKey > | > +-public_key() -> RSAPublicKey > | > +-signer(padding, algorithm) -> AsymmetricSignatureContext > | > +-decrypt(ciphertext, padding) -> bytes > > RSAPublicKey > | > +-verifier(padding, algorithm) -> AsymmetricVerificationContext > | > +-encrypt(plaintext, padding) -> bytes > > Now you can see that you only need the backend for getting the key, and the > beyond that it is assumed you have a backend specific ``RSAPrivateKey`` provider > that just uses that backend to perform the desired operations. > > Other mechanisms for getting a private key for a specific backend would be > deserialization, which I imagine would be achieved by a specific backend > provider, implementing one of several asymmetric algorithm agnostic backend > interfaces, such as a ``PKCS8Backend`` or the > ``TraditionalOpenSSLSerializationBackend``. > > As for the handling of key serialization I think it is best treated as an > operation you perform with a key, and therefor a method on a particular key > provider communicated via an optional key interface. > > For instance since the OpenSSL backend supports both RSA and PKCS8 it would > produce objects that provide both the ``RSAPrivateKey`` interface, and some > PKCS8 specific interface like:: > > PKCS8Key > | > +-pkcs8_der() -> bytes > | > +-pkcs8_pem(passphrase, algorithm, mode) -> bytes > Another proposal for serialization APIs might be that there are functions for > performing serialization that take keys, and that keys would then need a > standard interface for accessing their raw data (likely as python integers) and > it means that at serialization time you would need access to a backend. Either > for constructing a serializer object, or being passed directly to the function > for serializing the data alongside the key. > > Much more discussion needs to happen about the exact details of any > serialization API, I currently favor the ``PKCS8Key`` API however. Serializations are not quite of the same category as signing or encryption. They are operations which use key material while PKCS#8 etc are transformations of the key material itself. I'd like to suggest another option that takes inspiration from Cipher(). Key | +-serialize(Serialization(*options)) -> bytes This allows more complex serializations to be expressed tidily and doesn't add additional complexity associated with potential cross-backend key sharing that functions might. I'd now like to address the ability to use a key on multiple backends, which was one of the driving factors (in addition to the test vectors) behind our earlier decision to include the python integers that make up the components of an RSA key on our RSA specific interfaces. It is not clear to me that there is actual value in such a feature. So I would like to officially propose that we do not plan > ear future. > > I think I am OK with this. The most obvious limitation it will impose in the short term is that OS X users will have trouble converting a key to OpenSSL format once we get the CC backend going. I am not sure if this a particularly common use-case now that people seem to have realised that SSLeay is no longer a going concern. > > > > I bel ortant to support this representation and that it by treating it as a (de)serialization problem we can solve it relatively easily in the above framework (incidentally this may provide a path towards supporting multi-backend supporting keys but I don't want to focus on that). What is needed to support these is: 1. An in memory representation of the key components. 2. A backend method for loading this representation into a backend specific key. 3. An optional method > end specific key to this representation. > > In a series of pull requests I've started to lay out a migration path towards this > format however the desired end result is somewhat obscured by the method of > preserving compatibility. > > So to lay out what I expect will be the end result: > > An in memory representation:: > > RSAPrivateNumbers > | > +-public_numbers() -> RSAPublicNumbers > | > +- > > RSAPublicNumbers > | > +- > > Why additional interfaces rather than a single numbers() method on the Key classes that raises when the backend can't return the Numbers? We don't have any other parts of the API that gain and lose methods like this. > > It seems necessary given the reliance of our testing infrastructure on this > representation that you should always be able to load it, thus it seems like > it should be part of the previously specified ``RSABackend``:: > > RSABackend ;| +-load_rsa_numbers(rsa_numbers) -> RSAPrivateKey | RSAPublicKey I've chosen to support loading both objects in one method for the symmetry with other deserialization APIs where you do not necessarily know if you have a private or a public key. However it seems harder to avoid knowing that you have an RSA key so perhaps this attempt at preserving symmetry i > dir="ltr"> > > When all the user has is a byte string it is indeed hard to tell what the type of the key is. However if you have something that's implementing RSAPrivateKey, surely it's very easy to tell what the type is going to be? > > Other than those (what I hope are minor) differences in opinion I think this is great template. I'll try and adjust my existing ECC and DH PRs with this in mind. -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Fri May 23 10:11:19 2014 From: glyph at twistedmatrix.com (Glyph) Date: Fri, 23 May 2014 01:11:19 -0700 Subject: [Cryptography-dev] Reducing the impact of Backends on higher level APIs. In-Reply-To: References: Message-ID: On May 21, 2014, at 5:04 PM, David Reid wrote: > In PyCA's Cryptography the backend is the object responsible for providing one > of many lowest common denominator APIs to binding specific interfaces. In case anyone else feels like they need a suitable long-form reading environment to digest this message, I ran it through rest2html and posted it here: . Instapaper-text-ified here: . -glyph -------------- next part -------------- An HTML attachment was scrubbed... URL: