SAGE & cryptology

Discussions

• this thread in the ML
• this blog and especially this post
• JSAGE
• notes for developers

Available

• sage.crypto
• Sage ships PyCrypto
  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:

sage: import Crypto.Cipher.IDEA
sage: Crypto.Cipher.IDEA?
   x.__init__(...) initializes x; see x.__class__.__doc__ for signature

• book written on Cryptography by David Kohel, using SAGE
• ? openssl & pyopenssl optional packages

Wishes

• General trac
• sage.crypto: block ciphers
• 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.