Hi,
I have found a link to a speed comparison of hash functions:
http://code.google.com/p/xxhash/
Regards,
Wolfgang
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pytho
On 4 Oct 2013 07:17, "Guido van Rossum" wrote:
>
> On Thu, Oct 3, 2013 at 2:13 PM, Nick Coghlan wrote:
>>
>> On 4 Oct 2013 06:08, "Victor Stinner" wrote:
>> >
>> > 2013/10/3 Christian Heimes :
>> > > A hash algorithm can be added and one avaible hash
>> > > algorithm can be set before Py_Initial
On Sat, 5 Oct 2013 08:25:01 -0700
Guido van Rossum wrote:
>
> A good defense combines multiple techniques -- e.g. common sense about when
> and where you park your bike together with a mediocre lock might make the
> theft risk acceptably low.
(just remember to park it under a shed with an approp
On Thu, Oct 3, 2013 at 11:20 PM, Armin Rigo wrote:
> Hi Guido,
>
> On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum
> wrote:
> > Sounds a bit like some security researchers drumming up business. If you
> can
> > run the binary, presumably you can also recover the seed by looking in
> > /proc, r
Am 05.10.13 01:27, schrieb Victor Stinner:
> Ok, but why should we invest time to fix this specific DoS wheras
> there are other DoS like XML bomb?
That is a question about the very mechanics of free software.
"We" don't need to invest time into anything (and you may have
noticed that I lately act
On 10/05/2013 01:14 AM, Victor Stinner wrote:
And how do you retrieve the whole hash value from an HTTP page? You
may retrieve some bits using specific HTTP requests, but not directly
the whole hash value. I don't know any web page displaying directly
the hash value of a string coming from the
On Sat, Oct 05, 2013 at 01:27:37AM +0200, Victor Stinner wrote:
> I have no idea of the price of renting a botnet, it's probably
> expensive (and illegal as well).
Twelve cents per machine. Cheaper in bulk, and cheaper still for
machines outside of the US. For those on a budget, you can get ten
2013/10/4 :
>
> Quoting Victor Stinner :
>
>> I still fail to understand the real impact of a hash DoS compared to
>> other kinds of DoS.
>
>
> I think the key question is: how many attacking nodes do you need to
> control to effectively make some system deny service. A threat is bigger
> if you c
2013/10/5 Larry Hastings :
> On 10/04/2013 11:15 AM, Victor Stinner wrote:
>
> 2013/10/4 Armin Rigo :
>
> The current hash randomization is
> simply not preventing anything; someone posted long ago a way to
> recover bit-by-bit the hash randomized used by a remote web program in
> Python running on
On 10/04/2013 11:15 AM, Victor Stinner wrote:
2013/10/4 Armin Rigo :
The current hash randomization is
simply not preventing anything; someone posted long ago a way to
recover bit-by-bit the hash randomized used by a remote web program in
Python running on a server.
Oh interesting, is it public
Le Fri, 04 Oct 2013 17:13:32 +0200,
mar...@v.loewis.de a écrit :
>
> Whether this is a serious threat or not depends on what other threats
> the system being attacked is vulnerable to. Maybe there is something
> even simpler, or maybe the hash attack is the only hope of bringing
> the system to it
Quoting Victor Stinner :
I still fail to understand the real impact of a hash DoS compared to
other kinds of DoS.
I think the key question is: how many attacking nodes do you need to
control to effectively make some system deny service. A threat is bigger
if you can do it in 10 requests/s fro
Le Fri, 4 Oct 2013 11:15:17 +0200,
Victor Stinner a écrit :
> 2013/10/4 Armin Rigo :
> > The current hash randomization is
> > simply not preventing anything; someone posted long ago a way to
> > recover bit-by-bit the hash randomized used by a remote web program
> > in Python running on a server
Am 04.10.2013 11:15, schrieb Victor Stinner:
> 2013/10/4 Armin Rigo :
>> The current hash randomization is simply not preventing anything;
>> someone posted long ago a way to recover bit-by-bit the hash
>> randomized used by a remote web program in Python running on a
>> server.
>
> Oh interesting
2013/10/4 Armin Rigo :
> The current hash randomization is
> simply not preventing anything; someone posted long ago a way to
> recover bit-by-bit the hash randomized used by a remote web program in
> Python running on a server.
Oh interesting, is it public? If yes, could we please search the URL
Hi Guido,
On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum wrote:
> Sounds a bit like some security researchers drumming up business. If you can
> run the binary, presumably you can also recover the seed by looking in
> /proc, right? Or use ctypes or something. This demonstration seems of
> acad
On Thu, Oct 3, 2013 at 1:06 PM, Victor Stinner wrote:
> 2013/10/3 Christian Heimes :
> > A hash algorithm can be added and one avaible hash
> > algorithm can be set before Py_Initialize() is called for the first
> > time.
>
> "Py_Initialize" is not the good guard. Try for example "python3 -X
> fau
On Thu, Oct 3, 2013 at 12:05 PM, Guido van Rossum wrote:
> We already have adopted a feature that plugged most viable attacks on web
> apps, I think that's enough.
>
Actually... we did not do a very good job on that:
http://bugs.python.org/issue14621
The point of allowing alternates is to let p
On Thu, Oct 3, 2013 at 11:42 AM, Christian Heimes wrote:
> Hi,
>
> some of you may have seen that I'm working on a PEP for a new hash API
> and new algorithms for hashing of bytes and str. The PEP has three major
> aspects. It introduces DJB's SipHash as secure hash algorithm, chances
> the hash A
03.10.13 23:47, Guido van Rossum написав(ла):
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes mailto:christ...@python.org>> wrote:
Am 03.10.2013 21:45, schrieb Guido van Rossum:
> But fixing that shouldn't need all the extra stuff you're
> proposing.
I have proposed some of
On Thu, Oct 3, 2013 at 2:13 PM, Nick Coghlan wrote:
> On 4 Oct 2013 06:08, "Victor Stinner" wrote:
> >
> > 2013/10/3 Christian Heimes :
> > > A hash algorithm can be added and one avaible hash
> > > algorithm can be set before Py_Initialize() is called for the first
> > > time.
> >
> > "Py_Initi
On 4 Oct 2013 06:08, "Victor Stinner" wrote:
>
> 2013/10/3 Christian Heimes :
> > A hash algorithm can be added and one avaible hash
> > algorithm can be set before Py_Initialize() is called for the first
> > time.
>
> "Py_Initialize" is not the good guard. Try for example "python3 -X
> faulthandl
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes wrote:
> Am 03.10.2013 21:45, schrieb Guido van Rossum:
> > But fixing that shouldn't need all the extra stuff you're
> > proposing.
>
> I have proposed some of the extra stuff for more flexibility, the rest
> is for testing and debugging.
>
Hm, I
2013/10/3 Christian Heimes :
> A hash algorithm can be added and one avaible hash
> algorithm can be set before Py_Initialize() is called for the first
> time.
"Py_Initialize" is not the good guard. Try for example "python3 -X
faulthandler": PyObject_Hash() is called before Py_Initialize() to add
Am 03.10.2013 21:45, schrieb Guido van Rossum:
> But fixing that shouldn't need all the extra stuff you're
> proposing.
I have proposed some of the extra stuff for more flexibility, the rest
is for testing and debugging.
> What's a Python randomization key?
Python's hash randomization key, the s
On Thu, Oct 3, 2013 at 12:23 PM, Christian Heimes wrote:
> Am 03.10.2013 21:05, schrieb Guido van Rossum:
> > Hm. I would like to stick to the philosophy that Python's hash
> > should be as fast as it possibly can be, and should not be mistaken
> > for a cryptographic hash. The point is to optimiz
Am 03.10.2013 21:05, schrieb Guido van Rossum:
> Hm. I would like to stick to the philosophy that Python's hash
> should be as fast as it possibly can be, and should not be mistaken
> for a cryptographic hash. The point is to optimize dict lookups,
> nothing more, given typical (or even atypical) k
Hm. I would like to stick to the philosophy that Python's hash should be as
fast as it possibly can be, and should not be mistaken for a cryptographic
hash. The point is to optimize dict lookups, nothing more, given typical
(or even atypical) key distribution, not to thwart deliberate attacks. We
a
On Thu, 03 Oct 2013 20:42:28 +0200
Christian Heimes wrote:
>
> I haven't actually benchmarked how a faster hash algorithm
> affects the a real program, though ...
Chances are it doesn't. Only a "slow enough" hash algorithm might have
an impact, IMHO.
> On which level should Python support a plu
Hi,
some of you may have seen that I'm working on a PEP for a new hash API
and new algorithms for hashing of bytes and str. The PEP has three major
aspects. It introduces DJB's SipHash as secure hash algorithm, chances
the hash API to process blocks of data instead characters and it adds an
API to
30 matches
Mail list logo
