The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен более эффективный метод определения коллизий для SHA-1

13.05.2019 12:06

Исследователи из французского государственного института исследований в информатике и автоматике (INRIA) и Наньянского технологического университета (Сингапур) разработали усовершенствованный метод атаки на алгоритм 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, особенно в сертификатах и цифровых подписях.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Google продемонстрировал первую успешную атаку на алгоритм хеширования SHA-1
  3. OpenNews: Энтузиасты воссоздали метод мгновенной генерации PDF-файлов с одинаковым хэшем SHA-1
  4. OpenNews: GitHub добавил защиту от атак, использующих коллизии SHA-1
  5. OpenNews: Раскрыты детали новой атаки на различные реализации TLS
  6. OpenNews: Представлен метод атаки на групповой чат WhatsApp и Signal
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: sha1, collision, hash
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (87) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:48, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ну вот, опять только для товарищмайора :-(

     
     
  • 2.10, Аноним (10), 15:12, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Майнинговую ферму свою перепрофилируй. Всё больше толку от неё будет
     
     
  • 3.48, Аноним (48), 09:33, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    не будет. майнинг это хороший вклад, прибыльный. умный выбор
     
     
  • 4.79, GentooBoy (ok), 20:57, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сразу несколько раз.
     

  • 1.2, донатер (?), 13:49, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Давно пора отказываться от sha1
     
     
  • 2.4, Ivan_83 (ok), 14:27, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не давно, не пора.
    Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности.
    В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен.
    В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.
     
     
  • 3.5, Deny (?), 14:29, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Зачем юзать старьё?
     
     
  • 4.7, анон (?), 15:08, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а вы адепт "автомата Калашникова" на батарейках ?)
     
     
  • 5.8, Deny (?), 15:10, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо
     
     
  • 6.9, Deny (?), 15:11, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    йтись без этого,то я предпочту пользоваться современными вещами.
    Странно,обрезало сообщение
     
     
  • 7.15, Ан (??), 16:07, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))
     
     
  • 8.23, OpenEcho (?), 18:15, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    За что платят - то и получают скупой платит дважды Именно поэтому придуман... текст свёрнут, показать
     
  • 5.45, Аноним (45), 22:46, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А причем тут ак? Я тащусь, если честно, с этого автомата.
     
  • 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 не зависит, т

    там от него зависит превращение репозитария в тыкву.

     
     
  • 6.64, Ivan_83 (ok), 16:04, 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

    результат - секир башка

    Это так, к слову о "безопасен"...

     
     
  • 4.19, Аноним (19), 16:47, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 мегабайт
     
     
  • 5.21, OpenEcho (?), 17:53, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс
    > в 20 мегабайт

    А мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?

     
  • 4.24, rty (?), 18:19, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    При атаке HMAC, злоумышленник не сможет генерировать пару 171 сообщение 187... текст свёрнут, показать
     
     
  • 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.47, Sw00p aka Jerom (?), 23:43, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >поэтому если хэш функция имеет коллизии, то такая подпись - фуфло

    все хеш функции по определению имеют коллизии

     
     
  • 7.51, anonymous (??), 10:00, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Речь про известный алгоритм по изменению входных данных при сохранении результирующего hash-а.
     
     
  • 8.53, Sw00p aka Jerom (?), 11:13, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Про лавинный эффект забыли ... текст свёрнут, показать
     
  • 8.61, КО (?), 12:02, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же ... текст свёрнут, показать
     
  • 6.56, RJ (?), 11:43, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >если хэш функция имеет коллизии,

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

     
     
  • 7.80, GentooBoy (ok), 21:04, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не практически любая, а любая
     
  • 6.65, Ivan_83 (ok), 16:10, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    hmac выглядит совсем иначе.
    В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом.

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

     
  • 5.30, Ivan_83 (ok), 19:00, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Про губку ходили слухи что там не так всё радужно.
     
     
  • 6.31, Ivan_83 (ok), 19:01, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И никто не стремится переезжать на sha3, я что то вообще не видел его нигде.
     
     
  • 7.35, rty (?), 20:03, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не видел.
    Вместо блочного шифра с фиксированным ключом авторы keccak придумали свою функцию, которая по вроде как обладает свойствами PRP.
    Максимальный размер блока у современных шифров 512 бит, а максимальный размер состояния keccak 1600 бит, поэтому как сделать лучше при сохранении размера состояния я не знаю. EME какое-нибудь.
     
  • 5.44, Аноним84701 (ok), 22:33, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там той разницы-то code 1 1 1a openssl speed sha1 md5 The numbers are in 10... текст свёрнут, показать
     
     
  • 6.50, anonymous (??), 09:54, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с tmpfs повторить этот же эксперимент.
     
     
  • 7.54, Аноним84701 (ok), 11:28, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Имхо, это уже будет синтетика большие и тяжелые файлы, бэкапы и прочее обычно... текст свёрнут, показать
     
     
  • 8.55, anonymous (??), 11:42, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых диски бывают быстренькие, а-ля всякие NVMe во-вторых, бывает hash-иро... текст свёрнут, показать
     
     
  • 9.62, Аноним84701 (ok), 12:11, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Бывают Я немного попутал ветки и писал в контексте на самом деле нижеотписавш... текст свёрнут, показать
     
  • 4.29, Ivan_83 (ok), 18:58, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ты уверен что это так?
    Я где то читал что md5 хоть и "сломали" но в hmac он типа всё ещё безопасен.
     
     
  • 5.34, OpenEcho (?), 19:56, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я где то читал что 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.pdf


     
  • 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.
    То что ты называешь ксором с константами - на самом деле извлечение отдельных битов из байтов хэша секрета.
     
     
  • 7.69, Sw00p aka Jerom (?), 19:45, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    какое извлечение? там ксорится секретный ключь с магической константой
     
     
  • 8.70, Ivan_83 (ok), 00:54, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    for i 0 i MD5_MSG_BLK_64CNT i k_ipad i 0x3636363636363636ull... текст свёрнут, показать
     
     
  • 9.71, Sw00p aka Jerom (?), 02:09, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https ru wikipedia org wiki HMAC по википедии хеш от ключа не берется, в описа... текст свёрнут, показать
     
  • 3.32, OpenEcho (?), 19:35, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >для безопасности там pgp прикручивается сбоку.

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

    Или должны быть 3rd party центры сертификации, которые проверяют паспорт и соответствие физиономии и подписывают своим ключом и несут ответственность за верификацию или передавать публичные ключи из рук в руки(как это делается в банках), иначе нет никакой гарантии, что ключ, которым подписали принадлежит действительно хозяину, только надежда, не больше, что это правда тот за кого себя выдает.

     
     
  • 4.37, xm (ok), 20:49, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Теперь у нас есть DANE для этих целей. Вопрос в его поддержке софтом.
     
     
  • 5.38, OpenEcho (?), 21:30, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Думаете гугля позволит? Они так тщательно загоняют всех в CT стойло, а DANE, imho для них облом
     
  • 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 фингерпринт?

     
     
  • 8.81, Sw00p aka Jerom (?), 22:09, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    нет конечно, как ответил ниже другому коментатору, подразумевалось в смысле испо... текст свёрнут, показать
     
     
  • 9.82, Sw00p aka Jerom (?), 22:11, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    другому коментатору - вам, сорян ... текст свёрнут, показать
     
  • 9.83, OpenEcho (?), 23:12, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если соблюдается элементарная процедура сравнивания фингерпринта ключей между ко... текст свёрнут, показать
     
  • 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 атака и прийдет пушистый, белый арктический зверек


     
     
  • 6.77, anonymous (??), 20:20, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там, вроде как, не про GitHub была речь, а про qwerty123-подобное поведение коне... текст свёрнут, показать
     
     
  • 7.78, anonymous (??), 20:23, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    P.S.: Переформулирую: вообще да, просто так доверять никакому ключу, конечно же не стоит. А если есть дополнительные подозрительнеы признаки (а-ля лишние ключи), то нужно быть вдвое осторожным. Но обычно люди используют сторонние аутентицирующие каналы, и это не всегда встречал IRL с паспортом в руке (тем более, если человека знаешь много лет).
     
  • 7.84, OpenEcho (?), 00:29, 16/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Предыдущий себеседник, приводил пример, что если персона аутефицирована, то авто... текст свёрнут, показать
     
  • 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.76, Sw00p aka Jerom (?), 16:05, 15/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >перед установкой операционки и при установке пакетов для сверки фингерпринта

    так не в этом случае, имелось ввиду PGP для писем.

     
  • 7.85, Sw00p aka Jerom (?), 01:55, 16/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками его потом на сервере проверить, а мы про pgp разговариваем. Много ли таких людей кто сверяет? А в случае с виртуальными машинами и их клонами, многие ли перегенерировали хост ключи? Новость даже такая была.

     
     
  • 8.86, OpenEcho (?), 02:50, 16/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В одной конторе где я раньше работал, за игнор перепроверять фингерпринт SSH - п... текст свёрнут, показать
     

  • 1.3, Аноним (3), 14:00, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > коллизия возникает при наличии определённых префиксов, независимо от остальных данных в наборе

    Красота.

     
     
  • 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, результат хеширования не меняется. :)

     
     
  • 4.26, педофил (?), 18:39, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я понял как в второй случай и это было страшно.
     

  • 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.

     
     
  • 2.20, Crazy Alex (ok), 17:43, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    тот случай, когда даже md5 избыточен
     
  • 2.22, Annoynymous (ok), 17:56, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да, CRC32 не даст такой точности, куда там ему.
     
     
  • 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 отличается тем, что вычислить другие варианты оригиналов сложно (в идеале не проще полного перебора комбинаций).
    Но при этом вероятность того, что ваш меганакрученный пароль из ста слов имеет коллизию с одним символом пробел, тоже можно лишь попробовав. :)

     
     
  • 5.63, Sw00p aka Jerom (?), 14:21, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, просто нужно подобрать правильный алгоритм у которого максимальный период исчерпаемости
     
     
  • 6.87, КО (?), 17:55, 16/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Максимальный у hash=значение, но его легко подделать :)
     
     
  • 7.88, Annoynymous (ok), 12:56, 21/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Максимальный у hash=значение, но его легко подделать :)

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

     
  • 2.36, KonstantinB (ok), 20:35, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Случайно вы не получите одинаковый хэш даже с MD5.
    Ну, то есть, вероятность есть, но примерно такая же, как вероятность падения метеорита вам на голову.

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

     
     
  • 3.42, Sw00p aka Jerom (?), 22:23, 13/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у RSA даже есть свойство рефлексивности, когда m^e mod n = m
     
  • 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.17, Аноним (17), 16:18, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Эта публикация - чья-то дурацкая шутка SIMON-32 64 - шифр с 32-битным блоком и ... текст свёрнут, показать
     
  • 1.33, Аноним (33), 19:39, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям.

    Атаковать неуловимых Джо бабла не напасутся.

     
  • 1.43, Виталий (??), 22:32, 13/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    При тех же мощностях Гуглу нужно меньше двух дней, да уж безопасненько)))
     
     
  • 2.59, КО (?), 11:57, 14/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На что? На то, чтобы создать сертификаты для www.google.com и www.microsoft.com с одинаковой подписью? Да. Но они оба будут игнорироваться браузером, потому что ему нужна другая.
    Вот запороть git репо можно. Но цена вопроса в 100 тыс баксов. :)
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру