Pure Python Salsa20 Stream Cipher Implementation

[betabrain.honshu]

Hi Folks,

for those of you who are familiar with the micropledge.com project,
here is a good opportunity to spend or earn something:
http://micropledge.com/projects/pysalsa20

I know that the details of this project are still a bit unclear, but
that is something we could discuss. By the way, the end result should
look like it's a part of the python standard library (naming
conventions, etc.) and of course it will be open source.

Thanks
Ich

 

[Paul Rubin]

for those of you who are familiar with the micropledge.com project,
here is a good opportunity to spend or earn something:
http://micropledge.com/projects/pysalsa20

I don't understand why a pure python version of salsa20 would be
interesting. Is there some application that uses salsa20, that's
worth being able to interoperate with in pure python?

If you just want a stream cipher in pure python (including its
standard library), the fastest way seems to be able to use the sha
module as a building block:

http://www.nightsong.com/phr/crypto/p3.py

 

[Paul Rubin]

for those of you who are familiar with the micropledge.com project,
here is a good opportunity to spend or earn something:
http://micropledge.com/projects/pysalsa20

By the way, here is a concise implementation of salsa20 in C:

http://www.nightsong.com/phr/crypto/salsa20.c

maybe it could be converted to python more conveniently than
converting the reference implementation.

 

[betabrain.honshu]

I don't understand why a pure python version of salsa20 would be
interesting. Is there some application that uses salsa20, that's
worth being able to interoperate with in pure python?

The reason for a pure python is that it would be independent from the
platform. A C implementation is faster, but you need to compile it for
every platform. A python implementation doesn't have that problem and
could be used to fall back upon.

 

[Gabriel Genellina]

The reason for a pure python is that it would be independent from the
platform. A C implementation is faster, but you need to compile it for
every platform. A python implementation doesn't have that problem and
could be used to fall back upon.

On most platforms -with a notable exception- there is a C compiler
available as a standard tool, which is used to compile Python itself.
distutils can easily compile and install C extensions itself, so most of
the time "python setup.py install" is the only thing users have to
execute, exactly the same as if the package were pure Python. With
setuptools, things may be even easier.

I'm not saying that there is no merit in having a Python implementation,
just that -as Paul Rubin pointed out- the *need* for such thing is not too
high.

 

[Paul Rubin]

The reason for a pure python is that it would be independent from the
platform. A C implementation is faster, but you need to compile it for
every platform. A python implementation doesn't have that problem and
could be used to fall back upon.

But why salsa20 in that case, unless it's approved as a standard? If
you're willing to put up with terrible performance in the fallback
implementation, you may as well use AES, which is a standard. If you
want reasonable performance in the fallback implementation, use
one of the hashlib functions as a cipher.

 

[Paul Rubin]

On most platforms -with a notable exception- there is a C compiler
available as a standard tool, which is used to compile Python itself.

The notable exception that you're thinking of is pervasive, but since
Python is usually distributed as a binary for those systems, there
might as well also be a binary crypto module, and in fact there are
quite a few.

 

[bearophileHUGS]

Gabriel Genellina:

On most platforms -with a notable exception- there is a C compiler
available as a standard tool, which is used to compile Python itself.

For that platform the Python site may offer a version of binary Python
bundled with the MingGW (and Cython too, maybe), like ShedSkin does.

Bye,
bearophile

 

[Aahz]

On most platforms -with a notable exception- there is a C compiler
available as a standard tool, which is used to compile Python itself.
distutils can easily compile and install C extensions itself, so most of
the time "python setup.py install" is the only thing users have to
execute, exactly the same as if the package were pure Python. With
setuptools, things may be even easier.

What about Jython, PyPy, and IronPython?

 

[Gabriel Genellina]

What about Jython, PyPy, and IronPython?

What about them?
Do you mean that there should be a Python implementation for each and
every imaginable module over there, so it can be used with all of those
Python variants? Restricted of course to their minimum common feature set?

 

[ThunderBug]

And FWIW.... there already exists a pySalsa20, a ctypes wrapper for
Bernstein's eSTREAM submission.
http://www.seanet.com/~bugbee/crypto/

 

[Aahz]

What about them?
Do you mean that there should be a Python implementation for each and
every imaginable module over there, so it can be used with all of those
Python variants? Restricted of course to their minimum common feature set?

<shrug> Is there some reason you're using exaggerated language? My only
point is that simply saying "C compiler! C compiler!" ignores the fact
that Python itself is multi-platform (and makes you look foolish);
whether any given module should be written in pure Python needs to be
decided on a case-by-case basis.

 

[Paul Rubin]

<shrug> Is there some reason you're using exaggerated language? My only
point is that simply saying "C compiler! C compiler!" ignores the fact
that Python itself is multi-platform (and makes you look foolish);
whether any given module should be written in pure Python needs to be
decided on a case-by-case basis.

Certainly one of salsa20's main design features is that it's supposed
to be faster than AES-CTR. Therefore any implementation other than a
native C implementation is basically a compatibility fallback.
However, it's likely that there's already a JNI wrapper for it that
should(?) make it useable with jython. I don't know the .net
situation but I'd hope it's similar. And someone says there's already
a ctypes wrapper.

Overall, though, I just don't see a need for this, it's far more
important to have AES and DES available since those are standard
crypto algorithms, even if pure python implementations are inherently
slow. If something nonstandard is desired for speed, SHA-OFB seems
to work pretty well.

 

[Aahz]

Certainly one of salsa20's main design features is that it's supposed
to be faster than AES-CTR. Therefore any implementation other than a
native C implementation is basically a compatibility fallback.

....or a teaching tool, because code is easier to read in Python.

 

[Gabriel Genellina]

<shrug> Is there some reason you're using exaggerated language? My only
point is that simply saying "C compiler! C compiler!" ignores the fact
that Python itself is multi-platform (and makes you look foolish);
whether any given module should be written in pure Python needs to be
decided on a case-by-case basis.

And that's exactly what I said, I don't see the need for a pure Python
implementation of salsa20 based solely on "you need to compile [the C
source] on every platform" (cf. quoted text above). That's all, and I
don't want to argue with you or anyone about this.