История изменений
Исправление firkax, (текущая версия) :
Почему это нет? Если k нечётное (по-моему, даже не обязательно простое) то всё должно равномерным оставаться: имеем сложение оригинального hash(x) с какой-то производной от него функцией, сдвинутой как минимум на 1 бит влево. Т.к. биты криптографического хэша друг с другом по определению не коррелируют, то слагаемое в виде сдвинутого на 1 бит влево хэша (+любых манипуляций над ним кроме сдвига вправо или деления) уже никак равномерность распределения исходного hash(x) испортить не может.
Разумеется, надо оговорить что разрядность хэша какая была такая и остаётся, и лишние старшие биты от умножения мы выкидываем. Если их не выкинуть - да, с их учётом будет какое-то неравномерное распределение, но оно и понятно - у нас только 256/512/1024 бит энтропии было, умножением мы её не увеличим.
Хм, думаю это и ответ на один из моих вопросов. Поскольку условие - отсутствие корреляции между битами, то если её действительно нет ни в каком виде и hash(x) идеально в этом плане - можно взять хоть k=3. Если же уверенности нет, то лучше взять что-то побольше для лучшего перемешивания битов между собой при каждом умножении.
Исходная версия firkax, :
Почему это нет? Если k нечётное (по-моему, даже не обязательно простое) то всё должно равномерным оставаться: имеем сложение оригинального hash(x) с какой-то производной от него функцией, сдвинутой как минимум на 1 бит влево. Т.к. биты криптографического хэша друг с другом по определению не коррелируют, то слагаемое в виде сдвинутого на 1 бит влево хэша (+любых манипуляций над ним кроме сдвига вправо или деления) уже никак равномерность распределения исходного hash(x) испортить не может.
Разумеется, надо оговорить что разрядность хэша какая была такая и остаётся, и лишние старшие биты от умножения мы выкидываем. Если их не выкинуть - да, с их учётом будет какое-то неравномерное распределение, но оно и понятно - у нас только 256/512/1024 бит энтропии было, умножением мы её не увеличим.