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,
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:
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 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
62 matches
Mail list logo