Re: [Python-Dev] PEPs in progress

[Dirkjan Ochtman]

On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes  wrote:
> The second PEP addresses key derivation functions for secure password
> hashing. I like to add PBKDF2, bcrypt and scrypt facilities to the
> standard library.

Hashing only? I was hoping you would also include PKCS1 RSA primitives.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs in progress

[Antoine Pitrou]

Le Wed, 2 Jan 2013 09:18:17 +0100,
Dirkjan Ochtman  a écrit :
> On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes
>  wrote:
> > The second PEP addresses key derivation functions for secure
> > password hashing. I like to add PBKDF2, bcrypt and scrypt
> > facilities to the standard library.
> 
> Hashing only? I was hoping you would also include PKCS1 RSA
> primitives.

That's a totally different topic, no?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs in progress

[Christian Heimes]

Am 02.01.2013 10:49, schrieb Antoine Pitrou:
> Le Wed, 2 Jan 2013 09:18:17 +0100,
> Dirkjan Ochtman  a écrit :
>> On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes
>>  wrote:
>>> The second PEP addresses key derivation functions for secure
>>> password hashing. I like to add PBKDF2, bcrypt and scrypt
>>> facilities to the standard library.
>>
>> Hashing only? I was hoping you would also include PKCS1 RSA
>> primitives.
> 
> That's a totally different topic, no?

Yeah, these are totally different topics. PKCS #1 is about RSA
encryption, decryption, verification and padding. PBKDF2 is specified in
PKCS #5 v2.0.

PKCS #1 support should be implemented on top of OpenSSL or NaCl. I'm
planing to use OpenSSL as primary implementation and additional code as
fallback implementation of PBKDF2-HMAC-SHA-1, PBKDF2-HMAC-SHA-256 and
PBKDF2-HMAC-SHA-512.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs in progress

[Antoine Pitrou]

Le Wed, 02 Jan 2013 11:06:07 +0100,
Christian Heimes  a écrit :

> Am 02.01.2013 10:49, schrieb Antoine Pitrou:
> > Le Wed, 2 Jan 2013 09:18:17 +0100,
> > Dirkjan Ochtman  a écrit :
> >> On Wed, Jan 2, 2013 at 7:14 AM, Christian Heimes
> >>  wrote:
> >>> The second PEP addresses key derivation functions for secure
> >>> password hashing. I like to add PBKDF2, bcrypt and scrypt
> >>> facilities to the standard library.
> >>
> >> Hashing only? I was hoping you would also include PKCS1 RSA
> >> primitives.
> > 
> > That's a totally different topic, no?
> 
> Yeah, these are totally different topics. PKCS #1 is about RSA
> encryption, decryption, verification and padding. PBKDF2 is specified
> in PKCS #5 v2.0.
> 
> PKCS #1 support should be implemented on top of OpenSSL or NaCl. I'm
> planing to use OpenSSL as primary implementation and additional code
> as fallback implementation of PBKDF2-HMAC-SHA-1, PBKDF2-HMAC-SHA-256
> and PBKDF2-HMAC-SHA-512.

Does PBKDF2-SHA3 exist?



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEPs in progress

[Christian Heimes]

Am 02.01.2013 11:11, schrieb Antoine Pitrou:
>> PKCS #1 support should be implemented on top of OpenSSL or NaCl. I'm
>> planing to use OpenSSL as primary implementation and additional code
>> as fallback implementation of PBKDF2-HMAC-SHA-1, PBKDF2-HMAC-SHA-256
>> and PBKDF2-HMAC-SHA-512.
> 
> Does PBKDF2-SHA3 exist?

No HMAC-SHA-3 or PBKDF2-SHA-3 yet. The different design may require
different MAC and KDF functions. At least the sponge design isn't
vulnerable to length extension attacks like Merkle-Damgard
constructions, which removes the need for HMAC-SHA-3.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] hgweb misconfiguration

[Michael Foord]

Hey folks,

Likely the wrong place to report this, but I couldn't work out the best place 
and figured this is only as bad as anywhere else.

A user has reported to webmaster that hgweb is misconfigured (or at least the 
server configuration is interfering with hgweb).

The symptom is that this url is incorrectly a 404:


http://hg.python.org/cpython/file/3.3/Doc/tools/sphinxext/static/version_switch.js

His diagnosis:

>> the web server is misconfigured to serve the hgweb static
>> files for any directory named 'static'. It is appropriate for it to do
>> this for http://hg.python.org/static/ and maybe even
>> http://hg.python.org/cpython/static/ and the other repositories, but
>> it is inappropriate for it to serve the hgweb static files within the
>> repository contents.



What should have happened: The web server passes on the request to
hgweb, which notices that it is supposed to retrieve a particular
version of a file from the Mercurial repository and show it to the
user. This works successfully for URLs not containing '/static/'
(ending slash significant), e.g.,
.
You can see that hgweb successfully displays the directory listing.

However, try adding a slash onto the end of that. The web server picks
up '/static/' and takes over the request, listing its static files
(rather than letting hgweb display the 'static' directory from the
Mercurial repository). The static files shown by the web server's
directory listing are used for the user interface of hgweb; for
example, the logo . It
should be serving those static files on 
and  (where repo is a repository
name like cpython), but it is also serving on
, which is inappropriate,
because it makes it impossible to view version_switch.js and the other
files in that directory with the hgweb interface.

--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test___all__ polluting sys.modules?

[Victor Stinner]

Oh, I just remember this old issue which is somehow similar:
http://bugs.python.org/issue11995

"test_pydoc loads all Python modules"

Running test_pydoc in a subprocess would work around this issue.

Arfrever wrote a patch, I didn't read it (sorry!).

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com