До версии 3.4 Python использовал вариант FNV, который не является криптографически безопасным. К сожалению, простое добавление случайного значения к слабой хэш-функции, как это пробовал Python, не обеспечивает реальной безопасности. Легко сгенерировать строки, которые будут иметь один и тот же хэш FNV, даже при наличии рандомизации, благодаря слабости базового алгоритма хеширования.
Обратите внимание, что это верно, даже если начальное значение совершенно случайное и не просочилось к клиенту.
Чтобы понять, почему, представьте себе очень слабую хеш-функцию — простое сложение всех символов в строке. В этом случае, если вы добавите в начало случайное значение, то хэш любой отдельной строки будет случайным. Однако, если в двух строках есть символы, сумма которых дает одно и то же значение, то они будут хешироваться до одного и того же значения, независимо от того, что является случайным начальным числом. Следовательно, случайное начальное число не обеспечивает никакого сопротивления столкновениям. То, что на самом деле сделал Python, не так уж плохо, но и не намного лучше.
В версии 3.4 Python переключил алгоритм по умолчанию на SipHash, который, как считается, криптографически защищен от DOS-атак с коллизиями. К сожалению, любому, кто использует 2.x, совершенно не повезло.
person
Antimony
schedule
10.02.2017
cryptographically secure (at least for one session)
? - person thefourtheye   schedule 30.04.2014hash
целого числа является только этим целым числом. Это не изменится между вызовами интерпретатора. - person thefourtheye   schedule 30.04.2014