Docs

General Remarks

When using Python code in Sage

Sage uses an internal integer representation (sage.rings.integer.Integer) which differs with the int representation of Python and which can lead to errors in some circumstances.=> cast sage integers to python integers before supplying them to a Python function in Sage

one example: '1/2' in Python = 0, of type int (for now, it's foreseen to make it a real div, cf __future__ module, will be =0.5 of type float) but '1/2' in Sage = 1/2, of type sage.rings.rational.Rational , to solve it, either cast to int() or use operator // instead of / in Python

TODO

check licensing of different packages and compare them to requirements for sage

PyCrypto:

I've filed a bug in PyCrypto's bug tracker: https://bugs.launchpad.net/pycrypto/+bug/260130
The PyCrypto licensing status is a bit of a mess. It looks like a bunch of reference implementations were simply copied-and-pasted into the source tree, and each has its own licensing statement.
I recommend looking at each source file and making a judgment for yourself.
I'm slowly working on a new release of PyCrypto (I've just taken over from Andrew Kuchling). In the next release, I'll try to document things better, and fix the most obvious problems (I've already written a replacement for RIPEMD.c).
However, some of the software is unattributed. I assume that most of it was written by A.M. Kuchling, but I can't be totally sure. I'll try to contact Andrew and see if he can clear things up.
- Dwayne

analyse structure of integers and strings and see if the representation from sage is compatible with the one from python

Integers:Integers in Sage are a different type than the Python integers. Problems can occur when executing standard python code in Sage. To avoid problems: add 'r' after a number to let it be interpreted as a Python integer.More info:Google Groups: [1][2]Sage Tutorial on differences caused by the Sage preparser: [3]

Strings:Strings in Sage are the same type as Python strings

analyse the format of objects used by different libraries and see if they are compatible

Almost all libraries used "binary strings" as input/output with some exceptions:

TODO for Phil

make some speed tests with psyco, claiming to run python code up to 5x faster but:Psyco does not support the 64-bit x86 architecture, unless you have a Python compiled in 32-bit compatibility mode. There are no plans to port Psyco to 64-bit architectures. This would be rather involved. Psyco is only being maintained, not further developed. The development efforts of the author are now focused on PyPy, which includes Psyco-like techniques.

PyCrypto, the Python Cryptography Toolkit

Sage ships PyCrypto (new maintainer's page?) which implements many standard cryptographic algorithms. It is not really meant for research/education/playing around but for production code but maybe something could be done to have easier access to it from within Sage. The docstring level documentation is horrible:

All hash functions support the API described by PEP 247: after importing a given hashing module, call the new() function to create a new hashing object. You can now feed arbitrary strings into the object with the update() method, and can ask for the hash value at any time by calling the digest() or hexdigest() methods. The new() function can also be passed an optional string parameter that will be immediately hashed into the object's state.[7] Using the argument digest_size you can get the digest size but its constant.

Possibilities: Define a new cipher object after importing the module and define the key, mode (cbc,cfb,ecb or pgp) and possible IV.The object gives you two methods: 'encrypt()' and 'decrypt()'.For AES: S-Box not modifiable, LookUp Tables are being used.

Crypto.Util.randpool[9]The randpool module implements a strong random number generator in the RandomPool class. The internal state consists of a string of random data, which is returned as callers request it. The class keeps track of the number of bits of entropy left, and provides a function to add new random data; this data can be obtained in various ways, such as by using the variance in a user's keystroke timings.

PyOpenSSL

Looks like less functionality than PyCrypto => PyCrypto seems like a better candidate to adjust, else we would have to extend the PyOpenSSL wrapper AND OpenSSL itself for any wanted extended functionality.

Remarks

Bug

When calling the key generation function "rsa = tlslite.utils.keyfactory.generateRSAKey(384,["python"])" it will throw an error. The TLS Lite code will also break in future versions of python (more info on the SourceForge link)
Solutions:

add an "r" to the number to cast it to a python Integer instead of a Sage integer.=> rsa = tlslite.utils.keyfactory.generateRSAKey(384r,["python"])

CryptoPy: has some code to analyze SBox AES Sbox Analysis - a simple analysis of the AES Sbox that determines the number and size of the permutation subgroups in the transformation. Could be extended to examine any Sbox ...

EncryptData(key, data): Encrypts data using key and returns encrypted string. Uses 256 bit Rijndael cipher. Key is built from first 32 characters of password. A 32-bit message length is attached to beginning of ciphertext.

Python-mcrypt python-mcrypt is a comprehensive Python interface to the mcrypt library, which is a library providing a uniform interface to several symmetric encryption algorithms. It is intended to have a simple interface to access encryption algorithms in ofb, cbc, cfb, ecb and stream modes. The algorithms it supports are DES, 3DES, RIJNDAEL, Twofish, IDEA, GOST, CAST-256, ARCFOUR, SERPENT, SAFER+, and more.

Wishes

Someone needs to replace FiniteField_ext_pari with the two NTL implementations (they are much faster).

elliptic and hyperelliptic curves over finite fields support is rather poor

algebraic aspects received some attention for the cryptanalysis of symmetric cryptographic algorithms, i.e. the cryptanalyst expresses the cipher as a large set of multivariate polynomials and attempts to solve the system. The most common case over GF(2) is handled by PolyBoRi. This library is the backbone of BooleanPolynomialRing and friends. This class needs testing, documentation, extension and bugfixes. Basically someone should sit down and add all the methods of MPolynomial[Ring]_libsingular to BooleanPolynomial[Ring] which make sense, add a ton of doctests and test the hell out of the library to make sure no SIGSEGVs surprise the user.

the module sage.crypto.mq is also relevant for the above.

Univariate polynomials over GF(2) are still implemented via NTL's ZZ_pX class rather than GF2X. This should be changed. Also this ticket has a link to gf2x a very small drop in replacement C library which claimed to be 5x faster than NTL. Though, a formal vote is needed to get it into Sage.

At the end of the day everything boils down to linear algebra. So if you improve that, everybody wins. Sparse linear algebra mod p is still too slow (Ralf-Phillip Weinmann did some work here wrapping code from eclib), there isn o special implementation for sparse linear algebra over GF(2) (both blackbox and e.g. reduced echelon forms), dense LA over GF(2) needs Strassen multiplication/reduction, dense LA over GF(2^n) should probably get implemented.