Исследователи из французского государственного института исследований в информатике и автоматике (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
ну вот, опять только для товарищмайора :-(
Майнинговую ферму свою перепрофилируй. Всё больше толку от неё будет
не будет. майнинг это хороший вклад, прибыльный. умный выбор
Если вы получите подделанный сертификат гугла или фейсбука то ферму окупите сразу несколько раз.
Давно пора отказываться от sha1
Не давно, не пора.
Отказыватся имеет смысл там, где оно используется напрямую и в целях безопасности.
В HMAC конструкции он, как и md5 скорее всего ещё безопасен и долго будет безопасен.
В git оно используется не в целях безопасности, поэтому sha1/md5/md4 или что похуже - пофик, для безопасности там pgp прикручивается сбоку.
Зачем юзать старьё?
а вы адепт "автомата Калашникова" на батарейках ?)
Извините,не понял аналогии.Я предпочитаю использовать современные инструменты.Да,бывают ситуации,где необходимо думать о поддержке разнообразного легасти, но если можно обо
йтись без этого,то я предпочту пользоваться современными вещами.
Странно,обрезало сообщение
Потому что дешевле с точки зрения использования ресурсов компьютера. Такие вещи вы и сами должны понимать)))
> Потому что дешевле с точки зрения использования ресурсов компьютера.За что платят - то и получают... скупой платит дважды...
Именно поэтому придуманы PBKDF2, чтобы усложнить жизнь брутфорсу - грузить хардарь по полной.
От задач все зависит, если это авторизация, то нельзя экономить на ресурсах хардвари, если же задача проверять целостность к примеру архива, то наоборот, чем быстрей и легче хэш - тем лучше.
А причем тут ак? Я тащусь, если честно, с этого автомата.
Затем, что местами оно приколочено на гвозди (md5 в RADIUS без вариантов), а секурность в том же гите от sha1 не зависит, там для этого другие инструменты.А так, я же не настаиваю на sha1 в том же ssh/tls, наоборот, sha2-256 там весьма не плох, и нынче он аппаратно считается в райзенах. (sha1 тоже аппаратно считается, а вот sha2-512 нет).
>а секурность в том же гите от sha1 не зависит, ттам от него зависит превращение репозитария в тыкву.
Покажи примеры репозиториев которые превратились в тыкву из за sha1.
"HMAC is a specific type of message authentication code"HMAC гарантирует защиту от подмен используя Merkle-Damgård конструкцию _только_ при условии, что используемя хэш функция не имеет коллизий
MSG: казнить нельзя, помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86а теперь представте, что приказ пришел на ваше пожалование, но ваш недруг нашел коллизию в MD5 и подменил оригинал на:
MSG: казнить, нельзя помиловать!
HMAC: e46dfec0d4136e82abc5ff88d6f01f86результат - секир башка
Это так, к слову о "безопасен"...
Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс в 20 мегабайт
> Ага, и никто не заметит, что в начале фразы мааааленький бинарный префикс
> в 20 мегабайтА мы разве живем не во времена, где paypal.com.abracadabra.top - "нормальное", каждодневное явление?
"При атаке HMAC, злоумышленник не сможет генерировать пару («сообщение», «код») в удалённом (офлайн) режиме, так как злоумышленник не знает ключа K.
...
Таким образом, если скорость имеет значение, вполне приемлемо использовать MD5, а не SHA-1 в качестве встроенных хеш-функций для HMAC." Википедия
Не знаю, как работает hmac, но если положить хэш последним блоком в cbc (со случайным iv), то md5 очевидно можно использовать. Аутентификацию нельзя будет целенаправленно нарушить, так как слабый хэш зашифрован нормальным алгоритмом.
Или же можно взять хэш сообщения вместе с iv и зашифровать отдельно.Merkle-Damgård это модель, по которой строятся хэш-функции (а не hmac). По ней строились md5, sha1, sha2. Более современная и простая модель хэш-функций - cryptographic sponge. Представлена разработчиками sha3 keccak, по сути превращает в хэш-фунцию любой блочный шифр с достаточной длиной блока и гарантирует устойчивость, если устойчив шифр.
HMAC - это не шифровка, а упрощенно - цифровая подпись:hmac = хэш(секрет+сообщение+секрет+опционально случайность)
где только "секрет" - неизвестное значение, поэтому если хэш функция имеет коллизии, то такая подпись - фуфло
>HMAC - это не шифровка, а упрощенно - цифровая подпись:Да, не шифровка, но цифровая подпись - шифровка хеша (с помощью приватного ключа в случае RSA). Минус HMAC - нужно согласовывать секретную часть, пихаемую в месте с сообщением в хеш функцию.
пс: md5('blavlablasecretstring' + 'message text') - вот банальный MAC
>поэтому если хэш функция имеет коллизии, то такая подпись - фуфловсе хеш функции по определению имеют коллизии
Речь про известный алгоритм по изменению входных данных при сохранении результирующего hash-а.
Про лавинный эффект забыли
не речь про поиск двух фраз имеющий общую часть и одинаковый hash, это не то же самое, что подобрать коллизию к уже сформированной фразе.
>если хэш функция имеет коллизии,Практически любая функция свертки с меньшим количеством информационных битов, чем в оригинале, имеет коллизии.
Не практически любая, а любая
hmac выглядит совсем иначе.
В начале там берут хэш от секрета, далее в этом хэше половину битов каждого байта скармливают на вход хэш функции, потом вливают туда все данные и в конце оставшиеся половинки от хэша с секретом.Но да, ты прав насчёт того что такая функция не спасёт от подделки защищаемых данных, но зато она всё ещё гарантирует не возможность восстановить секрет.
Про губку ходили слухи что там не так всё радужно.
И никто не стремится переезжать на sha3, я что то вообще не видел его нигде.
Имхо в sha3 сомнительная функция f, а про саму модель sponge я ничего плохого не видел.
Вместо блочного шифра с фиксированным ключом авторы keccak придумали свою функцию, которая по вроде как обладает свойствами PRP.
Максимальный размер блока у современных шифров 512 бит, а максимальный размер состояния keccak 1600 бит, поэтому как сделать лучше при сохранении размера состояния я не знаю. EME какое-нибудь.
> Таким образом, если скорость имеет значение, вполне приемлемо использовать 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.18k1.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
В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с tmpfs повторить этот же эксперимент.
> В Вашем случае Вы, видимо, упёрлись в диск. Попробуйте с 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
> Имхо, это уже будет синтетика ("большие и тяжелые" файлы, бэкапы и прочее обычно все же хранятся на дисках, где все упирается в ИО).Во-первых диски бывают быстренькие, а-ля всякие NVMe; во-вторых, бывает hash-ирование на лету (без работы с диском).
> Тем более, это вообще-то был SSD,
Я неправильно прочитал вывод time-а, sorry.
И Вы правы (перепроверил на своей машине, только что): действительно утилиты sha1sum и md5sum работают с примерно одинаковой скоростью:
$ time md5sum dump
4c37decbf524ac3abced1e33132833d6 dumpreal 0m3,997s
user 0m3,700s
sys 0m0,289s$ time sha1sum dump
1bbe8f39f30d3a97528d87c5db87b1a72bf7f1f4 dumpreal 0m4,438s
user 0m4,129s
sys 0m0,300s
А если выбрать более аккуратную реализацию, то sha1 даже быстрее будет (спец. инструкции в процессоре?):$ time openssl md5 dump
MD5(dump)= 4c37decbf524ac3abced1e33132833d6real 0m3,881s
user 0m3,589s
sys 0m0,292s$ time openssl sha1 dump
SHA1(dump)= 1bbe8f39f30d3a97528d87c5db87b1a72bf7f1f4real 0m2,818s
user 0m2,510s
sys 0m0,308s
>> Имхо, это уже будет синтетика ("большие и тяжелые" файлы, бэкапы и прочее обычно все же хранятся на дисках, где все упирается в ИО).
> Во-первых диски бывают быстренькие, а-ля всякие 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делать хотя бы пару десятков повторов.
А ты уверен что это так?
Я где то читал что md5 хоть и "сломали" но в hmac он типа всё ещё безопасен.
> Я где то читал что 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...
> но в hmac он типа всё ещё безопасен.ну да, там и ксоров ключа с сообщением и с константами понадобавили вот и все, сам по себе HMAC это, что-то вроде
md5('blablablasecretstring' + 'message text')
Я выше написал что из себя представляет hmac.
То что ты называешь ксором с константами - на самом деле извлечение отдельных битов из байтов хэша секрета.
какое извлечение? там ксорится секретный ключь с магической константой
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ну да - не извлекаются биты, я чёт подзабыл малость, но только не ключ а его хэш, если ключ больше размера блока хэша.
> но только не ключ а его хэш, если ключ больше размера блока хэша.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 - операция побитового исключающего ИЛИ
>для безопасности там pgp прикручивается сбоку.Если публичные PGP ключи не передаются из рук в руки под подпись, то грош цена такой безопасности c PGP/GPG. Я как то показывал FreeBSD проекту как я стал "security-officer" зарегистрировав на MIT-ишном сервере ключей свой ключ 5180E90F с таким же именем. Никаких проблем, каждый это может сделать.
Или должны быть 3rd party центры сертификации, которые проверяют паспорт и соответствие физиономии и подписывают своим ключом и несут ответственность за верификацию или передавать публичные ключи из рук в руки(как это делается в банках), иначе нет никакой гарантии, что ключ, которым подписали принадлежит действительно хозяину, только надежда, не больше, что это правда тот за кого себя выдает.
Теперь у нас есть DANE для этих целей. Вопрос в его поддержке софтом.
Думаете гугля позволит? Они так тщательно загоняют всех в CT стойло, а DANE, imho для них облом
Ну вот в том же bitcoin core PGP-ключи используются. И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии, с другой - это был бы лакомый кусок для атаки (основной биткоин клиент же). И как-то подмен не видать, хотя большая часть пользователей не получала ключи "из рук в руки". Достаточно, что эти ключи перекрёстно подписаны и опубликованы во многих источниках.P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы ключ принадлежал той самой сущности, что коммиты делает, а так будь это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности репы некритично совершенно.
> И, с одной стороны, используются людьми, точно хорошо разбирающимися в криптографии,Не факт...
> И как-то подмен не видать, хотя большая часть пользователей не получала
> ключи "из рук в руки".А то что вы не видите подмен, - это значит что у вас не таких мощностей и доступа. Блокчэин не так уж хорошо защищен как вы думаете, - атака "51%" уже была успешно применена как миниум на 5-ти криптовалютах.
Оставим майнеров и посмотрим на простейшее. Предположим я имею возможность следить за вами, за всеми вашими девайсами и точками входа в интернет. Дальше все очень просто:
перехват вашего конекта, генерация новых ключей и отправка контента от вашего имени с моими ключами, на обратке - перепаковка с вашими ключами и доставка на ваши девайсы. Classic MITM атака. Помог PGP/GPG если ключи не были переданы из рук в руки?> Достаточно, что эти ключи перекрёстно подписаны
> и опубликованы во многих источниках.Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были случаи компроментирования и на довольно известных проектах.
> P.S. Вот как раз паспорт и физиономия не интересны совершенно. Интересно, чтобы
> ключ принадлежал той самой сущности, что коммиты делает, а так будь
> это хоть анонимный киферпанк, хоть марсианин, хоть AI - для безопасности
> репы некритично совершенно.о какой безопасности речь ???
X = сущность
Y = issued-by(X)верить Y которая принадлежит X ???
а еще X может генерить новые ключи каждый день...
и тогда вообще не понятно, а та ли это сущность X
>Ну а теперь - честно, как много вы видели "перекрёстно подписаных" ключей ? Допустим даже что это сплошь и >рядом, КТО эти перекрестные ключи и почему Вы считаете, что я не могу нагенерировать кучу других ключей и >перекрестно подписать то, что мне надо? Откуда у вас есть увереность и доверие перекрестным ключам если нет >механизма проверить кому они по настоящему принадлежат ? Фингерпринт на веб сайте ? Не верю, т.к. уже были >случаи компроментирования и на довольно известных проектахСоглашусь только с одним, что PGP и его сеть доверия, основанная на взаимных подписываниях ключей всей сетью, не спасет от так называемого "внедрения" злоумышленника в эту сеть, особенно в современных реалиях, когда порой эта сеть доверия состоит из людей которые друг друга в глаза не видели, а чисто по ынтернету.
Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему каналу связи (при личной встрече, по телефону и т.д.)
> Посимвольная сверка того же фингерпринта банальная практика в PGP, но по стороннему
> каналу связи (при личной встрече, по телефону и т.д.)Так именно об этом я и говорил в начале, PGP эффективен только в случае, если ключи передаются из рук в руки (если вы знаете голос человека, его повадки, то можно и через телефон, но самое надежное - как в банках - из рук в руки и под подпись)
Но это все работает только в случаях личных знакомств, верить же PGP подписям на Github для примера, где вы не знаете кореспондента лично или в случаях с бинарными пакетами в юникс системах - это просто вера на слово. Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?
> Вы видели людей, которые перед установкой redis звонят в проект и докапываются кто подписал пакет и сверяют с неизвестным X фингерпринт?нет конечно, как ответил ниже другому коментатору, подразумевалось в смысле использования PGP при шифровании писем.
"другому коментатору" - вам, сорян
>подразумевалось в смысле использования PGP при шифровании писем.Если соблюдается элементарная процедура сравнивания фингерпринта ключей между кореспондентами то проблем с PGP шифровкой нет.
Я же говорю о массом применении PGP в Git, в подписях операционных систем и пакетов и т.к. далее, где практически доверия ключам нет, т.к. большинство людей не знают тех, кто стоит за этими ключами. Мы просто верим на слово, что ключи и правда принадлежат хозяевам.
Не обязательно из рук в руки. По любому (хоть открытому) каналу с аутентификацией отправителя и гарантей сохранности сообщения.Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролю, другому ключу (владелец которого достоверно известен) и т.п.
Да и вообще в культуре использования PGP (из того что видел я) два одновременных валидных ключа на один ящик вызывают вопросы и повышенную осторожность.
Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для вашего закрытого ключа).
> Не обязательно из рук в руки. По любому (хоть открытому) каналу с
> аутентификацией отправителя и гарантей сохранности сообщения.
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPS, полагаясь
> на надёжность PKI. Но вообще способов много: аутентифицировать по логину-паролюЗдесь в соседней новости про взлом Github-овских экаунтов...
Помогла аутентификация?> , другому ключу (владелец которого достоверно известен) и т.п.
Где эта самая достоверность в PGP/GPG ?
> Да и вообще в культуре использования PGP (из того что видел я)
> два одновременных валидных ключа на один ящик вызывают вопросы и повышенную
> осторожность.И много вы знаете реальных людей, которые вообще смотрят за ключами и добросовестно сверяют с публичными key серверами сколько там ключей? Это хорошо если они там вообще опубликованы.
Вот именно, что кроме вызывания вопросов, текущая культура примения PGP ключей не вызывает больше ничего. Ну да, механизм криптографии высок, а толку от него если origin unknown ?
Видимость надежности, но не надежность т.к. без достоверной 100% гарантии принадлежности ключа - это не надежней чем просто верить на слово> Кроме того, вы ведь письмо-то всё равно не получите. Его получит всё
> равно правильный получатель, только прочесть не сможет (ибо оно преднозначалось для
> вашего закрытого ключа).Элементарная MITM атака и прийдет пушистый, белый арктический зверек
> Здесь в соседней новости про взлом 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, а не слать что попало куда попало и как попало.
P.S.: Переформулирую: вообще да, просто так доверять никакому ключу, конечно же не стоит. А если есть дополнительные подозрительнеы признаки (а-ля лишние ключи), то нужно быть вдвое осторожным. Но обычно люди используют сторонние аутентицирующие каналы, и это не всегда встречал IRL с паспортом в руке (тем более, если человека знаешь много лет).
> Там, вроде как, не про 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 и яровая.
> Многие проекты публикуют свои PGP ID тупо на сайте с HTTPSтак это по определению уже не открытый канал связи. Обычно лично звонят по телефону и посимвольно сверяют фингерпринт.
> Обычно лично звонят
> по телефону и посимвольно сверяют фингерпринт.Вероятно мы живем на разных планетах, т.к. я никогда не видел людей, которые "обычно звонят" в debian/CentOS/Gentoo... перед установкой операционки и при установке пакетов для сверки фингерпринта.
>перед установкой операционки и при установке пакетов для сверки фингерпринтатак не в этом случае, имелось ввиду PGP для писем.
Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками его потом на сервере проверить, а мы про pgp разговариваем. Много ли таких людей кто сверяет? А в случае с виртуальными машинами и их клонами, многие ли перегенерировали хост ключи? Новость даже такая была.
> Тот же ssh печатает фингерпринт ключа сервера при первом соединении, чтобы ручками
> его потом на сервере проверить, а мы про pgp разговариваем.В одной конторе где я раньше работал, за игнор перепроверять фингерпринт SSH - просто увольняли.
> Много ли таких людей кто сверяет? А в случае с виртуальными машинами
> и их клонами, многие ли перегенерировали хост ключи? Новость даже такая
> была.Вот это самый главный вопрос !!!
Не понимание элементарного механизма в технологиях криптографии просто исключает сам смысл этих технологий.
Банально все сводится - "а я как у всех"... грустно...
> коллизия возникает при наличии определённых префиксов, независимо от остальных данных в набореКрасота.
Да не совсем, это вариация на тему уже показанная Google - метод создания коллизии, не метод подбора к существующему hash.
поясняю, неточность в переводе статьидля любых, наперед заданных, p1 и p2 можно подобрать такие m1 и m2, что
hash(p1||m1)=hash(p2||m2)это не совсем тоже самое, что в переводе, что есть такие p1 и p2, что что не пиши в m1 и m2, результат хеширования не меняется. :)
Я понял как в второй случай и это было страшно.
Тогда получается, что можно взломать всё, куда удастся пропихнуть такой префикс? А это может стать отдельной уязвимостью?
мне - можно. Ну, если тебя совсем не насторожит бредятина в начале файла - может.А если ты для себя, любимого спрашивает - у тебя не хватит ресурсов.
И твоя майнинговая ферма по сравнению с моей - курам на смех (нет, ты думал, те китайские заводы по прозводству битков - крестьяне с рисовых полей вскладчину строили?)
> веский аргумент для незамедлительного прекращения использования SHA-1, особенно в сертификатах и цифровых подписях.А я давно юзаю SHA-512, правда при работе с файлами, любых размеров, вплоть до 60 Gb (копии iso blu-ray)
Не скажу, что сумма вычисляется долго на моём 6900K, но для меня важна 100% подлинность файла, особенно, когда бэкапы хранятся на HDD и M-Disc.
тот случай, когда даже md5 избыточен
Да, CRC32 не даст такой точности, куда там ему.
с crc32 даже в словаре аглийских слов можно найти несколько слов с одинаковым хешем. но конечно лучше чем ничего.
Некоторые люди слишком страдают беспокоясь маловероятных вещей. Да, я тоже.
Как избавиться от такого?
Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов. По идее. Нормальные люди не задумываются.
>Хеши - они вообще чисто вероятностны. ДОЛЖНЫ в норме быть совпадения, потому что они меньше файлов.ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятность
>ну и вот, суть хорошей хеш функции заключается в том, чтобы снизить эту вероятностьНе возможно. Можно только увеличить. :)
Криптографический hash отличается тем, что вычислить другие варианты оригиналов сложно (в идеале не проще полного перебора комбинаций).
Но при этом вероятность того, что ваш меганакрученный пароль из ста слов имеет коллизию с одним символом пробел, тоже можно лишь попробовав. :)
Возможно, просто нужно подобрать правильный алгоритм у которого максимальный период исчерпаемости
Максимальный у hash=значение, но его легко подделать :)
> Максимальный у hash=значение, но его легко подделать :)Максимальный у Hash>>значение, но он нахрен не нужен :-)
Случайно вы не получите одинаковый хэш даже с MD5.
Ну, то есть, вероятность есть, но примерно такая же, как вероятность падения метеорита вам на голову.А если к вашим HDD с бэкапами имеют неограниченный доступ посторонние люди, то скорее этот вопрос надо решать.
у RSA даже есть свойство рефлексивности, когда m^e mod n = m
>Случайно вы не получите одинаковый хэш даже с MD5.Случайно CRC32 получить тяжело. Специально - гораздо легче.
> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018АНБ оно такое АНБ.
> Дополнительно можно отметить публикацию результатов криптоанализа блочных шифров SIMON-32/64, разработанных АНБ США и в 2018 году утверждённых в качестве стандарта ISO/IEC 29167-21:2018.Эта публикация - чья-то дурацкая шутка. SIMON-32/64 - шифр с 32-битным блоком и 64-битным ключом. 64-битный "блок" YHWHYHWH, который они зашифровывают - это на самом деле 32-битный блок YHWH, повторенный 2 раза. Сложность задачи от того, что блок повторён дважды, не возрастает. Для того, чтобы найти ключ, превращающий YHWHYHWH в YHWHYHWH, достаточно перебрать 2^32 ключей. Это несколько дней брутфорса на современной персоналке. Это вовсе не означает, что шифр скомпрометирован - это верно для любого шифра с 32-битным блоком. Они же выставляют это как "достижения", доказывающие, что они скомпрометировали шифр. Уберите эту чушь из новости.
>При таком уровне вычислений ориентировочная стоимость атаки составляет менее ста тысяч долларов, что вполне по карману спецслужбам и крупным корпорациям.Атаковать неуловимых Джо бабла не напасутся.
При тех же мощностях Гуглу нужно меньше двух дней, да уж безопасненько)))
На что? На то, чтобы создать сертификаты для www.google.com и www.microsoft.com с одинаковой подписью? Да. Но они оба будут игнорироваться браузером, потому что ему нужна другая.
Вот запороть git репо можно. Но цена вопроса в 100 тыс баксов. :)