forum.opennet.ru - "Представлен более эффективный метод определения префиксов ко..." (88)

"Представлен более эффективный метод определения префиксов ко..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Представлен более эффективный метод определения префиксов ко..."	+/–
Сообщение от opennews (??), 13-Май-19, 13:48
Исследователи из французского государственного института исследований в информатике и автоматике (INRIA) и Наньянского технологического университета (Сингапур) разработали (https://eprint.iacr.org/2019/459) усовершенствованный метод атаки (https://eprint.iacr.org/2019/459.pdf) на алгоритм SHA-1, существенно упрощающий создание двух разных документов с одинаковыми хэшами SHA-1. Суть метода в сведении операции полноценного подбора коллизии в SHA-1 к коллизионной атаке с заданным префиксом, при которой для существующих данных можно подобрать определённые дополнения, при которых для общего набора возникает коллизия. Иными словами, для двух существующих документов можно вычислить два дополнения, и если одно присоединить к первому документу, а другое ко второму - результирующие хэши SHA-1 для этих файлов будут одинаковы. Данный вид атаки всё ещё требует огромных вычислений и подбор дополнений остаётся сложнее, чем обычный подбор коллизий, но и практическая эффективность результата существенно выше. Если до сих пор самый быстрый метод поиска дополнений для возникновения коллизии в SHA-1 требовал выполнения 277.1 операций, то новый метод снижает число вычислений до диапазона от 266.9 до 269.4. При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям. Для сравнения на поиск обычной коллизии необходимо выполнить примерно 264.7 операций. В прошлой демонстрации Google возможности генерации разных PDF-файлов с одинаковым хэшем SHA-1 использовалась уловка с объединением в один файл двух документов, переключением видимого слоя и смещением метки выбора слоя в область возникновения коллизии. При близких затратах ресурсов (на поиск первой коллизии SHA-1 Google потратил год вычислений на кластере из 110 GPU) новый метод позволяет добиться совпадения SHA-1 для двух произвольных наборов данных. С практической стороны можно подготовить TLS-сертификаты, в которых упоминаются разные домены, но совпадают хэши SHA-1. Подобная возможность позволяет нечистому на руку удостоверяющему центру создать сертификат для цифровой подписи, которую можно применять для авторизации фиктивных сертификатов к другим доменам. Проблема также может использоваться для компрометации протоколов, полагающихся на отсутствие коллизий, таких как TLS, SSH и IPsec. Предложенная стратегия поиска дополнений для возникновения коллизии подразумевает разбиение вычислений на два этапа. На первом этапе выполняется поиск блоков, находящихся на грани коллизии, путём встраивания случайных переменных цепочек в предопределённый целевой набор различий. На втором этапе на уровне отдельных блоков полученные цепочки различий сопоставляются с приводящими к коллизиям парами состояний, используя методы традиционных атак по подбору коллизий. Несмотря на то, что теоретическая возможность атаки на SHA-1 доказана ещё в 2005 году, а на практике первая коллизия была подобрана в 2017 году, SHA-1 всё ещё остаётся в обиходе и охватывается некоторыми стандартами и технологиями (TLS 1.2, Git и т.п.). Основной целью проделанной работы было желание предоставить ещё один веский аргумент для незамедлительного прекращения использования SHA-1, особенно в сертификатах и цифровых подписях. Дополнительно можно отметить публикацию (https://eprint.iacr.org/2019/474) результатов (https://eprint.iacr.org/2019/474.pdf) криптоанализа блочных шифров SIMON-32/64 (https://en.wikipedia.org/wiki/Simon_(cipher)), разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018 (https://www.iso.org/ru/standard/70388.html). Исследователям удалось разработать метод восстановления закрытого ключа на основе двух известных пар из открытого текста и шифротекста. При ограниченных вычислительных ресурсах на подбор ключа требуется от нескольких часов до нескольких дней. Теоретический коэффициент успешности атаки оценивается в 0.25, а практический для имеющегося прототипа - 0.025. URL: https://news.ycombinator.com/item?id=19878917 Новость: https://www.opennet.me/opennews/art.shtml?num=50674
Ответить \| Правка \| Cообщить модератору

Оглавление

ну вот, опять только для товарищмайора - , Аноним (1), 13:48 , 13-Май-19, (1) +1

Майнинговую ферму свою перепрофилируй Всё больше толку от неё будет, Аноним (10), 15:12 , 13-Май-19, (10) +1

не будет майнинг это хороший вклад, прибыльный умный выбор, Аноним (48), 09:33 , 14-Май-19, (48) –2

Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сраз, GentooBoy (ok), 20:57 , 15-Май-19, (79)

Давно пора отказываться от sha1, донатер (?), 13:49 , 13-Май-19, (2) –2

Не давно, не пора Отказыватся имеет смысл там, где оно используется напрямую и в, Ivan_83 (ok), 14:27 , 13-Май-19, (4) –1

Зачем юзать старьё , Deny (?), 14:29 , 13-Май-19, (5) –8

а вы адепт автомата Калашникова на батарейках , анон (?), 15:08 , 13-Май-19, (7)

Извините,не понял аналогии Я предпочитаю использовать современные инструменты Да, Deny (?), 15:10 , 13-Май-19, (8) –4

йтись без этого,то я предпочту пользоваться современными вещами Странно,обрезало, Deny (?), 15:11 , 13-Май-19, (9) –3

Потому что дешевле с точки зрения использования ресурсов компьютера Такие вещи , Ан (??), 16:07 , 13-Май-19, (15) +2

За что платят - то и получают скупой платит дважды Именно поэтому придуманы, OpenEcho (?), 18:15 , 13-Май-19, (23)

А причем тут ак Я тащусь, если честно, с этого автомата , Аноним (45), 22:46 , 13-Май-19, (45)

Затем, что местами оно приколочено на гвозди md5 в RADIUS без вариантов , а сек, Ivan_83 (ok), 18:57 , 13-Май-19, (28) –1

там от него зависит превращение репозитария в тыкву , КО (?), 11:59 , 14-Май-19, (60)

Покажи примеры репозиториев которые превратились в тыкву из за sha1 , Ivan_83 (ok), 16:04 , 14-Май-19, (64)

HMAC is a specific type of message authentication code HMAC гарантирует защиту , OpenEcho (?), 16:19 , 13-Май-19, (18)

Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 м, Аноним (19), 16:47 , 13-Май-19, (19) +1

А мы разве живем не во времена, где paypal com abracadabra top - нормальное , к, OpenEcho (?), 17:53 , 13-Май-19, (21) –1

При атаке HMAC, злоумышленник не сможет генерировать пару 171 сообщение 187, rty (?), 18:19 , 13-Май-19, (24)

HMAC - это не шифровка, а упрощенно - цифровая подпись hmac хэш секрет сообщен, OpenEcho (?), 18:36 , 13-Май-19, (25) –2

Да, не шифровка, но цифровая подпись - шифровка хеша с помощью приватного ключа, Sw00p aka Jerom (?), 22:06 , 13-Май-19, (39)
все хеш функции по определению имеют коллизии, Sw00p aka Jerom (?), 23:43 , 13-Май-19, (47)

Речь про известный алгоритм по изменению входных данных при сохранении результир, anonymous (??), 10:00 , 14-Май-19, (51)

Про лавинный эффект забыли, Sw00p aka Jerom (?), 11:13 , 14-Май-19, (53)
не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же , КО (?), 12:02 , 14-Май-19, (61)

Практически любая функция свертки с меньшим количеством информационных битов, че, RJ (?), 11:43 , 14-Май-19, (56)

Не практически любая, а любая, GentooBoy (ok), 21:04 , 15-Май-19, (80)

hmac выглядит совсем иначе В начале там берут хэш от секрета, далее в этом хэше , Ivan_83 (ok), 16:10 , 14-Май-19, (65)

Про губку ходили слухи что там не так всё радужно , Ivan_83 (ok), 19:00 , 13-Май-19, (30) –1

И никто не стремится переезжать на sha3, я что то вообще не видел его нигде , Ivan_83 (ok), 19:01 , 13-Май-19, (31) –1

Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не, rty (?), 20:03 , 13-Май-19, (35)

Там той разницы-то code 1 1 1aopenssl speed sha1 md5The numbers are in 1000s , Аноним84701 (ok), 22:33 , 13-Май-19, (44) +2

В Вашем случае Вы, видимо, упёрлись в диск Попробуйте с tmpfs повторить этот же, anonymous (??), 09:54 , 14-Май-19, (50)

Имхо, это уже будет синтетика большие и тяжелые файлы, бэкапы и прочее обычно, Аноним84701 (ok), 11:28 , 14-Май-19, (54) +1

Во-первых диски бывают быстренькие, а-ля всякие NVMe во-вторых, бывает hash-иро, anonymous (??), 11:42 , 14-Май-19, (55)

Бывают Я немного попутал ветки и писал в контексте на самом деле нижеотписавше, Аноним84701 (ok), 12:11 , 14-Май-19, (62)

А ты уверен что это так Я где то читал что md5 хоть и сломали но в hmac он тип, Ivan_83 (ok), 18:58 , 13-Май-19, (29) –1

читали скорее всего здесь https tools ietf org html rfc6151но там есть также , OpenEcho (?), 19:56 , 13-Май-19, (34) –1
ну да, там и ксоров ключа с сообщением и с константами понадобавили вот и все, с, Sw00p aka Jerom (?), 22:11 , 13-Май-19, (40)

Я выше написал что из себя представляет hmac То что ты называешь ксором с конста, Ivan_83 (ok), 16:14 , 14-Май-19, (66)

какое извлечение там ксорится секретный ключь с магической константой, Sw00p aka Jerom (?), 19:45 , 14-Май-19, (69)

for i 0 i MD5_MSG_BLK_64CNT i k_ipad i 0x3636363636363636ull , Ivan_83 (ok), 00:54 , 15-Май-19, (70)

https ru wikipedia org wiki HMACпо википедии хеш от ключа не берется, в описан, Sw00p aka Jerom (?), 02:09 , 15-Май-19, (71)

Если публичные PGP ключи не передаются из рук в руки под подпись, то грош цена т, OpenEcho (?), 19:35 , 13-Май-19, (32) –2

Теперь у нас есть DANE для этих целей Вопрос в его поддержке софтом , xm (ok), 20:49 , 13-Май-19, (37)

Думаете гугля позволит Они так тщательно загоняют всех в CT стойло, а DANE, imh, OpenEcho (?), 21:30 , 13-Май-19, (38) –2

Ну вот в том же bitcoin core PGP-ключи используются И, с одной стороны, использ, Crazy Alex (ok), 09:53 , 14-Май-19, (49)

Не факт А то что вы не видите подмен, - это значит что у вас не таких мощносте, OpenEcho (?), 18:46 , 14-Май-19, (67) –1

Соглашусь только с одним, что PGP и его сеть доверия, основанная на взаимных под, Sw00p aka Jerom (?), 02:18 , 15-Май-19, (72)

Так именно об этом я и говорил в начале, PGP эффективен только в случае, если кл, OpenEcho (?), 15:24 , 15-Май-19, (74)

нет конечно, как ответил ниже другому коментатору, подразумевалось в смысле испо, Sw00p aka Jerom (?), 22:09 , 15-Май-19, (81)

другому коментатору - вам, сорян, Sw00p aka Jerom (?), 22:11 , 15-Май-19, (82)
Если соблюдается элементарная процедура сравнивания фингерпринта ключей между ко, OpenEcho (?), 23:12 , 15-Май-19, (83)

Не обязательно из рук в руки По любому хоть открытому каналу с аутентификацие, anonymous (??), 10:31 , 14-Май-19, (52)

Здесь в соседней новости про взлом Github-овских экаунтов Помогла аутентифика, OpenEcho (?), 19:36 , 14-Май-19, (68)

Там, вроде как, не про GitHub была речь, а про qwerty123-подобное поведение коне, anonymous (??), 20:20 , 15-Май-19, (77)

P S Переформулирую вообще да, просто так доверять никакому ключу, конечно же , anonymous (??), 20:23 , 15-Май-19, (78)
Предыдущий себеседник, приводил пример, что если персона аутефицирована, то авто, OpenEcho (?), 00:29 , 16-Май-19, (84)

так это по определению уже не открытый канал связи Обычно лично звонят по телеф, Sw00p aka Jerom (?), 02:20 , 15-Май-19, (73)

Вероятно мы живем на разных планетах, т к я никогда не видел людей, которые об, OpenEcho (?), 15:29 , 15-Май-19, (75)

так не в этом случае, имелось ввиду PGP для писем , Sw00p aka Jerom (?), 16:05 , 15-Май-19, (76)
Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручка, Sw00p aka Jerom (?), 01:55 , 16-Май-19, (85)

В одной конторе где я раньше работал, за игнор перепроверять фингерпринт SSH - п, OpenEcho (?), 02:50 , 16-Май-19, (86)

Красота , Аноним (3), 14:00 , 13-Май-19, (3) +1

Да не совсем, это вариация на тему уже показанная Google - метод создания коллиз, КО (?), 15:52 , 13-Май-19, (13) +3

поясняю, неточность в переводе статьидля любых, наперед заданных, p1 и p2 можно , КО (?), 15:56 , 13-Май-19, (14) +2

Я понял как в второй случай и это было страшно , педофил (?), 18:39 , 13-Май-19, (26) –1

Тогда получается, что можно взломать всё, куда удастся пропихнуть такой префикс , педофил (?), 15:03 , 13-Май-19, (6) –2

мне - можно Ну, если тебя совсем не насторожит бредятина в начале файла - может, товарищ майор (?), 15:38 , 13-Май-19, (11) –3

А я давно юзаю SHA-512, правда при работе с файлами, любых размеров, вплоть до 6, Мексиканец (?), 15:43 , 13-Май-19, (12) –6

тот случай, когда даже md5 избыточен, Crazy Alex (ok), 17:43 , 13-Май-19, (20) +8
Да, CRC32 не даст такой точности, куда там ему , Annoynymous (ok), 17:56 , 13-Май-19, (22)

с crc32 даже в словаре аглийских слов можно найти несколько слов с одинаковым хе, Аноним (46), 23:14 , 13-Май-19, (46)

Некоторые люди слишком страдают беспокоясь маловероятных вещей Да, я тоже Как , педофил (?), 18:46 , 13-Май-19, (27)

ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятно, Sw00p aka Jerom (?), 22:17 , 13-Май-19, (41)

Не возможно Можно только увеличить Криптографический hash отличается тем, чт, КО (?), 11:52 , 14-Май-19, (57)

Возможно, просто нужно подобрать правильный алгоритм у которого максимальный пер, Sw00p aka Jerom (?), 14:21 , 14-Май-19, (63)

Максимальный у hash значение, но его легко подделать , КО (?), 17:55 , 16-Май-19, (87)

Максимальный у Hash значение, но он нахрен не нужен - , Annoynymous (ok), 12:56 , 21-Май-19, (88)

Случайно вы не получите одинаковый хэш даже с MD5 Ну, то есть, вероятность есть,, KonstantinB (ok), 20:35 , 13-Май-19, (36) +3

у RSA даже есть свойство рефлексивности, когда m e mod n m, Sw00p aka Jerom (?), 22:23 , 13-Май-19, (42)
Случайно CRC32 получить тяжело Специально - гораздо легче , КО (?), 11:53 , 14-Май-19, (58)

АНБ оно такое АНБ , Аноним (16), 16:10 , 13-Май-19, (16)
Эта публикация - чья-то дурацкая шутка SIMON-32 64 - шифр с 32-битным блоком и , Аноним (17), 16:18 , 13-Май-19, (17) –2
Атаковать неуловимых Джо бабла не напасутся , Аноним (33), 19:39 , 13-Май-19, (33) +1
При тех же мощностях Гуглу нужно меньше двух дней, да уж безопасненько , Виталий (??), 22:32 , 13-Май-19, (43) –1

На что На то, чтобы создать сертификаты для www google com и www microsoft com , КО (?), 11:57 , 14-Май-19, (59)

Сообщения [Сортировка по времени | RSS]

1. "Представлен более эффективный метод определения префиксов ко..." +1 +/–

Сообщение от Аноним (1), 13-Май-19, 13:48

ну вот, опять только для товарищмайора :-(

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Представлен более эффективный метод определения префиксов ко..." +1 +/–

Сообщение от Аноним (10), 13-Май-19, 15:12

Майнинговую ферму свою перепрофилируй. Всё больше толку от неё будет

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

48. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от Аноним (48), 14-Май-19, 09:33

не будет. майнинг это хороший вклад, прибыльный. умный выбор

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

79. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от GentooBoy (ok), 15-Май-19, 20:57

Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сразу несколько раз.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

2. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от донатер (?), 13-Май-19, 13:49

Давно пора отказываться от sha1

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от Ivan_83 (ok), 13-Май-19, 14:27

Не давно, не пора.
Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности.
В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен.
В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Представлен более эффективный метод определения префиксов ко..." –8 +/–

Сообщение от Deny (?), 13-Май-19, 14:29

Зачем юзать старьё?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от анон (?), 13-Май-19, 15:08

а вы адепт "автомата Калашникова" на батарейках ?)

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Представлен более эффективный метод определения префиксов ко..." –4 +/–

Сообщение от Deny (?), 13-Май-19, 15:10

Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Представлен более эффективный метод определения префиксов ко..." –3 +/–

Сообщение от Deny (?), 13-Май-19, 15:11

йтись без этого,то я предпочту пользоваться современными вещами.
Странно,обрезало сообщение

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Представлен более эффективный метод определения префиксов ко..." +2 +/–

Сообщение от Ан (??), 13-Май-19, 16:07

Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

23. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 13-Май-19, 18:15

> Потому что дешевле с точки зрения использования ресурсов компьютера.
За что платят - то и получают... скупой платит дважды...
Именно поэтому придуманы PBKDF2, чтобы усложнить жизнь брутфорсу - грузить хардарь по полной.
От задач все зависит, если это авторизация, то нельзя экономить на ресурсах хардвари, если же задача проверять целостность к примеру архива, то наоборот, чем быстрей и легче хэш - тем лучше.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

45. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Аноним (45), 13-Май-19, 22:46

А причем тут ак? Я тащусь, если честно, с этого автомата.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

28. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от Ivan_83 (ok), 13-Май-19, 18:57

Затем, что местами оно приколочено на гвозди (md5 в RADIUS без вариантов), а секурность в том же гите от sha1 не зависит, там для этого другие инструменты.
А так, я же не настаиваю на sha1 в том же ssh/tls, наоборот, sha2-256 там весьма не плох, и нынче он аппаратно считается в райзенах. (sha1 тоже аппаратно считается, а вот sha2-512 нет).

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

60. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от КО (?), 14-Май-19, 11:59

>а секурность в том же гите от sha1 не зависит, т
там от него зависит превращение репозитария в тыкву.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

64. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Ivan_83 (ok), 14-Май-19, 16:04

Покажи примеры репозиториев которые превратились в тыкву из за sha1.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

18. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 13-Май-19, 16:19

"HMAC is a specific type of message authentication code"
HMAC гарантирует защиту от подмен используя Merkle-Damgård конструкцию _только_ при условии, что используемя хэш функция не имеет коллизий
MSG: казнить нельзя, помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
а теперь представте, что приказ пришел на ваше пожалование, но ваш недруг нашел коллизию в MD5 и подменил оригинал на:
MSG: казнить, нельзя помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
результат - секир башка
Это так, к слову о "безопасен"...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

19. "Представлен более эффективный метод определения префиксов ко..." +1 +/–

Сообщение от Аноним (19), 13-Май-19, 16:47

Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 мегабайт

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от OpenEcho (?), 13-Май-19, 17:53

> Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс
> в 20 мегабайт
А мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

24. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от rty (?), 13-Май-19, 18:19

"При атаке HMAC, злоумышленник не сможет генерировать пару («сообщение», «код») в удалённом (офлайн) режиме, так как злоумышленник не знает ключа K.
...
Таким образом, если скорость имеет значение, вполне приемлемо использовать MD5, а не SHA-1 в качестве встроенных хеш-функций для HMAC." Википедия
Не знаю, как работает hmac, но если положить хэш последним блоком в cbc (со случайным iv), то md5 очевидно можно использовать.  Аутентификацию нельзя будет целенаправленно нарушить, так как слабый хэш зашифрован нормальным алгоритмом.
Или же можно взять хэш сообщения вместе с iv и зашифровать отдельно.
Merkle-Damgård это модель, по которой строятся хэш-функции (а не hmac). По ней строились md5, sha1, sha2. Более современная и простая модель хэш-функций - cryptographic sponge. Представлена разработчиками sha3 keccak, по сути превращает в хэш-фунцию любой блочный шифр с достаточной длиной блока и гарантирует устойчивость, если устойчив шифр.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

25. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от OpenEcho (?), 13-Май-19, 18:36

HMAC - это не шифровка, а упрощенно - цифровая подпись:
hmac = хэш(секрет+сообщение+секрет+опционально случайность)
где только "секрет" - неизвестное значение, поэтому если хэш функция имеет коллизии, то такая подпись - фуфло

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

39. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 13-Май-19, 22:06

>HMAC - это не шифровка, а упрощенно - цифровая подпись:
Да, не шифровка, но цифровая подпись - шифровка хеша (с помощью приватного ключа в случае RSA). Минус HMAC - нужно согласовывать секретную часть, пихаемую в месте с сообщением в хеш функцию.
пс: md5('blavlablasecretstring' + 'message text') - вот банальный MAC

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

47. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 13-Май-19, 23:43

>поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
все хеш функции по определению имеют коллизии

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

51. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 14-Май-19, 10:00

Речь про известный алгоритм по изменению входных данных при сохранении результирующего hash-а.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

53. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 14-Май-19, 11:13

Про лавинный эффект забыли

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

61. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от КО (?), 14-Май-19, 12:02

не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же самое, что подобрать коллизию к уже сформированной фразе.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

56. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от RJ (?), 14-Май-19, 11:43

>если хэш функция имеет коллизии,
Практически любая функция свертки с меньшим количеством информационных битов, чем в оригинале, имеет коллизии.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

80. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от GentooBoy (ok), 15-Май-19, 21:04

Не практически любая, а любая

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

65. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Ivan_83 (ok), 14-Май-19, 16:10

hmac выглядит совсем иначе.
В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом.
Но да, ты прав насчёт того что такая функция не спасёт от подделки защищаемых данных, но зато она всё ещё гарантирует не возможность восстановить секрет.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от Ivan_83 (ok), 13-Май-19, 19:00

Про губку ходили слухи что там не так всё радужно.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

31. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от Ivan_83 (ok), 13-Май-19, 19:01

И никто не стремится переезжать на sha3, я что то вообще не видел его нигде.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

35. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от rty (?), 13-Май-19, 20:03

Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не видел.
Вместо блочного шифра с фиксированным ключом авторы keccak придумали свою функцию, которая по вроде как обладает свойствами PRP.
Максимальный размер блока у современных шифров 512 бит, а максимальный размер состояния keccak 1600 бит, поэтому как сделать лучше при сохранении размера состояния я не знаю. EME какое-нибудь.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

44. "Представлен более эффективный метод определения префиксов ко..." +2 +/–

Сообщение от Аноним84701 (ok), 13-Май-19, 22:33

> Таким образом, если скорость имеет значение, вполне приемлемо использовать MD5, а не
> SHA-1 в качестве встроенных хеш-функций для HMAC." Википедия
Там той разницы-то.

1.1.1a
openssl speed sha1 md5
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5              63567.75k   189543.98k   342348.63k   440408.41k   472910.51k   473989.12k
sha1             65960.44k   161510.22k   306319.40k   397563.96k   432395.61k   435563.18k
1.0.2r
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              36231.18k   124193.78k   277993.54k   408510.01k   470129.73k
sha1             45284.49k   125546.04k   262676.74k   376613.89k   428378.79k

И

% time md5 ~/deb.vdi
MD5 (deb.vdi) = 0a68ba66a96e91e58e44b79f1428190a
md5 deb.vdi  7,70s user 1,68s system 89% cpu 10,450 total
...
md5 deb.vdi  7,80s user 0,91s system 99% cpu 8,721 total
% time sha1 deb.vdi
SHA1 (deb.vdi) = fbd6d7f78305df497ea8ccef4547cf11a406817c
sha1 deb.vdi  10,13s user 1,03s system 99% cpu 11,177 total
...
sha1 deb.vdi  10,30s user 0,80s system 99% cpu 11,112 total

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

50. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 14-Май-19, 09:54

В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с tmpfs повторить этот же эксперимент.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

54. "Представлен более эффективный метод определения префиксов ко..." +1 +/–

Сообщение от Аноним84701 (ok), 14-Май-19, 11:28

> В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с tmpfs повторить этот же эксперимент.
Имхо, это уже будет синтетика ("большие и тяжелые" файлы, бэкапы и прочее обычно все же хранятся на дисках, где все упирается в ИО).
Тем более, это вообще-то был SSD, да еще и несколько повторов (кэш) - ну и "openssl speed" тоже не привязан к диску ;)
Но повторил c tmpfs (по 2 повтора):

% dd if=/tmp/deb.vdi bs=1M of=/dev/null
2787+0 records in
2787+0 records out
2922381312 bytes (2,9 GB, 2,7 GiB) copied, 0,976803 s, 3,0 GB/s
% time md5 deb.vdi
MD5 (deb.vdi) = 0a68ba66a96e91e58e44b79f1428190a
md5 deb.vdi  7,78s user 0,76s system 99% cpu 8,541 total
md5 deb.vdi  7,99s user 0,75s system 99% cpu 8,755 total
% time sha1 deb.vdi
SHA1 (deb.vdi) = fbd6d7f78305df497ea8ccef4547cf11a406817c
sha1 deb.vdi  10,46s user 0,65s system 99% cpu 11,123 total
sha1 deb.vdi  10,39s user 0,75s system 99% cpu 11,148 total
% time sha256 deb.vdi
SHA256 (deb.vdi) = c62f00e59f04558e6e39cdbed3381ba0f47ca317cd2552969420beaabdd97d5f
sha256 deb.vdi  25,85s user 0,83s system 99% cpu 26,711 total
sha256 deb.vdi  25,16s user 0,70s system 99% cpu 25,879 total
% time sha384 deb.vdi
SHA384 (deb.vdi) = 2d313110e85163fe6df70ef1a12fe84d236accfef351d259d6ec0eefcf06f7272605fe302db2ef5120bd1e8058e18516
sha384 deb.vdi  17,32s user 0,68s system 99% cpu 18,013 total
sha384 deb.vdi  16,86s user 0,72s system 99% cpu 17,594 total
% time sha512 deb.vdi
SHA512 (deb.vdi) = 46c64d043055257af5ab321afa239c20b850d069ee08b0028499be264c0de3ad4e378af3c29c71558d58b71623bacd003b02987459b03ca4c5dd8477e1053135
sha512 deb.vdi  16,71s user 0,76s system 99% cpu 17,474 total
sha512 deb.vdi  16,93s user 0,72s system 99% cpu 17,665 total

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

55. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 14-Май-19, 11:42

> Имхо, это уже будет синтетика ("большие и тяжелые" файлы, бэкапы и прочее обычно все же хранятся на дисках, где все упирается в ИО).
Во-первых диски бывают быстренькие, а-ля всякие NVMe; во-вторых, бывает hash-ирование на лету (без работы с диском).
> Тем более, это вообще-то был SSD,
Я неправильно прочитал вывод time-а, sorry.
И Вы правы (перепроверил на своей машине, только что): действительно утилиты sha1sum и md5sum работают с примерно одинаковой скоростью:
$ time md5sum dump
4c37decbf524ac3abced1e33132833d6  dump
real    0m3,997s
user    0m3,700s
sys     0m0,289s
$ time sha1sum dump
1bbe8f39f30d3a97528d87c5db87b1a72bf7f1f4  dump
real    0m4,438s
user    0m4,129s
sys     0m0,300s

А если выбрать более аккуратную реализацию, то sha1 даже быстрее будет (спец. инструкции в процессоре?):
$ time openssl md5 dump
MD5(dump)= 4c37decbf524ac3abced1e33132833d6
real    0m3,881s
user    0m3,589s
sys     0m0,292s
$ time openssl sha1 dump
SHA1(dump)= 1bbe8f39f30d3a97528d87c5db87b1a72bf7f1f4
real    0m2,818s
user    0m2,510s
sys     0m0,308s

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

62. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Аноним84701 (ok), 14-Май-19, 12:11

>> Имхо, это уже будет синтетика ("большие и тяжелые" файлы, бэкапы и прочее обычно все же хранятся на дисках, где все упирается в ИО).
> Во-первых диски бывают быстренькие, а-ля всякие NVMe; во-вторых, бывает hash-ирование на лету (без работы с диском).
Бывают.
Я немного попутал ветки и писал в контексте (на самом деле нижеотписавшегося) #12, с его бэкапами blu-ray изо "бэкапы хранятся на HDD и M-Disc."
> А если выбрать более аккуратную реализацию, то sha1 даже быстрее будет (спец.
> инструкции в процессоре?):
> $ time openssl md5 dump
> MD5(dump)= 4c37decbf524ac3abced1e33132833d6
> real    0m3,881s
...
> real    0m2,818s
Слышал краем уха
https://en.wikipedia.org/wiki/Intel_SHA_extensions
Однако:

% time openssl md5 deb.vdi
MD5(deb.vdi)= 0a68ba66a96e91e58e44b79f1428190a
openssl md5 deb.vdi  6,67s user 0,96s system 99% cpu 7,649 total
openssl md5 deb.vdi  6,72s user 0,82s system 99% cpu 7,550 total
% time openssl sha1 deb.vdi
SHA1(deb.vdi)= fbd6d7f78305df497ea8ccef4547cf11a406817c
openssl sha1 deb.vdi  7,07s user 0,96s system 99% cpu 8,045 total
openssl sha1 deb.vdi  7,47s user 0,82s system 99% cpu 8,302 total

Хотя это тоже баловство, по хорошему нужно отключить энергосбережение и в single-user  моде cделать хотя бы пару десятков повторов.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

29. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от Ivan_83 (ok), 13-Май-19, 18:58

А ты уверен что это так?
Я где то читал что md5 хоть и "сломали" но в hmac он типа всё ещё безопасен.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

34. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от OpenEcho (?), 13-Май-19, 19:56

> Я где то читал что md5 хоть и "сломали" но в hmac
> он типа всё ещё безопасен.
читали скорее всего здесь:
https://tools.ietf.org/html/rfc6151
но там есть также: "for a new protocol design, a ciphersuite with HMAC-MD5 should not be included"
атака с вероятностью 0.87:
https://www.iacr.org/archive/eurocrypt2009/54790122/54790122...

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

40. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 13-Май-19, 22:11

> но в hmac он типа всё ещё безопасен.
ну да, там и ксоров ключа с сообщением и с константами понадобавили вот и все, сам по себе HMAC это, что-то вроде
md5('blablablasecretstring' + 'message text')

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

66. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Ivan_83 (ok), 14-Май-19, 16:14

Я выше написал что из себя представляет hmac.
То что ты называешь ксором с константами - на самом деле извлечение отдельных битов из байтов хэша секрета.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

69. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 14-Май-19, 19:45

какое извлечение? там ксорится секретный ключь с магической константой

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

70. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Ivan_83 (ok), 15-Май-19, 00:54

    for (i = 0; i < MD5_MSG_BLK_64CNT; i ++) {
        k_ipad[i] ^= 0x3636363636363636ull;
        hctx->k_opad[i] ^= 0x5c5c5c5c5c5c5c5cull;
    }
    /* Perform inner MD5. */
    md5_update(&hctx->ctx, (uint8_t*)k_ipad, sizeof(k_ipad));
0x36 = 00110110
0x5c = 01011100
ну да - не извлекаются биты, я чёт подзабыл малость, но только не ключ а его хэш, если ключ больше размера блока хэша.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

71. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 02:09

> но только не ключ а его хэш, если ключ больше размера блока хэша.
https://ru.wikipedia.org/wiki/HMAC
по википедии хеш от ключа не берется, в описании алгоритма шаги 2 и 3.
Si = XOR(K0, ipad)
So = XOR(K0, opad)
ipad и opad - магические константы.
пс: как тут вставлять мат формулы из вики?
HMAC(K, text) => H( (K xor OPAD) || H( (K xor IPAD) || text ) )
K - секретный ключ
text - открытый текст
OPAD, IPAD - магические константы (0x5c, 0x36)
H - собственно выбранная хеш функция
|| - символ конкатенации строк
xor - операция побитового исключающего ИЛИ

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

32. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от OpenEcho (?), 13-Май-19, 19:35

>для безопасности там pgp прикручивается сбоку.
Если публичные PGP ключи не передаются из рук в руки под подпись, то грош цена такой безопасности c PGP/GPG. Я как то показывал FreeBSD проекту как я стал "security-officer" зарегистрировав на MIT-ишном сервере ключей свой ключ 5180E90F с таким же именем. Никаких проблем, каждый это может сделать.
Или должны быть 3rd party центры сертификации, которые проверяют паспорт и соответствие физиономии и подписывают своим ключом и несут ответственность за верификацию или передавать публичные ключи из рук в руки(как это делается в банках), иначе нет никакой гарантии, что ключ, которым подписали принадлежит действительно хозяину, только надежда, не больше, что это правда тот за кого себя выдает.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

37. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от xm (ok), 13-Май-19, 20:49

Теперь у нас есть DANE для этих целей. Вопрос в его поддержке софтом.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от OpenEcho (?), 13-Май-19, 21:30

Думаете гугля позволит? Они так тщательно загоняют всех в CT стойло, а DANE, imho для них облом

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

49. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Crazy Alex (ok), 14-Май-19, 09:53

Ну вот в том же bitcoin core PGP-ключи используются. И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии, с другой - это был бы лакомый кусок для атаки (основной биткоин клиент же). И как-то подмен не видать, хотя большая часть пользователей не получала ключи "из рук в руки". Достаточно, что эти ключи перекрёстно подписаны и опубликованы во многих источниках.
P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы ключ принадлежал той самой сущности, что коммиты делает, а так будь это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности репы некритично совершенно.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

67. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от OpenEcho (?), 14-Май-19, 18:46

> И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии,
Не факт...

> И как-то подмен не видать, хотя большая часть пользователей не получала
> ключи "из рук в руки".
А то что вы не видите подмен, - это значит что у вас не таких мощностей и доступа. Блокчэин не так уж хорошо защищен как вы думаете, - атака "51%" уже была успешно применена как миниум на 5-ти криптовалютах.
Оставим майнеров и посмотрим на простейшее. Предположим я имею возможность следить за вами, за всеми вашими девайсами и точками входа в интернет. Дальше все очень просто:
перехват вашего конекта, генерация новых ключей и отправка контента от вашего имени с моими ключами, на обратке - перепаковка с вашими ключами и доставка на ваши девайсы. Classic MITM атака. Помог PGP/GPG если ключи не были переданы из рук в руки?
> Достаточно, что эти ключи перекрёстно подписаны
> и опубликованы во многих источниках.
Ну а теперь - честно, как  много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и  перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были случаи компроментирования и на довольно известных проектах.

> P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы
> ключ принадлежал той самой сущности, что коммиты делает, а так будь
> это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности
> репы некритично совершенно.
о какой безопасности речь ???
X = сущность
Y = issued-by(X)
верить Y которая принадлежит X ???
а еще X может генерить новые ключи каждый день...
и тогда вообще не понятно, а та ли это сущность X

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

72. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 02:18

>Ну а теперь - честно, как  много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и >рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и  >перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет >механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были >случаи компроментирования и на довольно известных проектах
Соглашусь только с одним, что PGP и его сеть доверия, основанная на взаимных подписываниях ключей всей сетью, не спасет от так называемого "внедрения" злоумышленника в эту сеть, особенно в современных реалиях, когда порой эта сеть доверия состоит из людей которые друг друга в глаза не видели, а чисто по ынтернету.
Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему каналу связи (при личной встрече, по телефону и т.д.)

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

74. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 15-Май-19, 15:24

> Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему
> каналу связи (при личной встрече, по телефону и т.д.)
Так именно об этом я и говорил в начале, PGP эффективен только в случае, если ключи передаются из рук в руки (если вы знаете голос человека, его повадки, то можно и через телефон, но самое надежное - как в банках - из рук в руки и под подпись)
Но это все работает только в случаях личных знакомств, верить же PGP подписям на Github для примера, где вы не знаете кореспондента лично или в случаях с бинарными пакетами в юникс системах - это просто вера на слово. Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

81. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 22:09

> Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?
нет конечно, как ответил ниже другому коментатору, подразумевалось в смысле использования PGP при шифровании писем.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

82. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 22:11

"другому коментатору" - вам, сорян

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

83. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 15-Май-19, 23:12

>подразумевалось в смысле использования PGP при шифровании писем.
Если соблюдается элементарная процедура сравнивания фингерпринта ключей между кореспондентами то проблем с PGP шифровкой нет.
Я же говорю о массом применении PGP в Git, в подписях операционных систем и пакетов и т.к. далее, где практически доверия ключам нет, т.к. большинство людей не знают тех, кто стоит за этими ключами. Мы просто верим на слово, что ключи и правда принадлежат хозяевам.

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

52. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 14-Май-19, 10:31

Не обязательно из рук в руки. По любому (хоть открытому) каналу с аутентификацией отправителя и гарантей сохранности сообщения.
Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю, другому ключу (владелец которого достоверно известен) и т.п.
Да и вообще в культуре использования PGP (из того что видел я) два одновременных валидных ключа на один ящик вызывают вопросы и повышенную осторожность.
Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для вашего закрытого ключа).

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

68. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 14-Май-19, 19:36

> Не обязательно из рук в руки. По любому (хоть открытому) каналу с
> аутентификацией отправителя и гарантей сохранности сообщения.
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь
> на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю
Здесь в соседней новости про взлом  Github-овских экаунтов...
Помогла аутентификация?
> , другому ключу (владелец которого достоверно известен) и т.п.
Где эта самая достоверность в PGP/GPG ?

> Да и вообще в культуре использования PGP (из того что видел я)
> два одновременных валидных ключа на один ящик вызывают вопросы и повышенную
> осторожность.
И много вы знаете реальных людей, которые вообще смотрят за ключами и добросовестно сверяют с публичными key серверами сколько там ключей? Это хорошо если они там вообще опубликованы.
Вот именно, что кроме вызывания вопросов, текущая культура примения PGP ключей не вызывает больше ничего. Ну да, механизм криптографии высок, а толку от него если origin unknown ?
Видимость надежности, но не надежность т.к. без достоверной 100% гарантии принадлежности ключа - это не надежней чем просто верить на слово
> Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё
> равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для
> вашего закрытого ключа).
Элементарная MITM атака и прийдет пушистый, белый арктический зверек

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

77. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 15-Май-19, 20:20

> Здесь в соседней новости про взлом  Github-овских экаунтов...
> Помогла аутентификация?
Там, вроде как, не про GitHub была речь, а про qwerty123-подобное поведение конечных пользователей и тупо публикацию своих логинов-паролей.
При такой культуре IT никакая технологий не поможет защитить данные.
А даже если бы утекали пароли из базы GitHub-а (что вряд ли), то они поддерживают двух-факторную авторизацию (в том числе по всяким Trezor-ам). А даже если бы этот механизм был дискредитирован, то это лишь говорит о том, чтобы не использовать GitHub для этих целей (каждый сам управляет рисками и надёжностью какого-либо метода аутентификации).
В общем, IMHO, плохой пример :)
> Где эта самая достоверность в PGP/GPG ?
После того, как публичный ключ был аутентифицирован по сторонним каналам, PGP даёт достоверность автора сообщений (подписи) и безопасность содержимого от посторонних лиц (шифрование)
Ну и стоит отметить, что в PGP есть Web-Of-Trust, и при грамотном приминении это тоже является инструментом аутентификации (когда доверенные лица произвели аутентификацию по сторонним каналам за вас, а вы уже используете этот результат).
> И много вы знаете реальных людей, которые вообще смотрят за ключами и добросовестно сверяют с публичными key серверами сколько там ключей? Это хорошо если они там вообще опубликованы.
Все известные мне активные пользователи инфраструктуры PGP ведут себя именно так. Жаль только, что таких мало. Я сам являюсь самым халатным пользователем PGP из данного локального окружения, как мне кажется, но даже я проверяю при поиске/добавлении новых ключей.
> Вот именно, что кроме вызывания вопросов, текущая культура примения PGP ключей не вызывает больше ничего.
Не понял вас. Под вопросами я имел в виду вопросы одного пользователя PGP-инфраструктуры к другому по сторонним/доверенным каналам (обычно IRL или посредством почты для которой уже проведена аутентификация ключа) на тему чему именно из этого доверять.
> Элементарная MITM атака и прийдет пушистый, белый арктический зверек
Элементарная MitM-атака? Это как? Как она становится элементарной? Просто провести атаку на BGP/DNS и PKI одновременно, чтобы перехватить письмо, в надежде, что его ещё пошлют зашифровав неверным ключом?
Да, такие риски действительно присутствуют, но если мы говорим в контексте неграмотного использования PGP, то не такие уж они и высокие. Для людей, кому действительно важно сократить риски, могут тупо грамотно применять PGP, а не слать что попало куда попало и как попало.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

78. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от anonymous (??), 15-Май-19, 20:23

P.S.: Переформулирую: вообще да, просто так доверять никакому ключу, конечно же не стоит. А если есть дополнительные подозрительнеы признаки (а-ля лишние ключи), то нужно быть вдвое осторожным. Но обычно люди используют сторонние аутентицирующие каналы, и это не всегда встречал IRL с паспортом в руке (тем более, если человека знаешь много лет).

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

84. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 16-Май-19, 00:29

> Там, вроде как, не про GitHub была речь, а про qwerty123-подобное поведение
> конечных пользователей и тупо публикацию своих логинов-паролей.
Предыдущий себеседник, приводил пример, что если персона аутефицирована, то автоматом можно верить его ключам. Я привел пример, что в случае как на гитхабе - это не работает.
> При такой культуре IT никакая технологий не поможет защитить данные.
Не совсем, если бы PGP ключи использовались так же как в SSL, то потеря логина/пароля к эккаунту не позволила бы нарушения целостности подписаного проекта.

> А даже если бы утекали пароли из базы GitHub-а (что вряд ли),
> то они поддерживают двух-факторную авторизацию (в том числе по всяким Trezor-ам).
2FA авторизация тоже не панацея, уже была масса взломов эккаутов защищенных 2FA.
В общей массе 2FA привязывают к телефону и в случае его компроментации все накрывается ... ну вы знаете чем.
>> Где эта самая достоверность в PGP/GPG ?
> После того, как публичный ключ был аутентифицирован по сторонним каналам, PGP даёт
> достоверность автора сообщений (подписи) и безопасность содержимого от посторонних лиц
> (шифрование)
Вот именно это я и пытаюсь сказать. Проблема то в том, что никто не делает эту самую проверку в случаях как с гитовскими публичными репами или проверка достоверности мэйнтеров пакетов в OS-ях.
> Ну и стоит отметить, что в PGP есть Web-Of-Trust, и при грамотном
> приминении это тоже является инструментом аутентификации (когда доверенные лица произвели
> аутентификацию по сторонним каналам за вас, а вы уже используете этот
> результат).
Я вам скажу больше, что я сам наивно играл в Web-of-trust, посидеть в кафешки, поболтать с  такими же чекнутыми фанатиками как и сам и сделать перекрестные подписи ключей... Это все работает к сожалению только для малых груп фанатиков-параноиков. Я же акцентирую на том, что даже эти механизмы не применяются в крупных проектах и  мы слепо верим что очередной релиз какой нибудь OS и правда подписан теми за кого они себя выдают. Тоже самое относится к популярным гитхабовским проектам.
Как много вы там видели перекрестно-подписанных ключей?
Если раньше можно было еще покопаться на публичных PGP-key серверах чтобы найти правду, то сейчас эти сервера дышат на ладан, даже MIT очень часто падает в 503. Плюс отсутствие элементарной защиты емэйлов на таких серверах, отворачивают желание людей публиковать там ключи, ибо спамеры не спят
> Все известные мне активные пользователи инфраструктуры PGP ведут себя именно так. Жаль
> только, что таких мало.
Вот и я об этом же, что нас мало, а остальные, не побоюсь сказать - большинство, вообще не заморачиваются с проверками ключей, а свято верят в PGP, не понимая механизма его работы.
> Не понял вас. Под вопросами я имел в виду вопросы одного пользователя
> PGP-инфраструктуры к другому по сторонним/доверенным каналам (обычно IRL или посредством
> почты для которой уже проведена аутентификация ключа) на тему чему именно
> из этого доверять.
Мой самый первый пост относительно PGP:
Если PGP ключи перепроверены, переданы из рук в руки или на худой конец сверены по телефону, то все Ok. Если же этого не делать (что есть массово) то PGP - не работает, это тоже самое как просто свято верить...
> Элементарная MitM-атака? Это как? Как она становится элементарной? Просто провести атаку
> на BGP/DNS и PKI одновременно, чтобы перехватить письмо, в надежде, что
> его ещё пошлют зашифровав неверным ключом?
а кто по вашему делает MITM атаки?
Те, у кого есть техническая возможность. Это абсолютно нормальная практика в больших конторах для предотвращения утечек, я уж не говорю о товарищах майорах.
> Да, такие риски действительно присутствуют, но если мы говорим в контексте неграмотного
> использования PGP, то не такие уж они и высокие.
Ну это все относительно. Если чувак послал своей девушке PGP просьбу прислать пароль от ее инстаграма, то скорей всего он на фиг никому не нужен, а вот если что посерьёзней, так для этого есть 5 eyes и яровая.

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

73. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 02:20

> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS
так это по определению уже не открытый канал связи. Обычно лично звонят по телефону и посимвольно сверяют фингерпринт.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

75. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 15-Май-19, 15:29

> Обычно лично звонят
> по телефону и посимвольно сверяют фингерпринт.
Вероятно мы живем на разных планетах, т.к. я никогда не видел людей, которые "обычно звонят"  в debian/CentOS/Gentoo... перед установкой операционки и при установке пакетов для сверки фингерпринта.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

76. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 15-Май-19, 16:05

>перед установкой операционки и при установке пакетов для сверки фингерпринта
так не в этом случае, имелось ввиду PGP для писем.

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

85. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 16-Май-19, 01:55

Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками его потом на сервере проверить, а мы про pgp разговариваем. Много ли таких людей кто сверяет? А в случае с виртуальными машинами и их клонами, многие ли перегенерировали хост ключи? Новость даже такая была.

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

86. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от OpenEcho (?), 16-Май-19, 02:50

> Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками
> его потом на сервере проверить, а мы про pgp разговариваем.
В одной конторе где я раньше работал, за игнор перепроверять фингерпринт SSH - просто увольняли.
> Много ли таких людей кто сверяет? А в случае с виртуальными машинами
> и их клонами, многие ли перегенерировали хост ключи? Новость даже такая
> была.
Вот это самый главный вопрос !!!
Не понимание элементарного механизма в технологиях криптографии просто исключает сам смысл этих технологий.
Банально все сводится - "а я как у всех"... грустно...

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

3. "Представлен более эффективный метод определения префиксов ко..." +1 +/–

Сообщение от Аноним (3), 13-Май-19, 14:00

> коллизия возникает при наличии определённых префиксов, независимо от остальных данных в наборе
Красота.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Представлен более эффективный метод определения префиксов ко..." +3 +/–

Сообщение от КО (?), 13-Май-19, 15:52

Да не совсем, это вариация на тему уже показанная Google - метод создания коллизии, не метод подбора к существующему hash.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

14. "Представлен более эффективный метод определения префиксов ко..." +2 +/–

Сообщение от КО (?), 13-Май-19, 15:56

поясняю, неточность в переводе статьи
для любых, наперед заданных, p1 и p2 можно подобрать такие m1 и m2, что
hash(p1||m1)=hash(p2||m2)
это не совсем тоже самое, что в переводе, что есть такие p1 и p2, что что не пиши в m1 и m2, результат хеширования не меняется. :)

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

26. "Представлен более эффективный метод определения префиксов ко..." –1 +/–

Сообщение от педофил (?), 13-Май-19, 18:39

Я понял как в второй случай и это было страшно.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

6. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от педофил (?), 13-Май-19, 15:03

Тогда получается, что можно взломать всё, куда удастся пропихнуть такой префикс? А это может стать отдельной уязвимостью?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Представлен более эффективный метод определения префиксов ко..." –3 +/–

Сообщение от товарищ майор (?), 13-Май-19, 15:38

мне - можно. Ну, если тебя совсем не насторожит бредятина в начале файла - может.
А если ты для себя, любимого спрашивает - у тебя не хватит ресурсов.
И твоя майнинговая ферма по сравнению с моей - курам на смех (нет, ты думал, те китайские заводы по прозводству битков - крестьяне с рисовых полей вскладчину строили?)

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "Представлен более эффективный метод определения префиксов ко..." –6 +/–

Сообщение от Мексиканец (?), 13-Май-19, 15:43

> веский аргумент для незамедлительного прекращения использования SHA-1, особенно в сертификатах и цифровых подписях.
А я давно юзаю SHA-512, правда при работе с файлами, любых размеров, вплоть до 60 Gb (копии iso blu-ray)
Не скажу, что сумма вычисляется долго на моём 6900K, но для меня важна 100% подлинность файла, особенно, когда бэкапы хранятся на HDD и M-Disc.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Представлен более эффективный метод определения префиксов ко..." +8 +/–

Сообщение от Crazy Alex (ok), 13-Май-19, 17:43

тот случай, когда даже md5 избыточен

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Annoynymous (ok), 13-Май-19, 17:56

Да, CRC32 не даст такой точности, куда там ему.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

46. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Аноним (46), 13-Май-19, 23:14

с crc32 даже в словаре аглийских слов можно найти несколько слов с одинаковым хешем. но конечно лучше чем ничего.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

27. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от педофил (?), 13-Май-19, 18:46

Некоторые люди слишком страдают беспокоясь маловероятных вещей. Да, я тоже.
Как избавиться от такого?
Хеши  - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов. По идее. Нормальные люди не задумываются.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

41. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 13-Май-19, 22:17

>Хеши  - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов.
ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

57. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от КО (?), 14-Май-19, 11:52

>ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
Не возможно. Можно только увеличить. :)
Криптографический hash отличается тем, что вычислить другие варианты оригиналов сложно (в идеале не проще полного перебора комбинаций).
Но при этом вероятность того, что ваш меганакрученный пароль из ста слов имеет коллизию с одним символом пробел, тоже можно лишь попробовав. :)

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

63. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 14-Май-19, 14:21

Возможно, просто нужно подобрать правильный алгоритм у которого максимальный период исчерпаемости

Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

87. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от КО (?), 16-Май-19, 17:55

Максимальный у hash=значение, но его легко подделать :)

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

88. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Annoynymous (ok), 21-Май-19, 12:56

> Максимальный у hash=значение, но его легко подделать :)
Максимальный у Hash>>значение, но он нахрен не нужен :-)

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

36. "Представлен более эффективный метод определения префиксов ко..." +3 +/–

Сообщение от KonstantinB (ok), 13-Май-19, 20:35

Случайно вы не получите одинаковый хэш даже с MD5.
Ну, то есть, вероятность есть, но примерно такая же, как вероятность падения метеорита вам на голову.
А если к вашим HDD с бэкапами имеют неограниченный доступ посторонние люди, то скорее этот вопрос надо решать.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

42. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Sw00p aka Jerom (?), 13-Май-19, 22:23

у RSA даже есть свойство рефлексивности, когда m^e mod n = m

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

58. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от КО (?), 14-Май-19, 11:53

>Случайно вы не получите одинаковый хэш даже с MD5.
Случайно CRC32 получить тяжело. Специально - гораздо легче.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

16. "Представлен более эффективный метод определения префиксов ко..." +/–

Сообщение от Аноним (16), 13-Май-19, 16:10

> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018
АНБ оно такое АНБ.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Представлен более эффективный метод определения префиксов ко..." –2 +/–

Сообщение от Аноним (17), 13-Май-19, 16:18

> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018.
Эта публикация - чья-то дурацкая шутка. SIMON-32/64 - шифр с 32-битным блоком и 64-битным ключом. 64-битный "блок" YHWHYHWH, который они зашифровывают - это на самом деле 32-битный блок YHWH, повторенный 2 раза. Сложность задачи от того, что блок повторён дважды, не возрастает. Для того, чтобы найти ключ, превращающий YHWHYHWH в YHWHYHWH, достаточно перебрать 2^32 ключей. Это несколько дней брутфорса на современной персоналке. Это вовсе не означает, что шифр скомпрометирован - это верно для любого шифра с 32-битным блоком. Они же выставляют это как "достижения", доказывающие, что они скомпрометировали шифр. Уберите эту чушь из новости.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Представлен более эффективный метод определения коллизий для..." +1 +/–

Сообщение от Аноним (33), 13-Май-19, 19:39

>При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям.
Атаковать неуловимых Джо бабла не напасутся.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Представлен более эффективный метод определения коллизий для..." –1 +/–

Сообщение от Виталий (??), 13-Май-19, 22:32

При тех же мощностях Гуглу нужно меньше двух дней, да уж безопасненько)))

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Представлен более эффективный метод определения коллизий для..." +/–

Сообщение от КО (?), 14-Май-19, 11:57

На что? На то, чтобы создать сертификаты для www.google.com и www.microsoft.com с одинаковой подписью? Да. Но они оба будут игнорироваться браузером, потому что ему нужна другая.
Вот запороть git репо можно. Но цена вопроса в 100 тыс баксов. :)

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Представлен более эффективный метод определения префиксов ко..."	+1 +/–
Сообщение от Аноним (1), 13-Май-19, 13:48
ну вот, опять только для товарищмайора :-(
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	10. "Представлен более эффективный метод определения префиксов ко..."	+1 +/–
	Сообщение от Аноним (10), 13-Май-19, 15:12
	Майнинговую ферму свою перепрофилируй. Всё больше толку от неё будет
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	48. "Представлен более эффективный метод определения префиксов ко..."	–2 +/–
	Сообщение от Аноним (48), 14-Май-19, 09:33
	не будет. майнинг это хороший вклад, прибыльный. умный выбор
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	79. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от GentooBoy (ok), 15-Май-19, 20:57
	Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сразу несколько раз.
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору

2. "Представлен более эффективный метод определения префиксов ко..."	–2 +/–
Сообщение от донатер (?), 13-Май-19, 13:49
Давно пора отказываться от sha1
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Представлен более эффективный метод определения префиксов ко..."	–1 +/–
	Сообщение от Ivan_83 (ok), 13-Май-19, 14:27
	Не давно, не пора. Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности. В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен. В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "Представлен более эффективный метод определения префиксов ко..."	–8 +/–
	Сообщение от Deny (?), 13-Май-19, 14:29
	Зачем юзать старьё?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	7. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от анон (?), 13-Май-19, 15:08
	а вы адепт "автомата Калашникова" на батарейках ?)
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	8. "Представлен более эффективный метод определения префиксов ко..."	–4 +/–
	Сообщение от Deny (?), 13-Май-19, 15:10
	Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "Представлен более эффективный метод определения префиксов ко..."	–3 +/–
	Сообщение от Deny (?), 13-Май-19, 15:11
	йтись без этого,то я предпочту пользоваться современными вещами. Странно,обрезало сообщение
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	15. "Представлен более эффективный метод определения префиксов ко..."	+2 +/–
	Сообщение от Ан (??), 13-Май-19, 16:07
	Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	23. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от OpenEcho (?), 13-Май-19, 18:15
	> Потому что дешевле с точки зрения использования ресурсов компьютера. За что платят - то и получают... скупой платит дважды... Именно поэтому придуманы PBKDF2, чтобы усложнить жизнь брутфорсу - грузить хардарь по полной. От задач все зависит, если это авторизация, то нельзя экономить на ресурсах хардвари, если же задача проверять целостность к примеру архива, то наоборот, чем быстрей и легче хэш - тем лучше.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	45. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Аноним (45), 13-Май-19, 22:46
	А причем тут ак? Я тащусь, если честно, с этого автомата.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	28. "Представлен более эффективный метод определения префиксов ко..."	–1 +/–
	Сообщение от Ivan_83 (ok), 13-Май-19, 18:57
	Затем, что местами оно приколочено на гвозди (md5 в RADIUS без вариантов), а секурность в том же гите от sha1 не зависит, там для этого другие инструменты. А так, я же не настаиваю на sha1 в том же ssh/tls, наоборот, sha2-256 там весьма не плох, и нынче он аппаратно считается в райзенах. (sha1 тоже аппаратно считается, а вот sha2-512 нет).
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	60. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от КО (?), 14-Май-19, 11:59
	>а секурность в том же гите от sha1 не зависит, т там от него зависит превращение репозитария в тыкву.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	64. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Ivan_83 (ok), 14-Май-19, 16:04
	Покажи примеры репозиториев которые превратились в тыкву из за sha1.
	Ответить \| Правка \| ^ к родителю #60 \| Наверх \| Cообщить модератору


	18. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от OpenEcho (?), 13-Май-19, 16:19
	"HMAC is a specific type of message authentication code" HMAC гарантирует защиту от подмен используя Merkle-Damgård конструкцию _только_ при условии, что используемя хэш функция не имеет коллизий MSG: казнить нельзя, помиловать! HMAC: e46dfec0d4136e82abc5ff88d6f01f86 а теперь представте, что приказ пришел на ваше пожалование, но ваш недруг нашел коллизию в MD5 и подменил оригинал на: MSG: казнить, нельзя помиловать! HMAC: e46dfec0d4136e82abc5ff88d6f01f86 результат - секир башка Это так, к слову о "безопасен"...
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	19. "Представлен более эффективный метод определения префиксов ко..."	+1 +/–
	Сообщение от Аноним (19), 13-Май-19, 16:47
	Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 мегабайт
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	21. "Представлен более эффективный метод определения префиксов ко..."	–1 +/–
	Сообщение от OpenEcho (?), 13-Май-19, 17:53
	> Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс > в 20 мегабайт А мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	24. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от rty (?), 13-Май-19, 18:19
	"При атаке HMAC, злоумышленник не сможет генерировать пару («сообщение», «код») в удалённом (офлайн) режиме, так как злоумышленник не знает ключа K. ... Таким образом, если скорость имеет значение, вполне приемлемо использовать MD5, а не SHA-1 в качестве встроенных хеш-функций для HMAC." Википедия Не знаю, как работает hmac, но если положить хэш последним блоком в cbc (со случайным iv), то md5 очевидно можно использовать. Аутентификацию нельзя будет целенаправленно нарушить, так как слабый хэш зашифрован нормальным алгоритмом. Или же можно взять хэш сообщения вместе с iv и зашифровать отдельно. Merkle-Damgård это модель, по которой строятся хэш-функции (а не hmac). По ней строились md5, sha1, sha2. Более современная и простая модель хэш-функций - cryptographic sponge. Представлена разработчиками sha3 keccak, по сути превращает в хэш-фунцию любой блочный шифр с достаточной длиной блока и гарантирует устойчивость, если устойчив шифр.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	25. "Представлен более эффективный метод определения префиксов ко..."	–2 +/–
	Сообщение от OpenEcho (?), 13-Май-19, 18:36
	HMAC - это не шифровка, а упрощенно - цифровая подпись: hmac = хэш(секрет+сообщение+секрет+опционально случайность) где только "секрет" - неизвестное значение, поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	39. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Sw00p aka Jerom (?), 13-Май-19, 22:06
	>HMAC - это не шифровка, а упрощенно - цифровая подпись: Да, не шифровка, но цифровая подпись - шифровка хеша (с помощью приватного ключа в случае RSA). Минус HMAC - нужно согласовывать секретную часть, пихаемую в месте с сообщением в хеш функцию. пс: md5('blavlablasecretstring' + 'message text') - вот банальный MAC
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	47. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Sw00p aka Jerom (?), 13-Май-19, 23:43
	>поэтому если хэш функция имеет коллизии, то такая подпись - фуфло все хеш функции по определению имеют коллизии
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	51. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от anonymous (??), 14-Май-19, 10:00
	Речь про известный алгоритм по изменению входных данных при сохранении результирующего hash-а.
	Ответить \| Правка \| ^ к родителю #47 \| Наверх \| Cообщить модератору


	53. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Sw00p aka Jerom (?), 14-Май-19, 11:13
	Про лавинный эффект забыли
	Ответить \| Правка \| ^ к родителю #51 \| Наверх \| Cообщить модератору


	61. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от КО (?), 14-Май-19, 12:02
	не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же самое, что подобрать коллизию к уже сформированной фразе.
	Ответить \| Правка \| ^ к родителю #51 \| Наверх \| Cообщить модератору


	56. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от RJ (?), 14-Май-19, 11:43
	>если хэш функция имеет коллизии, Практически любая функция свертки с меньшим количеством информационных битов, чем в оригинале, имеет коллизии.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	80. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от GentooBoy (ok), 15-Май-19, 21:04
	Не практически любая, а любая
	Ответить \| Правка \| ^ к родителю #56 \| Наверх \| Cообщить модератору


	65. "Представлен более эффективный метод определения префиксов ко..."	+/–
	Сообщение от Ivan_83 (ok), 14-Май-19, 16:10
	hmac выглядит совсем иначе. В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом. Но да, ты прав насчёт того что такая функция не спасёт от подделки защищаемых данных, но зато она всё ещё гарантирует не возможность восстановить секрет.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	30. "Представлен более эффективный метод определения префиксов ко..."	–1 +/–
	Сообщение от Ivan_83 (ok), 13-Май-19, 19:00
	Про губку ходили слухи что там не так всё радужно.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору