Re: [Python-Dev] PEP 7 clarification request: braces

On Mon, 2012-01-02 at 14:44 +1000, Nick Coghlan wrote: > I've been having an occasional argument with Benjamin regarding braces > in 4-line if statements: > > if (cond) > statement; > else > statement; > > vs. > > if (cond) { > statement; > } else { > statement; > } >

[Python-Dev] That depends on what the meaning of "is" is (was Re: http://mail.python.org/pipermail/python-dev/2011-December/115172.html)

On Sun, Jan 1, 2012 at 10:28 PM, Jim Jewett wrote: > Given the wording requiring a real dictionary, I would have assumed > that it was OK (if perhaps not sensible) to do pointer arithmetic and > access the keys/values/hashes directly. (Though if the breakage was > between python versions, I woul

Re: [Python-Dev] PEP 7 clarification request: braces

On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial wrote: > On 1/1/2012 11:44 PM, Nick Coghlan wrote: >> I think it's a recipe for future maintenance hassles when someone adds >> a second statement to one of the clauses but doesn't add the braces. >> (The only time I consider it reasonable to leave out th

Re: [Python-Dev] Hash collision security issue (now public)

I fixed a couple things in my proposed algorithm: https://gist.github.com/0a91e52efa74f61858b5 I had a typo, and used 21 instead of 12 for the size multiplier. We definitely don't need 2MB random data. The initialization of r was broken. Now it is an array of ints, so there's no conversion when i

Re: [Python-Dev] PEP 7 clarification request: braces

On 1/1/2012 11:44 PM, Nick Coghlan wrote: > I think it's a recipe for future maintenance hassles when someone adds > a second statement to one of the clauses but doesn't add the braces. > (The only time I consider it reasonable to leave out the braces is for > one liner if statements, where there's

Re: [Python-Dev] PEP 7 clarification request: braces

Nick Coghlan writes: > He keeps leaving [braces] out [when the block is a single statement], > I occasionally tell him they should always be included (most recently > this came up when we gave conflicting advice to a patch contributor). As someone who has maintained his fair share of C code, I a

[Python-Dev] PEP 7 clarification request: braces

I've been having an occasional argument with Benjamin regarding braces in 4-line if statements: if (cond) statement; else statement; vs. if (cond) { statement; } else { statement; } He keeps leaving them out, I occasionally tell him they should always be included (most

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Sun, Jan 1, 2012 at 10:00 PM, PJ Eby wrote: > On Sun, Jan 1, 2012 at 7:37 PM, Jim Jewett wrote: >> Well, there is nothing wrong with switching to a different hash function >> after N >> collisions, rather than "in the first place".  The perturbation >> effectively does by >> shoving the high-

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Sun, Jan 1, 2012 at 7:37 PM, Jim Jewett wrote: > Well, there is nothing wrong with switching to a different hash function > after N > collisions, rather than "in the first place". The perturbation > effectively does by > shoving the high-order bits through the part of the hash that survives t

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Sun, Jan 1, 2012 at 8:04 PM, Christian Heimes wrote: > Am 02.01.2012 01:37, schrieb Jim Jewett: >> Well, there is nothing wrong with switching to a different hash function >> after N >> collisions, rather than "in the first place".  The perturbation >> effectively does by >> shoving the high-o

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

On Mon, 02 Jan 2012 02:04:38 +0100 Christian Heimes wrote: > > PS: Something is wrong with your email client. Every of your replies > starts a new thread for me. Same here. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://m

Re: [Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

Am 02.01.2012 01:37, schrieb Jim Jewett: > Well, there is nothing wrong with switching to a different hash function > after N > collisions, rather than "in the first place". The perturbation > effectively does by > shoving the high-order bits through the part of the hash that survives the > mask

[Python-Dev] http://mail.python.org/pipermail/python-dev/2011-December/115172.html

In http://mail.python.org/pipermail/python-dev/2011-December/115172.html, P. J. Eby wrote: > On Sat, Dec 31, 2011 at 7:03 AM, Stephen J. Turnbull > wrote: >> While the dictionary probe has to start with a hash for backward >> compatibility reasons, is there a reason the overflow strategy for >>

[Python-Dev] Hash collision security issue (now public)

Victor Stinner wrote in > If we want to protect a website against this attack for example, we must > suppose that the attacker can inject arbitrary data and can get > (indirectly) the result of hash(str) (e.g. with the represen

[Python-Dev] Hash collision security issue (now public)

Paul McMillan in wrote: > Guido van Rossum wrote: >> Hm. I'm not sure I like the idea of extra arithmetic for every character >> being hashed. > the collision generator doesn't necessarily vary the length of the > string. Addi

Re: [Python-Dev] Hash collision security issue (now public)

> Different concern. What if someone were to have code implementing an > external, persistent hash table, using Python's hash() function? They might > have a way to rehash everything when a new version of Python comes along, > but they would not be happy if hash() is different in each process. I >

Re: [Python-Dev] Hash collision security issue (now public)

> But how about precomputing the intermediate value (x)? The hash is (mostly) > doing x = f(x, c) for each c in the input. That's a fair point. If we go down that avenue, I think simply choosing a random fixed starting value for x is the correct choice, rather than computing an intermediate value.

[Python-Dev] Hash collision security issue (now public)

Steven D'Aprano (in ) wrote: > By compile-time, do you mean when the byte-code is compilated, i.e. just > before runtime, rather than a switch when compiling the Python executable from > source? No. I really mean when the C c

Re: [Python-Dev] Hash collision security issue (now public)

On 1/1/2012 12:28 PM, Christian Heimes wrote: Am 01.01.2012 17:54, schrieb Antoine Pitrou: I don't understand. FNV-1 multiplies the current running result with a prime and then xors it with the following byte. This is also what we do. (I'm assuming 103 is prime) There must be a major diffe

Re: [Python-Dev] Hash collision security issue (now public)

On 1/1/2012 10:13 AM, Guido van Rossum wrote: PS. Is the collision-generator used in the attack code open source? As I posted before, Alexander Klink and Julian Wälde gave their project email as hash...@alech.de. Since they indicated disappointment in not hearing from Python, I presume they w

Re: [Python-Dev] Hash collision security issue (now public)

Le 01/01/2012 04:29, Paul McMillan a écrit : This is incorrect. Once an attacker has guessed the random seed, any operation which reveals the ordering of hashed objects can be used to verify the answer. JSON responses would be ideal. In fact, an attacker can do a brute-force attack of the random

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 01:11, schrieb Guido van Rossum: > FWIW I managed to build Python 2.6, and a trivial mutation of the > string/unicode hash function (add 1 initially) made only three tests > fail; test_symtable and test_json both have a dependency on dictionary > order, test_ctypes I can't quite figur

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 17:54, schrieb Antoine Pitrou: > I don't understand. FNV-1 multiplies the current running result with a > prime and then xors it with the following byte. This is also what we do. > (I'm assuming 103 is prime) There must be a major difference somewhere inside the algorithm. The ta

Re: [Python-Dev] Hash collision security issue (now public)

Le dimanche 01 janvier 2012 à 17:34 +0100, Christian Heimes a écrit : > Am 01.01.2012 17:09, schrieb Antoine Pitrou: > > On Sun, 01 Jan 2012 16:48:32 +0100 > > Christian Heimes wrote: > >> The talkers claim and have shown that it's too easy to pre-calculate > >> collisions with hashing algorithms

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 17:09, schrieb Antoine Pitrou: > On Sun, 01 Jan 2012 16:48:32 +0100 > Christian Heimes wrote: >> The talkers claim and have shown that it's too easy to pre-calculate >> collisions with hashing algorithms similar to DJBX33X / DJBX33A. It >> might be a good idea to change the hashing a

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 06:57, schrieb Paul McMillan: > I agree that doing anything is better than doing nothing. If we use > the earlier suggestion and prepend everything with a fixed-length > seed, we need quite a bit of entropy (and so a fairly long string) to > make a lasting difference. Your code at ht

Re: [Python-Dev] Hash collision security issue (now public)

On Sun, 01 Jan 2012 16:56:19 +0100 Christian Heimes wrote: > Am 01.01.2012 05:11, schrieb Antoine Pitrou: > > On Sat, 31 Dec 2011 16:56:00 -0700 > > Guido van Rossum wrote: > >> ISTM the only reasonable thing is to have a random seed picked very early > >> in the process, to be used to change the

Re: [Python-Dev] Hash collision security issue (now public)

On Sun, 01 Jan 2012 16:48:32 +0100 Christian Heimes wrote: > The talkers claim and have shown that it's too easy to pre-calculate > collisions with hashing algorithms similar to DJBX33X / DJBX33A. It > might be a good idea to change the hashing algorithm, too. Paul as > listed some new algorithms.

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 05:11, schrieb Antoine Pitrou: > On Sat, 31 Dec 2011 16:56:00 -0700 > Guido van Rossum wrote: >> ISTM the only reasonable thing is to have a random seed picked very early >> in the process, to be used to change the hash() function of >> str/bytes/unicode (in a way that they are still

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 00:56, schrieb Guido van Rossum: > ISTM the only reasonable thing is to have a random seed picked very > early in the process, to be used to change the hash() function of > str/bytes/unicode (in a way that they are still compatible with each other). > > The seed should be unique per

Re: [Python-Dev] Hash collision security issue (now public)

Am 31.12.2011 23:38, schrieb Terry Reedy: > On 12/31/2011 4:43 PM, PJ Eby wrote: > >> Here's an idea. Suppose we add a sys.hash_seed or some such, that's >> settable to an int, and defaults to whatever we're using now. Then >> programs that want a fix can just set it to a random number, > > I d

Re: [Python-Dev] Hash collision security issue (now public)

Am 01.01.2012 16:13, schrieb Guido van Rossum: > Different concern. What if someone were to have code implementing an > external, persistent hash table, using Python's hash() function? They > might have a way to rehash everything when a new version of Python comes > along, but they would not be hap

Re: [Python-Dev] Hash collision security issue (now public)

PS. Is the collision-generator used in the attack code open source? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailm

Re: [Python-Dev] Hash collision security issue (now public)

Different concern. What if someone were to have code implementing an external, persistent hash table, using Python's hash() function? They might have a way to rehash everything when a new version of Python comes along, but they would not be happy if hash() is different in each process. I somehow va

Re: [Python-Dev] Hash collision security issue (now public)

On Sat, Dec 31, 2011 at 10:57 PM, Paul McMillan wrote: > > Still, it would represent an effort for the attacker of a much greater > > magnitude than the current attack. It's all a trade-off -- at some point > > it'll just be easier for the attacker to use some other vulnerability. > Also > > the