rgreatКакой смысл пытаться решить принципиально нерешаемую задачу?
Насколько мне известно, на SipHash и BobJenkisnHash lookup3 (тот что в дельфях) с рандомизированным seed атак нет.

rgreatНо если уж хочеться - меняйте seed пока кол-во коллизий не уменьшиться ниже определенного порога. Ну или пока не надоест.
Нет, я просто не стану использовать функцию, которая для этого не годится. По крайней мере, не таким способом.

Есть другой вариант для простых функций - делать двойное хеширование и на завершающем этапе результат одной из функций использовать в качестве входных данных для другой.

rgreatЗа счет какого волшебного механизма они могут исчезнуть?
Никто не говорит, что они исчезли. Появится завтра новый метод анализа и, возможно, выработают алгоритм для атаки.

DmSer,

https://doc.qt.io/qt-5/qmap.html The QMap class is a template class that provides a red-black-tree -based dictionary.
Какой смысл сравнивать разные структуры? Хеш-таблицы там: QHash и QSet.

DmSerКакая разница что там под капотом?
Разница большая . Смотри таблицу с ассоциативными контейнерами.

QMap and QHash provide very similar functionality. The differences are:

QHash provides average faster lookups than QMap. (See Algorithmic Complexity for details.)
When iterating over a QHash, the items are arbitrarily ordered. With QMap, the items are always sorted by key.
The key type of a QHash must provide operator==() and a global qHash(Key) function. The key type of a QMap must provide operator<() specifying a total order. Since Qt 5.8.1 it is also safe to use a pointer type as key, even if the underlying operator<() does not provide a total order.


DmSerСравнивались аналогичные инструменты.
Вовсе нет. Словарь - это просто интерфейс. Реализовать его можно очень по-разному. Вот ты взял дельфийский словарь реализованный через хеш-таблицу (просто потому, что других в коробке нет), а сравниваешь со словарём реализованным через красно-чёрное дерево. Правильнее было бы сравнивать с QHash .

kealon(Ruslan)т.е. есть вероятность, что на таблицу могут провести внешнюю атаку
Разве в Qt'шных таблицах это не залечили использованием QT_HASH_SEED?

kealon(Ruslan)это усложняет, но не исключает
А какая хеш-функция, по дефолту, там используется? Seed они добавили сильно позже чем стало известно о таких атаках, наверняка делали с учётом новых реалий.

DmSer,

А если обеим таблицам предварительно размер установить ?

kealon(Ruslan)я с Qt на вы, не ковырял реализацию, но принципиально это не поможет при определённом желании
Нашёл, что там что-то на основе PJW, правда не совсем понятно куда там seed прикрутили. А вообще, проблема с этой атакой вполне решаема. Я писал выше о SipHash, почти все на неё перешли. На один из первых вариантов lookup3 тоже была атака, однако, потом были внесены изменения и про атаки на неё больше не слышно.

kealon(Ruslan)Qt графическая библиотека и не для серверов
Изначально так и было, но сейчас Qt это полноценный фреймвок с очень неплохим покрытием. Да и что там нужно для серверов, умение в сокеты...

kealon(Ruslan)когда нужно копировать из одной таблицы в другую, тогда например тот же TDictonary замедлится чудовищно, из-за одинаковых хэш-функций и взаимнопростых делителей. Достаточно поменять что-то одно и всё будет летать - делитель поменять сложно(фактически переписать реализацию), а вот другую хэш-функцию задать довольно просто.
Достаточно искоробочную функцию инициализировать рандомно .

DmSer,

Похоже, таблицы там используют метод цепочек.