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.

The ideal toolbox

This is a lengthy list but it's our Xmas list ;-)

Block ciphers

Block cipher algorithms

Make sure the internals are accessible and reconfigurable, particularly the S-BOXes.
Try to make generic constructors such as Feistel cipher, etc

• Serpent
• Twofish
• Idea
• DES, 3DES 112, 168
• AES 128, 196, 256
• Present

Modes of operation

Make sure we can select independently the block cipher encryption/decryption mode and the chaining "encryption/decryption" mode

• Authentication modes
  • CMAC
  • XCBC
  • CBC-MAC
• Authentication+encryption modes
  • CCM
  • GCM
• Encryption modes
  • ECB
  • CBC
  • CTR
• Disk encryption modes
  • LRW
  • XTS

Non-keyed hashes

• MDC-2 (ISO 10118-2)

Paddings

• Bit padding (can be done at bit level, others are at byte level)

DD DD DD 80 00 00 00 00

• zeros

DD DD DD 00 00 00 00 00

• PKCS7

DD DD DD 05 05 05 05 05

• ISO 10126

DD DD DD 42 DB 8A 98 05

• ANSI X.923

DD DD DD 00 00 00 00 05

Stream ciphers

Same thing, get the internals accessible and patchable

• RC4
• A5/1 A5/2
• SNOW2 SNOW3G
• SW candidates of eSTREAM:
  • HC-128
  • RABBIT
  • Salsa 20/12
  • SOSEMANUK
• HW candidates of eSTREAM:
  • F-FCSR
  • Grain
  • MICKEY
  • Trivium