Paul Rubin http wrote:
Actually and surprisingly, that's not really true. Crypto algorithms
are pretty straightforward, so if you examine the code and check that
it passes a bunch of test vectors, you can be pretty sure it's
correct.
I was going to write pretty much the same thing.
If a
Paul Rubin wrote:
Oh, ok. Earlier you said you wanted user feedback before you could
conclude that there was reason to want an AES module at all.
I believe I never said that. I said that I wanted user feedback to
determine whether *this* AES module (where this is either your
from-scratch
Skip Montanaro [EMAIL PROTECTED] wrote:
Fine. Go build a sumo distribution and track the normal CPython.
The problem isn't all that new. (Take a look at scipy.org for one
take on that theme. Of course Linux distros have been doing their
take on this forever.)
If I'm writing code just
Paul Rubin http wrote:
Martin v. Löwis [EMAIL PROTECTED] writes:
Apparently, people disagree on what precisely the API should be. E.g.
cryptkit has
obj = aes(key)
obj.encrypt(data)
I don't disagree about the API. The cryptkit way is better than ECB
example I gave, but the ECB
Nick Craig-Wood [EMAIL PROTECTED] writes:
There is a PEP about this...
API for Block Encryption Algorithms v1.0
http://www.python.org/peps/pep-0272.html
Yes, I know about that and have been in contact with its author. He
and I are in agreement (or at least were in agreement some time
Martin v. Löwis [EMAIL PROTECTED] writes:
Oh, ok. Earlier you said you wanted user feedback before you could
conclude that there was reason to want an AES module at all.
I believe I never said that. I said that I wanted user feedback to
determine whether *this* AES module (where this is
Nick I think one of the special things about Python is its batteries
Nick included approach, and a crypto library would seem to be an
Nick obvious battery to install since it doesn't (or needn't) depend on
Nick any other library or application.
Obvious for some I suppose (I've
Skip Montanaro [EMAIL PROTECTED] writes:
While it might be convenient to not have to distribute some third
party library in addition to Python, there is a fundamental problem
implementing a crypto algorithm from scratch for inclusion into
Python. There is always the problem that the new code
Paul Rubin wrote:
Oops, sorry, it's in the os module:
http://docs.python.org/lib/os-miscfunc.html
The difference is simply a matter of the packaging.
No, it's not. It also is a matter of code size, and impact. Small
additions can be reviewed and studied more easily, and need to be
tested on
Martin v. Löwis [EMAIL PROTECTED] writes:
Indeed, if it was a single new function to an existing module, I would
not require that this be delivered to users first. It is entire new
libraries that I worry about.
Why is it different if a single new function is added to an existing
module, or if
http://www.python.org/pypi
THIS IS ALL PYTHON.
Paul No. Those are programs people have written in Python or as Python
Paul extensions.
What's your point? That I have to download and perhaps install them to use
them? In that case, how are these two scenarios different:
What matters is the code complexity, not whether something is in a
separate module or not.
Martin A module *is* typically more complex than a single function.
And one that deals with cryptography is likely to be even more complex.
Skip
--
Skip Montanaro [EMAIL PROTECTED] writes:
What's your point? That I have to download and perhaps install them to use
them? In that case, how are these two scenarios different:
* I have to download and build the MySQLdb package to talk to MySQL
servers from Python code
* I
Skip Montanaro [EMAIL PROTECTED] writes:
And one that deals with cryptography is likely to be even more complex.
No. The AES module would have about the same complexity as the SHA module.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin http://[EMAIL PROTECTED] writes:
actually: mxCrypto is the most capable of these packages and might be
the one with the most users, but it's completely unsuitable for the
core because of its size).
Oops, I should say, mxCrypto itself isn't that large; the issue is
that it needs
Paul Rubin wrote:
An AES or DES addition to an existing module that implements just one
call:
ECB(key, data, direction)
would be a huge improvement over what we have now.
Apparently, people disagree on what precisely the API should be. E.g.
cryptkit has
obj = aes(key)
obj.encrypt(data)
I think
Paul Rubin wrote:
(And
actually: mxCrypto is the most capable of these packages and might be
the one with the most users, but it's completely unsuitable for the
core because of its size).
mxCrypto is primarily unsuitable for the core because Marc-Andre Lemburg
will never ever contribute it. He is
Paul Rubin http wrote:
An AES or DES addition to an existing module that implements just one
call:
ECB(key, data, direction)
would be a huge improvement over what we have now. A more complete
crypto module would have some additional operations, but ECB is the
only one that's really
Paul I've had this discussion here before, maybe not with you. What I
Paul really want is zero installations of anything.
Fine. Go build a sumo distribution and track the normal CPython. The
problem isn't all that new. (Take a look at scipy.org for one take on that
theme. Of course
Martin v. Löwis [EMAIL PROTECTED] writes:
Apparently, people disagree on what precisely the API should be. E.g.
cryptkit has
obj = aes(key)
obj.encrypt(data)
I don't disagree about the API. The cryptkit way is better than ECB
example I gave, but the ECB example shows it's possible to do it
Martin v. Löwis [EMAIL PROTECTED] writes:
mxCrypto is primarily unsuitable for the core because Marc-Andre Lemburg
will never ever contribute it. He is very concerned about including
crypto code with the Python distribution, so he certainly won't
contribute his own.
Oh wait, I confused
Nick Craig-Wood [EMAIL PROTECTED] writes:
I would hate to see a module which only implemented ECB. Sure its the
only operation necessary to build the others out of, but its the least
secure mode of any block cipher.
It's intended as a building block for other modes. Most applications
Skip Montanaro [EMAIL PROTECTED] writes:
* Quixote
Paul Don't know what this is.
Web app framework.
I think Python should add a web app framework to its core, again since
it otherwise can't seriously begin to compete with PHP. However,
there are lots of approaches so this is an
Paul Rubin wrote:
I can say that assuming I know what so-and-so is. For the specific
case of AES, I would say I don't think the Python lib necessarily
needs to have an AES module, but I would not object if it had one
Well, ok, you're changing your tune a little bit now, and getting more
Martin v. Löwis [EMAIL PROTECTED] writes:
And I still stand by those blanket statements. Any new module (i.e.
specific code) should see real users for some time before it can
be incorporated into Python.
Let's see, the urandom module was recently released in 2.4, I think
initially at my
Paul Rubin wrote:
Let's see, the urandom module was recently released in 2.4, I think
initially at my urging.
There is no urandom module in Python 2.4.
If you can't speak for others, how can you say there's no policy in
force?
I should say I'm not aware of a policy.
If Guido says no crypto, is
Martin v. Löwis [EMAIL PROTECTED] writes:
Let's see, the urandom module was recently released in 2.4, I think
initially at my urging.
There is no urandom module in Python 2.4.
Oops, sorry, it's in the os module:
http://docs.python.org/lib/os-miscfunc.html
The difference is simply a
snip
As long as we are discussing cryptography, what's wrong with m2crypto?
http://sandbox.rulemaker.net/ngps/m2/
Why not incorporate it into the standard distribution?
Or, what about Andrew Kuchling's crypto toolkit?
http://www.amk.ca/python/code/crypto.html
snip
Umm, is it just me or
Finally, what if, saints be preserved, your whizbang new module is
phr It is not a whizbang module. It is a stripped-down, basic
phr implementation of a well-accepted set of standards that are being
phr used in thousands of other applications in other languages.
Then there
Skip Montanaro [EMAIL PROTECTED] writes:
phr It is not a whizbang module. It is a stripped-down, basic
phr implementation of a well-accepted set of standards that are being
phr used in thousands of other applications in other languages.
Then there should be a library already out
Skip Montanaro [EMAIL PROTECTED] writes:
As long as we are discussing cryptography, what's wrong with
m2crypto? Or, what about Andrew Kuchling's crypto toolkit?
Lucas Umm, is it just me or did we just discuss the legal issues of
Lucas that??
You may have. Whether or
[EMAIL PROTECTED] wrote:
I don't see why you can't make up your mind enough to issue simple
statements like the Python lib should have a module that does
so-and-so
I can say that assuming I know what so-and-so is. For the specific
case of AES, I would say I don't think the Python lib necessarily
Martin v. Löwis [EMAIL PROTECTED] writes:
I don't see why you can't make up your mind enough to issue simple
statements like the Python lib should have a module that does
so-and-so
I can say that assuming I know what so-and-so is. For the specific
case of AES, I would say I don't think
[EMAIL PROTECTED] wrote:
That it's not appropriate for the
distro maintainers to look at the spec and the reference (pure Python)
implementatation and say yes, we want this, go write the C version
and we'll include it after it's had some testing.
I know that I'm not going to give a blanket
Martin v. Löwis [EMAIL PROTECTED] writes:
That it's not appropriate for the
distro maintainers to look at the spec and the reference (pure Python)
implementatation and say yes, we want this, go write the C version
and we'll include it after it's had some testing.
I know that I'm not
phr I don't see why you can't make up your mind enough to issue simple
phr statements like the Python lib should have a module that does
phr so-and-so, and it should meet such-and-such requirements, so if
phr someone submits one that meets the requirements and passes code
phr
Skip Montanaro [EMAIL PROTECTED] writes:
Because good requirements specification is difficult and testing improves
the breed. Better to have the major API changes and bugs taken care of, and
to have its popularity demonstrated *before* it gets into the Python
distribution. The best way to do
On Thu, 27 Jan 2005 04:04:38 +, phr wrote:
Skip Montanaro [EMAIL PROTECTED] writes:
Because good requirements specification is difficult and testing improves
the breed. Better to have the major API changes and bugs taken care of, and
to have its popularity demonstrated *before* it gets
Jeremy Bowers [EMAIL PROTECTED] writes:
The policy has been laid out, multiple times, by multiple people now. The
answer is, you are not going to get any such indication that will satisfy
you.
Actually I already got an indication that satisfied me, from Guido and
Andrew, although it was later
[EMAIL PROTECTED] wrote:
The likely-best-known Python application in the world (probably more
people have heard of it than have heard of Python) originally had
crypto
and what Python application is that? I can think of quite a few applications
written in Python that are widely known, but
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
The likely-best-known Python application in the world (probably more
people have heard of it than have heard of Python) originally had
crypto
and what Python application is that? I can think of quite a few applications
written in Python that are
I've already downloaded p3 - thanks :-)
I wonder how long it took (in reality) an average hacker to break the
algorithm used by rotor ?
Regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
Now what if acipher and this class could be made from part of the core
distro? Any application could have the option of encryption with only a
few lines of code:
Just a bit of info on the subject (which you might already have)
I do not know in which country the python.msi is compiled
Philippe C. Martin [EMAIL PROTECTED] writes:
I do not know in which country the python.msi is compiled (Deuchland ?),
but most likely, the county has rules like most other as far as crypto
code in binary format export (especially if distributed as part of a
commercial package): for instance,
Paul Rubin http://[EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (John J. Lee) writes:
Building larger ones seems to
have complexity exponential in the number of bits, which is not too
Why?
The way I understand it, that 7-qubit computer was based on embedding
the qubits on atoms in a
Philippe C. Martin [EMAIL PROTECTED] writes:
So far getting the agreement for my product has taken two months of work
(http://www.bis.doc.gov/encryption/) I hope to get a positive
response this week (wish me luck!)
That sounds like you're doing a closed source product and need an ENC
I also feel the lack of a standard cryptography module in the core...
even a *basic* one. At least rotor provided that, before it was
deprecated. I (along with many other python users) write CGIs where the
only extension modules that I can use are either pure python, or ones
my web hoster is
Fuzzyman [EMAIL PROTECTED] writes:
I also feel the lack of a standard cryptography module in the core...
even a *basic* one. At least rotor provided that, before it was deprecated.
Rotor was insecure and really shouldn't have been used. If you need
crypto in pure Python, try this:
[Note: this is a 2nd attempt at posting reply to Martin's message,
since the first one didn't reach the server. It's a rewrite from memory
but says about the same thing as the other attempt. --Paul]
Martin v. Löwis [EMAIL PROTECTED] writes:
Paul Rubin wrote:
If he understood how Python is
[EMAIL PROTECTED] wrote:
Maybe we're not thinking about the same problems. Say I'm an app
writer and I want to use one of your modules. My development
environment is GNU/Linux, and I want to ship a self-contained app that
anyone can run without having to download additional components.
[EMAIL PROTECTED] wrote
As an app writer I want to publish code that runs on multiple
platforms without needing special attention from the end user, and
preferably without needing special platform-specific attention from
me.
please answer the question: have you done this? what kind of
Fredrik Lundh [EMAIL PROTECTED] writes:
please answer the question: have you done this? what kind of programs
have you successfully delivered as self-contained apps for use on arbi-
trary platforms?
Here's a simple one:
import sha
name = raw_input('Enter your name: ')
print 'Your
[EMAIL PROTECTED] wrote:
Maybe we're not thinking about the same problems. Say I'm an app
writer and I want to use one of your modules. My development
environment is GNU/Linux, and I want to ship a self-contained app that
anyone can run without having to download additional components. That
Martin v. Löwi said
Hmm. Most applications don't have any crypto needs.
Any program where one stores data would have crypto needs.
Here are some examples: Database, wordprocessor, spreadsheet, address
book, mail program, (should I go on?). What would be the alternative to
encryption to satisfy
James Stroud wrote:
Martin v. Löwi said
Hmm. Most applications don't have any crypto needs.
Any program where one stores data would have crypto needs.
James, you must have mistyped the above, or your logic
is quite flawed.
I have written dozens of programs which store data, and
only a couple have
On Monday 24 January 2005 03:40 pm, Fredrik Lundh wrote:
have you tried this, or are you just making things up to be able to continue
the argument? (hint: it doesn't work; python portability means that it's
fairly
easy to write programs that run on multiple platforms, not that they will run
I was purposefully making an illogical statement to illustrate the lapse
in reason of Martin's statement. Users have crypto needs, not
applications. Applications are presumably not anthropomorphic enough to
have needs--hence the lack of logic.
However, I am not an application (as far as you or I
James Stroud [EMAIL PROTECTED] writes:
Applications that lack features force users to accept a limited feature
set or they use an alternative program with other limitations. Putting
the possibility for cryptographic storage increases the utility of any
application that stores data, and it
[Again I'm having news server trouble and made a previous attempt to
post this, so sorry if you see it twice. This version is edited
somewhat from the previous.]
Martin v. Löwis [EMAIL PROTECTED] writes:
This is not possible - whether the module is included in Python or not.
People *will* have
Terry Hancock wrote:
And, well, I'm sorry Mr. Lundh, but your PIL module actually is something
of a pain to install still. The OP is right about that. Usually worth it,
but I don't
like the fact that that pain is being passed on to the end-user of my
software.
The fact that you got all
Paul Rubin wrote:
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.
As Andrew says, it is not apparent that there was consensus.
Martin, do you know more
Paul Rubin wrote:
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.
This is non-sense. I have been distributing C modules outside
the core for quite some time now, and I found that the modules
are quite useful.
Paul Rubin http wrote:
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
Nick Craig-Wood [EMAIL PROTECTED] writes:
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.
I'm sure thats wrong now-a-days. Here are some examples of open
source software with
Paul Rubin wrote:
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
A.M. Kuchling [EMAIL PROTECTED] writes:
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
Paul Rubin wrote:
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
Fredrik Lundh [EMAIL PROTECTED] writes:
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.
Excellent. I hope you will re-read it several times a day. Doing
that might improve your attitude.
--
Paul Rubin wrote:
Excellent. I hope you will re-read it several times a day. Doing
that might improve your attitude.
you really don't have a fucking clue about anything, do you?
/F
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh [EMAIL PROTECTED] writes:
Excellent. I hope you will re-read it several times a day. Doing
that might improve your attitude.
you really don't have a fucking clue about anything, do you?
You're not making any bloody sense. I explained to you why I wasn't
interested in
Paul Rubin http://phr.cx@NOSPAM.invalid writes:
[...]
Building larger ones seems to
have complexity exponential in the number of bits, which is not too
[...]
Why?
It's not even known in theory whether quantum computing is
possible on a significant scale.
Discuss. wink
(I don't mean I'm
[EMAIL PROTECTED] (John J. Lee) writes:
Building larger ones seems to
have complexity exponential in the number of bits, which is not too
Why?
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
A.M. Kuchling [EMAIL PROTECTED] writes:
It was discussed in this thread:
http://mail.python.org/pipermail/python-dev/2003-April/034959.html
In that thread, you wrote:
Rubin wanted to come up with a nice interface for the module, and
has posted some notes toward it. I have an existing
Paul Rubin wrote:
you really don't have a fucking clue about anything, do you?
You're not making any bloody sense.
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
Paul Rubin said unto the world upon 2005-01-22 20:16:
Fredrik Lundh [EMAIL PROTECTED] writes:
You're not making any bloody sense.
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
Brian van den Broek [EMAIL PROTECTED] writes:
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
[EMAIL PROTECTED] wrote:
Do you know this for a fact?
I'm going by newsgroup messages from around the time that I was
proposing to put together a standard block cipher module for Python.
Ah, newsgroup messages. Anybody could respond, whether they have insight
or not.
The PSF does comply with the
Robin Becker schreef:
well since rotor is a german (1930's) invention
And AES is a Belgian invention... ;-)
it is a bit late for
Amricans (Hollywood notwithstanding) to be worried about its export
--
JanC
Be strict when sending and tolerant when receiving.
RFC 1958 - Architectural
Martin v. Löwis [EMAIL PROTECTED] writes:
I'm going by newsgroup messages from around the time that I was
proposing to put together a standard block cipher module for Python.
Ah, newsgroup messages. Anybody could respond, whether they have insight
or not.
Here's the message I had in
Paul Rubin schrieb:
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?
That was years ago. The regulations changed since then, so they all
have 128 bits now.
Perhaps the NSA has found a way to handle 128bit in the
Peter Maas wrote:
Paul Rubin schrieb:
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?
That was years ago. The regulations changed since then, so they all
have 128 bits now.
Perhaps the NSA has found a way to
Robin Becker [EMAIL PROTECTED] writes:
Apparently factorization based crypto is on the way out anyhow (as an
article in Scientific American is reported to claim).
I haven't seen that SA article but I saw the Slashdot blurb. They
have confused quantum cryptography with quantum computation, when
Paul Rubin wrote:
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
Martin v. Lwis [EMAIL PROTECTED] writes:
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
Robin Becker [EMAIL PROTECTED] writes:
Paul Rubin wrote:
.I'm also missing the rotor module and regret that something useful
was warned about and now removed with no plugin replacement.
Hm, yes. Here is a (rather slow) replacement:
This module is derived from Modules/rotormodule.c and
Robin Becker [EMAIL PROTECTED] writes:
What exactly are/were the political reasons for rotor removal?
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
Robin Becker [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Reed L. O'Brien [EMAIL PROTECTED] writes:
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately... Is there a standard module that works alike or
an AES module that works alike but with better
Scott David Daniels [EMAIL PROTECTED] writes:
I understand this to be true. Since I am trying to address encryption
in the zipfile module, and I know you actually follow a bit of the
encryption stuff, can you answer a question or two for me?
Sure, I can try, so go ahead. There's more crypto
Nick Craig-Wood wrote:
Robin Becker [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Reed L. O'Brien [EMAIL PROTECTED] writes:
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately... Is there a standard module that works alike or
an AES module that works alike but
Robin Becker wrote:
Presumably he is talking about crypo-export rules. In the past strong
cryptography has been treated as munitions, and as such exporting it
(especially from the USA) could have got you into very serious
trouble.
So Python is an American Language and must obey American Law.
Robin Becker [EMAIL PROTECTED] writes:
Presumably he is talking about crypo-export rules. In the past strong
cryptography has been treated as munitions, and as such exporting it
(especially from the USA) could have got you into very serious
trouble.
well since rotor is a german
On 19 Jan 2005 17:09:19 -0800, Paul Rubin http://[EMAIL PROTECTED] wrote:
Robin Becker [EMAIL PROTECTED] writes:
Presumably he is talking about crypo-export rules. In the past strong
cryptography has been treated as munitions, and as such exporting it
(especially from the USA) could have
[EMAIL PROTECTED] (Bengt Richter) writes:
Isn't the SSL dependent on OS or at least shared lib support?
Firefox has its own implementation. IE uses wininet which is built
Windows. I'm not aware of any no-crypto version of Windows but even
if there is one, the US version is running, like,
I see rotor was removed for 2.4 and the docs say use an AES module
provided separately... Is there a standard module that works alike or
an AES module that works alike but with better encryption?
cheers,
reed
--
http://mail.python.org/mailman/listinfo/python-list
94 matches
Mail list logo
