| |
| 2.4, Ivan_83 (ok), 14:27, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
 Не давно, не пора.
Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности.
В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен.
В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.
| | |
| |
| |
| |
| 5.8, Deny (?), 15:10, 13/05/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –4 +/– |
Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо
| | |
| |
| |
| 7.15, Ан (??), 16:07, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))
| | |
|
|
|
| 4.28, Ivan_83 (ok), 18:57, 13/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –1 +/– | |
Затем, что местами оно приколочено на гвозди (md5 в RADIUS без вариантов), а секурность в том же гите от sha1 не зависит, там для этого другие инструменты.
А так, я же не настаиваю на sha1 в том же ssh/tls, наоборот, sha2-256 там весьма не плох, и нынче он аппаратно считается в райзенах. (sha1 тоже аппаратно считается, а вот sha2-512 нет).
| | |
| |
| 5.60, КО (?), 11:59, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>а секурность в том же гите от sha1 не зависит, т
там от него зависит превращение репозитария в тыкву.
| | |
|
|
| 3.18, OpenEcho (?), 16:19, 13/05/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– | |
"HMAC is a specific type of message authentication code"
HMAC гарантирует защиту от подмен используя Merkle-Damgård конструкцию _только_ при условии, что используемя хэш функция не имеет коллизий
MSG: казнить нельзя, помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
а теперь представте, что приказ пришел на ваше пожалование, но ваш недруг нашел коллизию в MD5 и подменил оригинал на:
MSG: казнить, нельзя помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86
результат - секир башка
Это так, к слову о "безопасен"...
| | |
| |
| |
| 5.21, OpenEcho (?), 17:53, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
> Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс
> в 20 мегабайт
А мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?
| | |
|
| |
| 5.25, OpenEcho (?), 18:36, 13/05/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –2 +/– | |
HMAC - это не шифровка, а упрощенно - цифровая подпись:
hmac = хэш(секрет+сообщение+секрет+опционально случайность)
где только "секрет" - неизвестное значение, поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
| | |
| |
| 6.39, Sw00p aka Jerom (?), 22:06, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>HMAC - это не шифровка, а упрощенно - цифровая подпись:
Да, не шифровка, но цифровая подпись - шифровка хеша (с помощью приватного ключа в случае RSA). Минус HMAC - нужно согласовывать секретную часть, пихаемую в месте с сообщением в хеш функцию.
пс: md5('blavlablasecretstring' + 'message text') - вот банальный MAC
| | |
| 6.56, RJ (?), 11:43, 14/05/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– | |
>если хэш функция имеет коллизии,
Практически любая функция свертки с меньшим количеством информационных битов, чем в оригинале, имеет коллизии.
| | |
| 6.65, Ivan_83 (ok), 16:10, 14/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
hmac выглядит совсем иначе.
В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом.
Но да, ты прав насчёт того что такая функция не спасёт от подделки защищаемых данных, но зато она всё ещё гарантирует не возможность восстановить секрет.
| | |
|
| |
| |
| 7.35, rty (?), 20:03, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не видел.
Вместо блочного шифра с фиксированным ключом авторы keccak придумали свою функцию, которая по вроде как обладает свойствами PRP.
Максимальный размер блока у современных шифров 512 бит, а максимальный размер состояния keccak 1600 бит, поэтому как сделать лучше при сохранении размера состояния я не знаю. EME какое-нибудь.
| | |
|
|
|
| |
| 5.40, Sw00p aka Jerom (?), 22:11, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> но в hmac он типа всё ещё безопасен.
ну да, там и ксоров ключа с сообщением и с константами понадобавили вот и все, сам по себе HMAC это, что-то вроде
md5('blablablasecretstring' + 'message text')
| | |
| |
| 6.66, Ivan_83 (ok), 16:14, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Я выше написал что из себя представляет hmac.
То что ты называешь ксором с константами - на самом деле извлечение отдельных битов из байтов хэша секрета.
| | |
|
|
|
| 3.32, OpenEcho (?), 19:35, 13/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| –2 +/– | |
>для безопасности там pgp прикручивается сбоку.
Если публичные PGP ключи не передаются из рук в руки под подпись, то грош цена такой безопасности c PGP/GPG. Я как то показывал FreeBSD проекту как я стал "security-officer" зарегистрировав на MIT-ишном сервере ключей свой ключ 5180E90F с таким же именем. Никаких проблем, каждый это может сделать.
Или должны быть 3rd party центры сертификации, которые проверяют паспорт и соответствие физиономии и подписывают своим ключом и несут ответственность за верификацию или передавать публичные ключи из рук в руки(как это делается в банках), иначе нет никакой гарантии, что ключ, которым подписали принадлежит действительно хозяину, только надежда, не больше, что это правда тот за кого себя выдает.
| | |
| |
| 4.49, Crazy Alex (ok), 09:53, 14/05/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
 Ну вот в том же bitcoin core PGP-ключи используются. И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии, с другой - это был бы лакомый кусок для атаки (основной биткоин клиент же). И как-то подмен не видать, хотя большая часть пользователей не получала ключи "из рук в руки". Достаточно, что эти ключи перекрёстно подписаны и опубликованы во многих источниках.
P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы ключ принадлежал той самой сущности, что коммиты делает, а так будь это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности репы некритично совершенно.
| | |
| |
| 5.67, OpenEcho (?), 18:46, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– | |
> И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии,
Не факт...
> И как-то подмен не видать, хотя большая часть пользователей не получала
> ключи "из рук в руки".
А то что вы не видите подмен, - это значит что у вас не таких мощностей и доступа. Блокчэин не так уж хорошо защищен как вы думаете, - атака "51%" уже была успешно применена как миниум на 5-ти криптовалютах.
Оставим майнеров и посмотрим на простейшее. Предположим я имею возможность следить за вами, за всеми вашими девайсами и точками входа в интернет. Дальше все очень просто:
перехват вашего конекта, генерация новых ключей и отправка контента от вашего имени с моими ключами, на обратке - перепаковка с вашими ключами и доставка на ваши девайсы. Classic MITM атака. Помог PGP/GPG если ключи не были переданы из рук в руки?
> Достаточно, что эти ключи перекрёстно подписаны
> и опубликованы во многих источниках.
Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были случаи компроментирования и на довольно известных проектах.
> P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы
> ключ принадлежал той самой сущности, что коммиты делает, а так будь
> это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности
> репы некритично совершенно.
о какой безопасности речь ???
X = сущность
Y = issued-by(X)
верить Y которая принадлежит X ???
а еще X может генерить новые ключи каждый день...
и тогда вообще не понятно, а та ли это сущность X
| | |
| |
| 6.72, Sw00p aka Jerom (?), 02:18, 15/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и >рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и >перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет >механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были >случаи компроментирования и на довольно известных проектах
Соглашусь только с одним, что PGP и его сеть доверия, основанная на взаимных подписываниях ключей всей сетью, не спасет от так называемого "внедрения" злоумышленника в эту сеть, особенно в современных реалиях, когда порой эта сеть доверия состоит из людей которые друг друга в глаза не видели, а чисто по ынтернету.
Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему каналу связи (при личной встрече, по телефону и т.д.)
| | |
| |
| 7.74, OpenEcho (?), 15:24, 15/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему
> каналу связи (при личной встрече, по телефону и т.д.)
Так именно об этом я и говорил в начале, PGP эффективен только в случае, если ключи передаются из рук в руки (если вы знаете голос человека, его повадки, то можно и через телефон, но самое надежное - как в банках - из рук в руки и под подпись)
Но это все работает только в случаях личных знакомств, верить же PGP подписям на Github для примера, где вы не знаете кореспондента лично или в случаях с бинарными пакетами в юникс системах - это просто вера на слово. Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?
| | |
|
|
|
| 4.52, anonymous (??), 10:31, 14/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
Не обязательно из рук в руки. По любому (хоть открытому) каналу с аутентификацией отправителя и гарантей сохранности сообщения.
Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю, другому ключу (владелец которого достоверно известен) и т.п.
Да и вообще в культуре использования PGP (из того что видел я) два одновременных валидных ключа на один ящик вызывают вопросы и повышенную осторожность.
Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для вашего закрытого ключа).
| | |
| |
| 5.68, OpenEcho (?), 19:36, 14/05/2019 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
> Не обязательно из рук в руки. По любому (хоть открытому) каналу с
> аутентификацией отправителя и гарантей сохранности сообщения.
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь
> на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю
Здесь в соседней новости про взлом Github-овских экаунтов...
Помогла аутентификация?
> , другому ключу (владелец которого достоверно известен) и т.п.
Где эта самая достоверность в PGP/GPG ?
> Да и вообще в культуре использования PGP (из того что видел я)
> два одновременных валидных ключа на один ящик вызывают вопросы и повышенную
> осторожность.
И много вы знаете реальных людей, которые вообще смотрят за ключами и добросовестно сверяют с публичными key серверами сколько там ключей? Это хорошо если они там вообще опубликованы.
Вот именно, что кроме вызывания вопросов, текущая культура примения PGP ключей не вызывает больше ничего. Ну да, механизм криптографии высок, а толку от него если origin unknown ?
Видимость надежности, но не надежность т.к. без достоверной 100% гарантии принадлежности ключа - это не надежней чем просто верить на слово
> Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё
> равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для
> вашего закрытого ключа).
Элементарная MITM атака и прийдет пушистый, белый арктический зверек
| | |
| |
| |
| 7.78, anonymous (??), 20:23, 15/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
P.S.: Переформулирую: вообще да, просто так доверять никакому ключу, конечно же не стоит. А если есть дополнительные подозрительнеы признаки (а-ля лишние ключи), то нужно быть вдвое осторожным. Но обычно люди используют сторонние аутентицирующие каналы, и это не всегда встречал IRL с паспортом в руке (тем более, если человека знаешь много лет).
| | |
|
|
| 5.73, Sw00p aka Jerom (?), 02:20, 15/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS
так это по определению уже не открытый канал связи. Обычно лично звонят по телефону и посимвольно сверяют фингерпринт.
| | |
| |
| 6.75, OpenEcho (?), 15:29, 15/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Обычно лично звонят
> по телефону и посимвольно сверяют фингерпринт.
Вероятно мы живем на разных планетах, т.к. я никогда не видел людей, которые "обычно звонят" в debian/CentOS/Gentoo... перед установкой операционки и при установке пакетов для сверки фингерпринта.
| | |
| |
| 7.85, Sw00p aka Jerom (?), 01:55, 16/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками его потом на сервере проверить, а мы про pgp разговариваем. Много ли таких людей кто сверяет? А в случае с виртуальными машинами и их клонами, многие ли перегенерировали хост ключи? Новость даже такая была.
| | |
|
|
|
|
|
|
| |
| 2.13, КО (?), 15:52, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– |
Да не совсем, это вариация на тему уже показанная Google - метод создания коллизии, не метод подбора к существующему hash.
| | |
| |
| 3.14, КО (?), 15:56, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– | |
поясняю, неточность в переводе статьи
для любых, наперед заданных, p1 и p2 можно подобрать такие m1 и m2, что
hash(p1||m1)=hash(p2||m2)
это не совсем тоже самое, что в переводе, что есть такие p1 и p2, что что не пиши в m1 и m2, результат хеширования не меняется. :)
| | |
|
|
| 1.6, педофил (?), 15:03, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –2 +/– |
Тогда получается, что можно взломать всё, куда удастся пропихнуть такой префикс? А это может стать отдельной уязвимостью?
| | |
| |
| 2.11, товарищ майор (?), 15:38, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| –3 +/– | |
мне - можно. Ну, если тебя совсем не насторожит бредятина в начале файла - может.
А если ты для себя, любимого спрашивает - у тебя не хватит ресурсов.
И твоя майнинговая ферма по сравнению с моей - курам на смех (нет, ты думал, те китайские заводы по прозводству битков - крестьяне с рисовых полей вскладчину строили?)
| | |
|
| 1.12, Мексиканец (?), 15:43, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –6 +/– | |
> веский аргумент для незамедлительного прекращения использования SHA-1, особенно в сертификатах и цифровых подписях.
А я давно юзаю SHA-512, правда при работе с файлами, любых размеров, вплоть до 60 Gb (копии iso blu-ray)
Не скажу, что сумма вычисляется долго на моём 6900K, но для меня важна 100% подлинность файла, особенно, когда бэкапы хранятся на HDD и M-Disc.
| | |
| |
| |
| 3.46, Аноним (46), 23:14, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
с crc32 даже в словаре аглийских слов можно найти несколько слов с одинаковым хешем. но конечно лучше чем ничего.
| | |
|
| 2.27, педофил (?), 18:46, 13/05/2019 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +/– |
Некоторые люди слишком страдают беспокоясь маловероятных вещей. Да, я тоже.
Как избавиться от такого?
Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов. По идее. Нормальные люди не задумываются.
| | |
| |
| 3.41, Sw00p aka Jerom (?), 22:17, 13/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов.
ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
| | |
| |
| 4.57, КО (?), 11:52, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
Не возможно. Можно только увеличить. :)
Криптографический hash отличается тем, что вычислить другие варианты оригиналов сложно (в идеале не проще полного перебора комбинаций).
Но при этом вероятность того, что ваш меганакрученный пароль из ста слов имеет коллизию с одним символом пробел, тоже можно лишь попробовав. :)
| | |
|
|
| 2.36, KonstantinB (ok), 20:35, 13/05/2019 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +3 +/– |
 Случайно вы не получите одинаковый хэш даже с MD5.
Ну, то есть, вероятность есть, но примерно такая же, как вероятность падения метеорита вам на голову.
А если к вашим HDD с бэкапами имеют неограниченный доступ посторонние люди, то скорее этот вопрос надо решать.
| | |
| |
| 3.58, КО (?), 11:53, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Случайно вы не получите одинаковый хэш даже с MD5.
Случайно CRC32 получить тяжело. Специально - гораздо легче.
| | |
|
|
| 1.16, Аноним (16), 16:10, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +/– | |
> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018
АНБ оно такое АНБ.
| | |
| 1.33, Аноним (33), 19:39, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]
| +1 +/– | |
>При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям.
Атаковать неуловимых Джо бабла не напасутся.
| | |
| |
| 2.59, КО (?), 11:57, 14/05/2019 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
На что? На то, чтобы создать сертификаты для www.google.com и www.microsoft.com с одинаковой подписью? Да. Но они оба будут игнорироваться браузером, потому что ему нужна другая.
Вот запороть git репо можно. Но цена вопроса в 100 тыс баксов. :)
| | |
|
|
