rotor replacement

[Robin Becker]

Re: rotor replacement

Peter Maas wrote:[color=blue]
> Paul Rubin schrieb:
>[color=green][color=darkred]
>>> Wasn't there a default 40-bit version that was ok (weak), but you had
>>> to declare yourself US resident to download 128-bit support?[/color]
>>
>>
>>
>> That was years ago. The regulations changed since then, so they all
>> have 128 bits now.[/color]
>
>
> Perhaps the NSA has found a way to handle 128bit in the meantime.
> But this is unlikely because there is no export regulation to ban
> 512bit as far as I know :)
>[/color]

Apparently factorization based crypto is on the way out anyhow (as an
article in Scientific American is reported to claim).

http://www.sciam.com/article.cfm?chanID=sa006&articleID=000479CD-F58C-11BE-AD0683414B7F0000&ref=rdf

-can't wait to get my quantum computer-ly yrs-
Robin Becker

[Paul Rubin]

Re: rotor replacement

Robin Becker <robin@SPAMREMO VEjessikat.fsne t.co.uk> writes:[color=blue]
> Apparently factorization based crypto is on the way out anyhow (as an
> article in Scientific American is reported to claim).[/color]

I haven't seen that SA article but I saw the Slashdot blurb. They
have confused "quantum cryptography" with quantum computation, when
they are entirely different things. Quantum cryptography (basically
communicating a message over an optical fiber in such a way that any
attempt to eavesdrop is supposed destroy the readability of the
message) has been done over quite long distances, 10's of km or even
more. Quantum computation is mostly a theoretical speculation. The
largest quantum computer ever built held seven bits, and factored the
number 15 into its factors 3 and 5. Building larger ones seems to
have complexity exponential in the number of bits, which is not too
much better than using an exponential-time algorithm on a conventional
computer. It's not even known in theory whether quantum computing is
possible on a significant scale. There are just some theorems about
what properties such a computer would have, if it can exist. One of
them, however, is being able to factor in P-time, and that caused
lots of excitement.

[Martin v. Löwis]

Re: rotor replacement

Paul Rubin wrote:[color=blue]
> Some countries have laws about cryptography software (against some
> combination of export, import, or use). The Python maintainers didn't
> want to deal with imagined legal hassles that might develop from
> including good crypto functions in the distribution. Then it became
> obvious that the same imagined hassles could also befall the rotor
> module, so that was removed.[/color]

Do you know this for a fact? The PSF does comply with the U.S. American
export procedures for crypto code, and reports the crypto code in
Python appropriately to BXA.

Regards,
Martin

[phr@localhost.localdomain]

Re: rotor replacement

"Martin v. Löwis" <martin@v.loewi s.de> writes:[color=blue][color=green]
> > Some countries have laws about cryptography software (against some
> > combination of export, import, or use). The Python maintainers didn't
> > want to deal with imagined legal hassles that might develop from
> > including good crypto functions in the distribution. Then it became
> > obvious that the same imagined hassles could also befall the rotor
> > module, so that was removed.[/color]
>
> Do you know this for a fact?[/color]

I'm going by newsgroup messages from around the time that I was
proposing to put together a standard block cipher module for Python.
[color=blue]
> The PSF does comply with the U.S. American export procedures for
> crypto code, and reports the crypto code in Python appropriately to BXA.[/color]

Since rotor was removed, there is no crypto code in Python that needs
reporting.

[Martin v. Löwis]

Re: rotor replacement

phr@localhost.l ocaldomain wrote:[color=blue][color=green]
>>Do you know this for a fact?[/color]
>
>
> I'm going by newsgroup messages from around the time that I was
> proposing to put together a standard block cipher module for Python.[/color]

Ah, newsgroup messages. Anybody could respond, whether they have insight
or not.
[color=blue][color=green]
>>The PSF does comply with the U.S. American export procedures for
>>crypto code, and reports the crypto code in Python appropriately to BXA.[/color]
>
>
> Since rotor was removed, there is no crypto code in Python that needs
> reporting.[/color]

We have released different versions of Python in the past. For Python
2.2, a report about the rotor module was sent to BXA.

Regards,
Martin

[JanC]

Re: rotor replacement

Robin Becker schreef:
[color=blue]
> well since rotor is a german (1930's) invention[/color]

And AES is a Belgian invention... ;-)
[color=blue]
> it is a bit late for
> Amricans (Hollywood notwithstanding ) to be worried about its export[/color]


--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Paul Rubin]

Re: rotor replacement

"Martin v. Löwis" <martin@v.loewi s.de> writes:[color=blue][color=green]
> > I'm going by newsgroup messages from around the time that I was
> > proposing to put together a standard block cipher module for Python.[/color]
>
> Ah, newsgroup messages. Anybody could respond, whether they have insight
> or not.[/color]


Here's the message I had in mind:

http://groups-beta.google.com/group/comp.lang.python/msg/adfbec9f4d7300cc

It came from someone who follows Python crypto issues as closely as
anyone, and refers to a consensus on python-dev. I'm not on python-dev
myself but I feel that the author of that message is credible and is
not just "anyone".

[Nick Craig-Wood]

Re: rotor replacement

Paul Rubin <http> wrote:[color=blue]
> Here's the message I had in mind:
>
> http://groups-beta.google.com/group/...fbec9f4d7300cc
>
> It came from someone who follows Python crypto issues as closely as
> anyone, and refers to a consensus on python-dev. I'm not on python-dev
> myself but I feel that the author of that message is credible and is
> not just "anyone".[/color]

And here is the relevant part...

"A.M. Kuchling" wrote:[color=blue]
> On Fri, 27 Feb 2004 11:01:08 -0800 Trevor Perrin wrote:[color=green]
> > Are you and Paul still looking at adding ciphers to stdlib? That would
> > make me really, really happy :-)....[/color]
>
> No, unfortunately; the python-dev consensus was that encryption raised
> export control issues, and the existing rotor module is now on its way to
> being removed.[/color]

I'm sure thats wrong now-a-days. Here are some examples of open
source software with strong crypto

Linux kernel: http://www.kernel.org/
GNU crypto project: http://www.gnu.org/software/gnu-crypto/
TryCrypt: http://truecrypt.sourceforge.net/
OpenSSL: http://www.openssl.org/
AEScrypt: http://aescrypt.sourceforge.net/
<lots more here!>

Note that some of these are being worked on at sourceforge just like
python.

Surely it must be possible to add a few simple crypto modules to
python?

That said
a) IANAL
b) 'apt-get install python-crypto' works for me ;-)

--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

[Paul Rubin]

Re: rotor replacement

Nick Craig-Wood <nick@craig-wood.com> writes:[color=blue][color=green]
> > No, unfortunately; the python-dev consensus was that encryption raised
> > export control issues, and the existing rotor module is now on its way to
> > being removed.[/color]
>
> I'm sure thats wrong now-a-days. Here are some examples of open
> source software with strong crypto[/color]

There's tons of such examples, but python-dev apparently reached
consensus that the Python maintainers were less willing than the
maintainers of those other packages to deal with those issues.

You're right that this specifically says export control. I'm now
thinking I saw some other messages, again from knowledgeable posters,
saying that there was a bigger concern that including crypto in the
distribution could make trouble for users in countries where having
crypto at all was restricted. I'll see if I can find those.

Martin, do you know more about this? I remember being disappointed
about the decisions since I had done some work on a new block cipher
API and I had wanted to submit an implementation to the distro. But
when I heard there was no hope of including it, I stopped working on
it. If there's an interest in it again, I can do some more with it.

[A.M. Kuchling]

Re: rotor replacement

On 22 Jan 2005 04:50:30 -0800,
Paul Rubin <http> wrote:[color=blue]
> Martin, do you know more about this? I remember being disappointed
> about the decisions since I had done some work on a new block cipher[/color]

It was discussed in this thread:

http://mail.python.org/pipermail/python-dev/2003-April/034959.html

Guido and M.-A. Lemburg were leaning against including crypto; everyone else
was positive. But Guido's the BDFL, so I interpreted his vote as being the
critical one.

--amk

[Fredrik Lundh]

Re: rotor replacement

Paul Rubin wrote:
[color=blue]
> Martin, do you know more about this? I remember being disappointed
> about the decisions since I had done some work on a new block cipher
> API and I had wanted to submit an implementation to the distro. But
> when I heard there was no hope of including it, I stopped working on
> it.[/color]

"I'll only work on stuff if I'm sure it's going right into the core" isn't exactly
a great way to develop good Python software. I recommend the "would
anyone except me have any use for this?" approach.

</F>

[Paul Rubin]

Re: rotor replacement

"Fredrik Lundh" <fredrik@python ware.com> writes:[color=blue]
> "I'll only work on stuff if I'm sure it's going right into the core"
> isn't exactly a great way to develop good Python software. I
> recommend the "would anyone except me have any use for this?"
> approach.[/color]

1. Crypto is an important "battery" for many security applications.
As a crypto activist I like to spread crypto, and I therefore think it
would be useful if crypto were in the core. That is the reason I was
willing to do the work of writing a suitable module. To have it go
into the core and further my goal of spreading crypto. That's as good
a reason as any to write a crypto module.

2. "Would anyone except me have any use for this?" shows a lack of
understanding of how Python is used. Some users (call them
"applicatio n users" or AU's) use Python to run Python applications for
whatever purpose. Some other users (call them "developers ") use
Python to develop applications that are intended to be run by AU's.

Now we're talking about an extension module written in C. There is no
way to write AES for Python any other way and still have reasonable
perfomance.

Modules written in C and distributed separately from the core are a
pain in the neck to download and install. You need compilers, which
not everyone has access to. AU's often use Windows, which doesn't
come with any compilers, so many AU's have no compilers. Developers
generally have access to compilers for the platforms they develop on,
but usually won't have compilers for every target platform that every
AU in their audience might want to run their app on. Even AU's with
compilers need to be able to install extension modules before they can
run them, which isn't always possible, for example if they're using
Python at a web hosting service.

What I'm getting at here is that C modules are considerably more
useful to AU's if they're in the core than if they're outside it, and
the effect is even larger for developers. For developers, extension
modules are practically useless unless they're in the core. Depending
on extension modules that have to be installed by the AU severely
limits the audience for the developer's app.

The module we're discussing was intended for developers. "Would
anyone except me have any use for this, [even if it doesn't go in the
core]?" is a bizarre question. The whole purpose of the module was to
let developers ship Python crypto apps that don't making the AU load
external C modules. If it's not in the core, it doesn't meet its
usefulness criterion. Your proposed question amounts to asking "is
this worth doing even if its usefulness is severely limited?". I
aleady asked myself that question and the answer was no. I was only
interested in the higher-usefulness case, which means putting the
module in the core. I don't see anything unreasonable about that. I
can only work on a limited number of things, so I pick the most useful
ones.

[Paul Rubin]

Re: rotor replacement

"A.M. Kuchling" <amk@amk.ca> writes:[color=blue]
> It was discussed in this thread:
> http://mail.python.org/pipermail/pyt...il/034959.html
>
> Guido and M.-A. Lemburg were leaning against including crypto; everyone else
> was positive. But Guido's the BDFL, so I interpreted his vote as being the
> critical one.[/color]

That's interesting, so it's an export issue after all. But export
from the US is handled by sending an email to the DOC, and Martin
mentions that's already been done for some Python modules. I had been
under the impression was that the concern was over causing possible
problems for users in some destination countries, and possibly having
to maintain separate distros for the sake of users like that. But
maybe I was wrong about that.

[Fredrik Lundh]

Re: rotor replacement

Paul Rubin wrote:
[color=blue]
> 2. "Would anyone except me have any use for this?" shows a lack of
> understanding of how Python is used. Some users (call them
> "applicatio n users" or AU's) use Python to run Python applications for
> whatever purpose. Some other users (call them "developers ") use
> Python to develop applications that are intended to be run by AU's.[/color]

"lack of understanding of how Python is used"

wonderful. I'm going to make a poster of your post, and put it on my
office wall.

</F>

[Martin v. Löwis]

Re: rotor replacement

Paul Rubin wrote:[color=blue]
> There's tons of such examples, but python-dev apparently reached
> consensus that the Python maintainers were less willing than the
> maintainers of those other packages to deal with those issues.[/color]

As Andrew says, it is not apparent that there was consensus.
[color=blue]
> Martin, do you know more about this?[/color]

I'm pretty certain that we (the PSF) sent a message to BXA, reporting
the rotor module. While I can't find out exactly when this happened
right now, the board meeting on 2002-04-09 decided that this should
happen, see

http://python.org/psf/records/board/minutes-2002-04-09.html

Regards,
Martin