Software Developer/CryptoSystems/Mathematics Looking for Way to Contribute
MitchMenges
Mathematics. cryptography algorithms, encryption, and would like to
contribute my time and effort to the Sage project. I would like any
of you to get me started in the right direction, any info would be
appreciated. Also what sort of additions to the project are more
common ?
Thank you all for your time and hope to be able to speak with you all
soon. Please feel free to contact me anytime at dmeng...@gmail.com
Mitch Menges
David Harvey
On Mar 20, 2008, at 1:09 PM, MitchMenges wrote:
> I have been developing software and doing research in the areas of:
> Mathematics. cryptography algorithms, encryption, and would like to
> contribute my time and effort to the Sage project. I would like any
> of you to get me started in the right direction, any info would be
> appreciated. Also what sort of additions to the project are more
> common ?
Hi Mitch,
There's a wealth of bugs and feature requests listed here:
http://www.sagemath.org:9002/sage_trac/report/1?sort=ticket&asc=0
or you could just play around with Sage, find out what it can do in
your area, and think of new functionality that you might be
interested in adding, or existing functionality that you might be
interested in improving.
david
Iftikhar Burhanuddin
Dear Mitch,
There are quite a few people affliated to Sage who either research or
teach Crypto.
The first thing to do is browse the source code:
http://www.sagemath.org/hg/sage-main?cmd=manifest;manifest=-1;path=/sage/
and see what's been done and what you think is missing. (And perhaps stick
it into a wiki page.)
Sage's trac is another good place to look. There's been a book written on
Cryptography by David Kohel, which you will find useful.
http://echidna.maths.usyd.edu.au/~kohel/tch/Crypto/index.html
Code whatever inspires you!
Regards,
Ifti
Mitchell Menges
Martin Albrecht
to give you a slightly more detailed answer and some examples. As David and
Ifti said it really depends on what your interests are, what your
mathematical background is and what programming languages you feel
comfortable with (C/C++ or Python). The following list is nowhere near
complete, so I hope nobody is offended if I left his/her favorite area that
needs work in crypto out. This is just the stuff that immediately came to
mind.
* As mentioned earlier, David Kohel's book might be a good start because it
uses Sage. I am under the impression that the code in Sage (the module
sage.crypto) is yet to be completed to it might make sense to look into this
to see what needs to be extended, improved. E.g. block ciphers aren't covered
in sage.crypto.
* Sage ships PyCrypto
http://www.amk.ca/python/code/crypto
which implements many standard cryptographic algorithms. 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
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.
* Finite fields are pretty important for cryptography. Sage uses several
finite field implementations. Someone needs to replace FiniteField_ext_pari
with the two NTL implementations (they are much faster). This should be
relative straight forward and a good way to learn Cython <-> C interaction
etc.
* Last time I checked Sage wasn't exactly kicking ass when it comes to
elliptic and hyperelliptic curves over finite fields. As these are quite
important in asymmetric cryptography it might be worth looking into this. I
guess a large part boils down to wrapping the relevant code in eclib.
* 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
http://trac.sagemath.org/sage_trac/ticket/2114
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 is
no 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.
I hope this list encourages you to look around and find something you'd like
to work on. Feel free to get back with questions etc.
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
John Cremona
> elliptic and hyperelliptic curves over finite fields. As these are quite
That is fair. Apart from an SEA point-counting implementation -- only
over prime fields -- the rest (for elliptic curves) is definitely only
designed to work at sub-crypto field sizes.
> important in asymmetric cryptography it might be worth looking into this. I
> guess a large part boils down to wrapping the relevant code in eclib.
No! eclib is 99.9% about elliptic curves and (certain) modular forms
over the rationals. There is even less in there for curves over
finite fields than in Sage itself (since there is nothing at all for
curves over non-prime fields). Sorry, that's not what I do so it's
not what's in eclib.
John Cremona
>
--
John Cremona
Martin Albrecht
So the challenge is even more interesting :-) Thanks for pointing that out.
Mitchell Menges
Mitch
William Stein
> Thanks Martin for your time composing that previous post, that was exactly
> what I needed, your explaination there has really set the course for what I
> need to start looking at and working on. Tonight I am going familiarize
> myself with Sage more in depth and will keep in mind what you shared with
> me. Just a quick question for you, you stated "which language I felt more
> comfortable with C++ or python." I work with C/C++ and other languages I am
> very comfortable with C++ and its structure, would you suggest I just stick
> to C++ or drop it and pick up Python fully for coding in Sage?
If you want to contribute to Sage it is critical that you become very
fluent in Python. Knowing C/C++ is also very helpful, but Python
is even more important. Read "Dive Into Python" (free online).
http://diveintopython.org/
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Martin Albrecht
This is very true, but your C++ will come in _very_ handy if you want to work
on most of the stuff I posted. Also if you don't mind, take a look at Cython.
This is a Pyrex fork a language to bind Python and C/C++ together or in other
terms: C that looks like Python. We use that to interface with C/C++ code.