Because: (1) The rest of Zeus is written in Python. (2) Writing in Python while pushing computations in C/C++ is a well accepted idiom. (3) Premature optimisation is the root of all evil. As I mentioned, the atomic cryptographic operations are already in C/C++. However they are not vectorised, and there may be room for improvement in their implementations. πλ > On 20 Mar 2017, at 23:19, John Tsioris <jtsioris [ at ] gmail [ dot ] com> wrote: > > I see your point, but I don't get why Python was selected at the first place. Is there any specific reason, e.g. it facilitates the communication with other parts of the project? Ina addition, is it viable and profitable that the computation-specific modules be rewritten in C/C++? > > 2017-03-20 22:43 GMT+02:00 Panos Louridas <louridas [ at ] grnet [ dot ] gr>: > The crypto stuff is already carried out in C/C++ (check the imported libraries), as are most crypto projects in Python, otherwise it would take ages. > > However, binding with C using Cython does, although it does speed up individual computations, may not have the expected effect because stuff is translated between Python and C between calls. Ideally, one would expect to have vectorised C operations, so that, for instance, a sum of products is computed in C in one go and then the result sent back to Python. Also, in terms of exponentiations, there are considerable improvements that can be implemented (like sliding window etc.). > > So, making a fast C/Python crypto operation is an interesting, non-trivial problem. > > πλ > > > On 20 Mar 2017, at 00:04, John Tsioris <jtsioris [ at ] gmail [ dot ] com> wrote: > > > > One more question, I see that the implementation you posted (https://github.com/grnet/ac16) is in Python. Since computational time is of the essence, should I assume that the above implementation may be ported to another language (C/C++ perhaps)? Or would that be incompatible with the overall system? > > > > 2017-03-19 23:13 GMT+02:00 Panos Louridas <louridas [ at ] grnet [ dot ] gr>: > > > > > On 19 Mar 2017, at 20:53, John Tsioris <jtsioris [ at ] gmail [ dot ] com> wrote: > > > > > > > > > ---------- Forwarded message ---------- > > > From: John Tsioris <jtsioris [ at ] gmail [ dot ] com> > > > Date: 2017-03-19 15:28 GMT+02:00 > > > Subject: Re: [opensource-devs] GSOC 2017 - Zeus Project > > > To: Panos Louridas <louridas [ at ] grnet [ dot ] gr> > > > > > > > > > Hello again, > > > and thank you for your previous reply. > > > In the wiki section about the mixnet implementations in Zeus, it says: "Therefore we seek to implement or enhance or test different mixnets in order to replace the current mixnet algorithm in Zeus". > > > Could you describe in greater detail the drawbacks of the current mixnet algorithm (I assume it lacks efficiency)? > > > > Exactly. It’s the Sako-Kilian mixnet. It’s fine, but it’s slow. > > > > > Moreover, what alternative implementations do you have in mind? > > > > If you search in the literature you will see that there are many, but unfortunately most of them are covered by patents. > > > > We are implementing a new generation of mixnets that are open and free to use. See for example: > > > > https://github.com/grnet/ac16 > > > > which implements: > > > > https://eprint.iacr.org/2016/866.pdf > > > > This of course can be part of your proposal: a mixnet in the literature that is open so that we can use them and you can implement it. > > > > πλ > > > > > >
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Γενική λίστα αλληλογραφίας που απευθύνεται σε developers/contributors έργων ανοικτού λογισμικού - A general discussion list for developers/contributors of open-source projects, https://lists.ellak.gr/opensource-devs/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <opensource-devs+unsubscribe [ at ] ellak [ dot ] gr>.