J
JanC
Robin Becker schreef:
And AES is a Belgian invention... ;-)
And AES is a Belgian invention... ;-)
P
Paul Rubin
Martin v. Löwis said:
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".
N
Nick Craig-Wood
Paul Rubin said:
And here is the relevant part...
A.M. Kuchling said:
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 ;-)
P
Paul Rubin
Nick Craig-Wood said:
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
A.M. Kuchling
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
F
Fredrik Lundh
Paul said:
"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>
P
Paul Rubin
Fredrik Lundh said:
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
"application 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.
P
Paul Rubin
A.M. Kuchling said:
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.
F
Fredrik Lundh
Paul said:
"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>
P
Paul Rubin
Fredrik Lundh said:
Excellent. I hope you will re-read it several times a day. Doing
that might improve your attitude.
F
Fredrik Lundh
Paul said:
you really don't have a fucking clue about anything, do you?
</F>
P
Paul Rubin
Fredrik Lundh said:
You're not making any bloody sense. I explained to you why I wasn't
interested in writing that particular piece of code unless it was
going in the core. That was in response to your suggestion that I
write the code without regard to whether it was going in the core or
not.
If you didn't understand the explanation, I suggest you read it again,
perhaps by putting it on your wall like you said. If you have any
questions after that, feel free to post them.
J
John J. Lee
Paul Rubin said:
Discuss. <wink>
(I don't mean I'm requesting a discussion -- it just reads like a
physics / philosophy exam essay question, which traditionally end with
that word
John
P
Paul Rubin
The way I understand it, that 7-qubit computer was based on embedding
the qubits on atoms in a large molecule, then running the computation
procedure on a bulk solution containing zillions of the molecules,
then shooting RF pulses through the solution and using an NMR
spectrometer to find a peak at the most likely quantum state (i.e. the
state which had the most of the molecules in that state). To do it
with 8 qubits instead of 7, you'd have to use twice as much solution,
so that particular technique doesn't scale. What we want is a way to
calculations on single molecules, not bulk solutions. But no one so
far has managed to do even 7 qubits that way.
The problem is maintaining enough coherence through the whole
calculation that the results aren't turned into garbage. In any
physically realizeable experiment, a certain amount of decoherence
will creep in at every step. So you need to add additional qubits for
error correction, but then those qubits complicate the calculation and
add more decoherence, so you need even more error correcting qubits.
So the error correction removes some of your previous decoherence
trouble but adds some of its own.
As I understand it, whether there's a quantum error correcting scheme
that removes decoherence faster than it adds it as the calculation
gets larger, is an open problem in quantum computing theory.
I'm not any kind of expert in this stuff but have had some
conversations with people who are into it, and the above is what they
told me, as of a few years ago. I probably have it all somewhat garbled.
P
Paul Rubin
A.M. Kuchling said:
Rubin wanted to come up with a nice interface for the module, and
has posted some notes toward it. I have an existing implementation
that's 2212 lines of code; I like the interface, but opinions may
vary.
Does that mean you have a 2212-line C implementation of the interface
that I proposed? Do you plan to release it?
BTW, I just looked at the other messages in that thread and I realize
that I've looked at them before, and that's where I saw the concern
about importing crypto into some countries including Holland. Again,
I think the reasoning is bizarre. I'm sure there are tons of Firefox
users in Holland, and Firefox definitely contains an SSL stack that
doesn't have to be downloaded separately.
F
Fredrik Lundh
Paul said:
oh, I make perfect sense, and I think most people here understand why
I found your little "lecture" so funny. if you still don't get it, maybe some-
one can explain it to you.
</F>
P
Paul Rubin
Fredrik Lundh said:
I would appreciate it if someone did.
B
Brian van den Broek
Paul Rubin said unto the world upon 2005-01-22 20:16:
Hi,
no Python expert, just a hobbyist. But, I think I can take this one on:
Fredrik's contributed a lot to Python. The Standard Library book,
several well know tools, and, I'd wager a finger, a fair bit of code
in the standard lib. I don't think the community gives you a name like
F-bot, but that you know a wee bit about how Python is actually used,
etc.
Best,
Brian vdB
Hi,
no Python expert, just a hobbyist. But, I think I can take this one on:
Fredrik's contributed a lot to Python. The Standard Library book,
several well know tools, and, I'd wager a finger, a fair bit of code
in the standard lib. I don't think the community gives you a name like
F-bot, but that you know a wee bit about how Python is actually used,
etc.
Best,
Brian vdB
P
Paul Rubin
Brian van den Broek said:
If he understood how Python is actually used, he'd understand that any
C module is a lot more useful in the core than out of it.
His lecture to me about the crypto module was bizarre and
inappropriate. The whole purpose of that module was to fix a
deficiency of Python, namely the lack of a good crypto module in the
core, that people could use without having to install any downloaded C
modules. If it doesn't go into the core, the deficiency isn't fixed,
so the module has failed in its purpose. There are already tons of
3rd party crypto modules outside the core, and the module I was
writing wouldn't add anything useful to those. It only provided
AES/DES and the basic FIPS modes, and was designed specifically to be
suitable for the core where the other modules were considered too
fancy. Also, Guido had expressed interest in having it, before
changing heart because of the legal stuff. Where does Frederik get
off lecturing me about wanting to get a module into the core, when
Guido had invited me to do precisely that with that very module?
Frederik has written some pretty good C modules himself, that are a
pain in the neck to use because they're not in the core, which means
that before they can be used they first have to be compiled and
installed. If he wanted to maximize their usefulness, he'd be trying
to get them into the core. I don't know what his goals are though.
I did release a replacement for the rotor module that's written in
Python, which means it's reasonably useable without being in the core.
However, while its security should be ok, to provide reasonable
performance it had to use a nonstandard algorithm and therefore isn't
good for interoperating with anything. To be both acceptably fast and
interoperable with other applications, a C module is needed.
?
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Paul said:
As Andrew says, it is not apparent that there was consensus.
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