Hi Friedrich I totally agree with 1) and 2): that kind of implementations would be very appropriate and valuable to have in Sage. Concerning 3), I would initially think that doc-tests could be sufficient.
I was loosely involved in some discussions on implementing the McEliece public-key crypto-system #21352 (https://trac.sagemath.org/ticket/21352) which has since stalled since the author left it. From there I remember that we noticed some crufty-ness to the code in sage/crypto. For instance, though there is a base-class Cipher, it doesn't have abstract methods for encrypting and decrypting; as a result, it seems that different words has been used for this all over (at least "enciphering", "encode", "encrypt"). The existing PublicKeyCipher in sage/crypto/cipher.py is also sort of weird: e.g. it inherits key() from Cipher, but in the only current implementation - Blum-Goldwasser class - there is instead public_key() and private_key(). Perhaps some cleanup and redesign is appropriate here. I really don't know about 4). If researchers and teachers find that they can use a modular, high-level implementation of certain protocols, then why not? But as with the ciphers themselves, the aim shouldn't be a competitive, highly optimised implementation, I think, but rather something that eases understanding and experimentation. Best, Johan Friedrich Wiemer writes: > Today I stumbled across https://trac.sagemath.org/ticket/11565 in where the > design of the crypto module is briefly discussed ... > > 1) While RSA might be not the best cipher to point out the following, this > certainly holds for block ciphers or other crypto primitives. During my > research work I often implement some cipher scheme in python from scratch, > because I want to tinker with it, maybe exchange some parts of it, etc. > Having these things in sage with a highly modularized design would really > ease this kind of work. > > 2) Having all the heavy mathematic stuff in sage, we can easily provide > implementations of, say, AES that are in fact their mathematical > descriptions. I think Rusydi H. Makarim already started working on this. In > my opinion, this has at least two advantages: First it is a great > educational tool for students to see, how this math "works in real" and > helps them in getting a better understanding whats actually going on. > Second it would allow to have a collection of reference implementations, > which (because of the above modularized approach) allow to easily generate > also intermediate test vectors. For me, this last point is really a big > plus, because often you only get "coarse-grained" testvectors from cipher > specifications like input/output of the whole encryption (sometimes also > intermediate results after a single round or so) - but I have never seen a > specification, which also provides intermediate results after the inner > parts of a round function or so. If you want to implement some optimized > version, you might be very happy, to have such test possibilities at hand. > > 3) So, from the end of point 2: It would also be nice, to have a lot of > test vectors for crypto schemes - maybe its already enough to have these in > the doctests, at least this would be a nice starting point. > > 4) This last point is somewhat of an abstraction above point 2, combined > with 1. Going a level up, to the crypto-protocol level, it would be quite > easy to implement protocols like TLS when all the basic crypto stuff is > readily available. I was told that there is no free TLS implementation in > python available, where you are actually able to exchange parts of the > protocol (this again might be interesting if you are doing research on such > a protocol). Regarding this point, I'm not sure if sage is the right place > to have such a protocol level implementation, because its main aim seem to > be a mathematical CAS. > > What are your opinions regarding this? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
