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.
