Important Notice: this service will be discontinued by the end of 2024 because for multiple years now, Plume is no longer under active/continuous development. Sadly each time there was hope, active development came to a stop again. Please consider using our Writefreely instance instead.

Ctypescrypto

About my ctypescrypto project.

About 5 years ago I need to use some cryptographic functions in the one project I was paid for. Being an author of loadble OpenSSL module (engine) implementing Russian GOST cryptography standards, I, of course want to use OpenSSL.

But I’ve found out that most python interfaces to OpenSSL such as m2crypto and pyopenssl are not flexible enough to support new algorithms loaded with engine.

Authors of most interfaces think that there is hard-coded list of crypto algorithms which they can hardcode into their python modules too. If is not true for OpenSSL, where algorithms can be implemented as loadable modules.

Then I’ve found somebody’s unfinished work on code.google.com and find out that standard Python library includes ctypes module which allows to do almost everything with shared library whithoutt compiled C wrappers.

So, I decide to use this approach. and created my ctypescrypto library.

Being a long-time OpenSSL user and even contributor, I know that design of libcrypto is almost object-orientned, as it can be expressed on plain C. So I’ve designed object model for ctypescrypto with such objects ax X509Cert, CMSmessage etc.

There are such things as BIO (The Basic-Input-Output) and OID objects, which are used by OpenSSL for internal purposes. They’ve to be implemented to, as it is required to properly manipulate with certificates and keys.

My main concern was to implement proper handling of standard data formats - X509 and CMS because it is things which developers of the various scripting language extensions typically forget about. They use certificate as blob and don’t care much about displaying its information, often using the outdated ASCII only API.

But I, living in Russia, needed not only GOST algorithms, but also cyrillic letters in the certification subjects, specific extensions, mandated by Russian standard and so on. It is all supported by OpenSSL itself. But it is not enough to support these things inside library, you also have to have proper interfaces to it.

I wouldn’t tell that I’ve completed this job. But at least my module allows to examine the certificate subject and extensions, extract the signer info from the CMS message and verify signature using the OpenSSL trusted certificate store.

Unfortunatly, then came the end of life of the Python 2. And Python 3 introduced the distinction between character strings and byte strings. While this distinction is mostly good thing for alll who use non-Latin alphabets, for cryptographers it requires great care implementing support of both.

Typically user doesn’t care whether one feeds text or some binary data, such as Office document or image into the cryptographic tool. One just wants to encrypt or sign anything one want to send out.

And if passphrase is used to protect some information, user want to just tiype it in the whatever language it is, and don’t care about byte representation. But sending and receiving ends of communication have to agree on exact byte representation of both signed text and passphrases.

Now, following things are unfinished in the ctypescrypto:

  1. Test coverage (cms module is not covered at all)
  2. Python3 support - transparently handle string and bytes whereever both of them make sense when writing and let user request neccessary represention when reading.
  3. Certificate request handling. I think that there should be enoudh API to construct certificate request field by field and to manage typical CA task copying fields from request into certificate and adding neccesary ones.
  4. CRL handling

I ’m not sure whether this library needs builtin support for the OCSP protocol and downloading CA certificates by Authority Info Access extension.