| 1.1, Crazy Alex (ok), 13:07, 03/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Хм, интересно, но если оно шустро работает только там, где есть AVX-2 - то несколько сомнительное изобретение. Как ни крути, ARM кругом - море.
| | |
| |
| 2.11, Ivan (??), 14:29, 03/03/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Не совсем.
Раз оно шустро работает на AVX2 это означает, что вычисление этой функции параллелизуется. Т.е. даже если набор векторных комманд не позволяет реализовать это на ARM (я не знаю так ли это), скалярный код можно написать так, чтобы он по макимуму использовал параллелизм на уровне инструкций (для супер скалярных процессоров).
| | |
| |
| 3.53, kachsheev (ok), 18:37, 05/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > набор векторных комманд
> ARM
NEON же (не уверен, что на всех процах). 128-битные регистры как раз есть.
| | |
|
|
| 1.2, yaa (?), 13:21, 03/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Дык, это более серверная (даже highload servers) сторона. В этой области ARM --- экзотика.
| | |
| |
| 2.6, VoDA (ok), 14:09, 03/03/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > я один не в курсе, зачем ускорять хеш-функции?
Хэши используются практически везде и всегда. К примеру, Хэш функции используются в Map-ах. Программы на каждый чих дергают хэши, потому скорость очень сильно завязана на скорость хэша.
| | |
| |
| |
| 4.8, Аноним (-), 14:22, 03/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если туда попадают юзерские данные, то да. Иначе злоумышленник, генерируя коллизии, заставит вашу мапку безумно тормозить.
| | |
| |
| 5.9, Аноним (-), 14:24, 03/03/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Если туда попадают юзерские данные, то да. Иначе злоумышленник, генерируя коллизии, заставит
> вашу мапку безумно тормозить.
И часто у тебя в Map-ы попадают юзерские данные в качестве ключей?
| | |
| 5.10, Аноним (-), 14:27, 03/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Если туда попадают юзерские данные, то да. Иначе злоумышленник, генерируя коллизии, заставит
> вашу мапку безумно тормозить.
И опять таки - почему криптостойкие, а не просто с защитой от hashDoS атак?
Еще раз - я не понимаю, почему криптостойкая хеш-функция должна быть быстрой. Всегда ж вроде говорилось, что она должна быть медленной, для усложнения генерации RainbowTable например (да, я знаю, что от этого нужно защищаться еще и динамической солью)
| | |
| |
| 6.12, funny_falcon (ok), 14:38, 03/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Я с тобою абсолютно согласен.
Могу только предположить, что если назвать функцию "криптостойкой", то найдутся желающие проверить её эту "криптоктойкость" - хотя бы для курсовой работы. Но уже будет стоять имя научного руководителя... в общем, понты рано или поздно обеспечены (или позор). Если понты оправдались, то вот тебе бесплатное подтверждение качества. Даже если она не окажется "криптостойкой", анализ может подтвердить её устойчивость к hashDoS, а значит ты всё равно в плюсе.
Если же не называть "криптостойкой", то можешь хоть запроверяться, но если ты сам не эксперт в криптографии, тебе всё равно никто не поверит. А других экспертов такая функция не привлечёт.
| | |
| |
| 7.13, Аноним (-), 14:46, 03/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Я с тобою абсолютно согласен.
Отлично, значит не я один не понимаю, зачем ускорять криптостойкие хеш функции :D
| | |
| |
| |
| 9.17, Аноним (-), 15:30, 03/03/2016 [^] [^^] [^^^] [ответить] | +/– | ИМХО не согласен Во первых, никто не считает хеш TCP пакетов я не про чексумы ... текст свёрнут, показать | | |
| |
| |
| 11.24, Аноним (-), 17:07, 03/03/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Секундочку, а где вторая сторона будет каждый раз новую соль брать Нельзя же де... большой текст свёрнут, показать | | |
|
| |
| 11.25, Аноним (-), 17:15, 03/03/2016 [^] [^^] [^^^] [ответить] | +/– | хранить шифрованные пароли - не особо безопаснее хранения паролей в открытом вид... большой текст свёрнут, показать | | |
| |
| |
| 13.37, angra (ok), 09:31, 04/03/2016 [^] [^^] [^^^] [ответить] | +1 +/– |  Объясняю разницу между шифрованием самим паролем и правильным использованием сол... текст свёрнут, показать | | |
| 13.38, Аноним (-), 11:32, 04/03/2016 [^] [^^] [^^^] [ответить] | +/– | Ты это серьезно Выше уже все расписали, но все равно я не могу мимо этого пройт... большой текст свёрнут, показать | | |
|
|
|
| |
| |
| |
| 13.32, Аноним (-), 19:08, 03/03/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Вот при этом и соль Дописываем ее к данным и считаем хеш Теперь если ты что-то... большой текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| |
| 19.45, Аноним (-), 17:51, 04/03/2016 [^] [^^] [^^^] [ответить] | +/– | Не, ты его сейчас зачем-то начал До этого был нормальный разговор Давай так - ... большой текст свёрнут, показать | | |
|
|
| |
| |
| 19.48, Аноним (-), 18:45, 04/03/2016 [^] [^^] [^^^] [ответить] | +/– | У меня складывается стойкое впечатление, что ты не до конца понимаешь, о чем гов... большой текст свёрнут, показать | | |
| |
| 21.56, Аноним (-), 11:32, 07/03/2016 [^] [^^] [^^^] [ответить] | +/– | не придирайся к словам тут по сути берется хеш функция от заданной парольной фр... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| 7.30, Sw00p aka Jerom (?), 18:44, 03/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>но если ты сам не эксперт в криптографии, тебе всё равно никто не поверит.
и каков критерий оценки экспертства? премия тюринга, или клэя ?
| | |
|
| 6.47, Ordu (ok), 18:14, 04/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > И опять таки - почему криптостойкие, а не просто с защитой от hashDoS атак?
Попробуйте сформулировать требование "с защитой от hashDoS атак" подробно, то есть раскрыть его подробным описанием слов в сто. Не читеря при этом, то есть не добавляя ненужных слов. А потом сделайте то же самое с требованием "криптостойкость". И финально найдите десять отличий между тем и этим.
Если вам это удастся, то расскажите об отличиях. Мне было бы интересно услышать: мне кажется, что разницы нет никакой, но я, в конечном итоге, не специалист в этих вопросах и могу ошибаться.
| | |
|
| 5.15, angra (ok), 15:10, 03/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Во-первых, без злоумышленника она будет просто тормозить всегда по сравнению с некриптостойкой хеш-функцией.
Во-вторых, криптостойкие хеш-функции от некриптостойких отличаются в первую очередь не количеством коллизий, а сложностью восстановления исходных данные по хешу.
| | |
| |
| 6.20, cebka (?), 16:17, 03/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Не знаю термина "криптостойкие" относительно хеш-функций, но, разумеется, ваше определение подходит к любой хеш функции - в общем случае исходные данные *невозможно* восстановить для любой хеш функции, т.к. пространство выходных значений всегда меньше пространства входных значений просто по определению хеш функции. А вот криптографические хеши отличаются от обычных тем, что *подобрать* к ним коллизию очень сложно для любых входных данных. Они потому и называются collision-resistant. Siphash НЕ является collision resistant хеш-функцией.
| | |
| |
| 7.35, funny_falcon (ok), 21:29, 03/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8
Цитата:
Для того, чтобы хеш-функция H считалась криптографически стойкой, она должна удовлетворять трём основным требованиям, на которых основано большинство применений хеш-функций в криптографии:
- Необратимость или стойкость к восстановлению прообраза: для заданного значения хеш-функции m не должен быть вычислен блок данных X, для которого {H(X)=m}.
- Стойкость к коллизиям первого рода или восстановлению вторых прообразов: для заданного сообщения M должно быть вычислительно невозможно подобрать другое сообщение N, для которого H(N)=H(M).
- Стойкость к коллизиям второго рода: должно быть вычислительно невозможно подобрать пару сообщений ~(M, M'), имеющих одинаковый хеш.
(Согласно третьему пункту, MD5 считается взломанной, хотя относительно первых двух пунктов пока нет)
| | |
|
| 6.31, Sw00p aka Jerom (?), 18:48, 03/03/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> в первую очередь не количеством коллизий, а сложностью восстановления исходных данные по хешу.
не в первую, но во вторую и третью, соответственно коллизиям первого и второго рода.
| | |
|
|
|
|
|
| 1.19, cebka (?), 16:12, 03/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– | |
Переделал у себя на ассемблере: https://git.io/v29iL
Производительность реально довольно хорошо подросла (я сравнивал не с sse4.2 версией, которая на x86_64 работает не быстрее generic, а с самим generic):
Refrence siphash (1KB): 0.30127492197789 sec
Optimized siphash (1KB): 0.07682267203927 sec
Refrence siphash (5B): 0.082667203852907 sec
Optimized siphash (5B): 0.032516790088266 sec
Refrence siphash (50B): 0.21968871704303 sec
Optimized siphash (50B): 0.071362769929692 sec
Highway hash интересный, но до подробного криптоанализа и до наличия reference версии без интринисков пока использовать не буду, хотя для моих задач она просто неприлично хорошо подходит.
| | |
| 1.59, erthink (ok), 13:58, 07/03/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Лучше поздно чем никогда.
HighwayHash не является официальным проектом гугла, это pet-проект нескольких сотрудников. Поэтому фразу "Компания Google представила HighwayHash" нельзя назвать полностью корректной.
Криптографическая "стойкость" HighwayHash никак не доказана. Но об этом "доказательстве" стоит упомянуть отдельно, ибо оно сводится к двум пунктам:
1) Авторы провели статистические тесты SMHasher-ом и с ними все хорошо.
Однако, буквальные результаты не были где-либо показан. Более того, был использован доработанный вариант SMHasher, исходные тексты которого авторы показывать отказались. Не были открыты даже параметры запуска/скрипты/сценарии. Поэтому невозможно воспроизвести или перепроверить результаты, либо поковыраться в них.
При этом стоит отметить что есть доработанный (более строгий) вариант SMHasher от Yves Orton, который бракует очень многие их "хороших" хеш-функций.
2) HighwayHash внутри выполняет операции аналогичные SipHash, и поэтому его стойкость следует из доказательств свойств SipHash.
Тут проблема в том, что операции всё-таки не совсем аналогичные.
Более того, внутри HighwayHash есть умножение данных на сами данные (упрощенно конечно). Поэтому в принципе возможен вектор атаки подтасовкой данных с целью получения нуля в одном из множителей. И вот никакого достойного анализа этого вектора атаки нет, только общие фразы.
Ну и напоследок, HighwayHash сильно завязан на SSE4/AVX, т.е. без них производительность катиться к неприемлемым значениям. Поэтому, лично у меня возникает вопрос - а не лучше ли просто использовать AES-NI. Даже если это делать не так наивно как в MeowHash, то все равно будет быстрее и не менее переносимо (на разных архитектурах ускорение AES работает одинаково и распространено шире, в сравнении с аналогами SSE4/AVX).
| | |
|
