Разработчики проекта OpenBSD представили (https://www.mail-archive.com/announce@openbsd.org/msg00...) выпуск переносимой редакции пакета LibreSSL 2.8.1 (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Проект LibreSSL ориентирован на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы. Ветка LibreSSL 2.8.x рассматривается как экспериментальная, в которой развиваются возможности для включения в состав OpenBSD 6.4.
Особенности LibreSSL 2.8.1:
- Добавлены тестовые векторы для проверки корректности реализаций ECDH, RSASSA-PSS, AES-GCM,
AES-CMAC, AES-CCM, AES-CBC-PKCS5, DSA, ChaCha20-Poly1305, ECDSA и
X25519 при помощи инструментария для проверки криптографических библиотек Wycheproof (https://www.opennet.ru/opennews/art.shtml?num=45725);
- Упрощён код генерации и проверки цифровых подписей при обмене ключами;
- Очередная порция кода переведена на использование подсистем CBB/CBS, в том числе на CBB переведён код обработки сообщений при согласовании соединений;
- Устранено несколько утечек памяти;
- Упрощён разбор и обработка сессионных тикетов по аналогии с реализацией из BoringSSL;- В SSL_copy_session_id, PEM_Sign, EVP_EncodeUpdate, BIO_set_cipher,
X509_OBJECT_up_ref_count обеспечен возврат целочисленного кода ошибки, соответствующего OpenSSL;- Некоторые #defines-макросы заменены на функции для соответствия c ABI OpenSSL;
- Из OpenSSL перенесена функция X509_get0_serialNumber;
- Для соответствия OpenSSL удалены EVP_PKEY2PKCS8_broken и PKCS8_set_broken. Добавлены PKCS8_pkey_add1_attr_by_NID и PKCS8_pkey_get0_attrs;
- Из утилиты openssl удалена неработающая поддержка форматов pkcs8;
- Некоторые функции из публичного API переведены на использование const для аргументов;
- Добавлен не подверженный тайминг-атакам код проверки результатов верификации цифровых подписей;
- Добавлены дополнительные тесты шифров в appstest.sh, включая все шифры для TLSv1.2;
- Из OpenSSL перенесены функции RSA_meth_get_finish() и RSA_meth_set1_name();
- Добавлен новый API EVP_CIPHER_CTX_(get|set)_iv() для получения вектора инициализации с целью проведения его верификации.
URL: https://www.mail-archive.com/announce@openbsd.org/msg00...
Новость: https://www.opennet.ru/opennews/art.shtml?num=49353
Отличная либа!
Да либа классная, а главное удобная (libtls), однако про планы на развитие TLS 1.3 ничего разрабы не пишут. Печально.
я_тут_же>>> Когда слышу / читаю о «Цифровых подписях» - просто блевать охота.. Как же дурят весь мир...я>>Модератор, интересно - чего это вы удалили мой пост тут - про цифровые подписи?
я>>Upd: Что, соучаствуем в сговоре? Не ну что ещё остаётся думать то? Разъясните что ли.Sw00p aka Jerom> аргументы в студию, %хамства% !!!
Что то вы на модератора не похожи... Что совсем тупой? Вопрос был не к вам!
А, с таким отношение, в ч.н.подозреваю что реально русoфобским, то я вам вообще ничего не
обязан! (Ну, может кроме пули в лоб засадить, как нибудь, за оскорбление и вообще русoфобию).
========
я_затем(и перед этим написал - типа ну ладно, раз хотите аргументов ждите, ага уже - хотят они реально! быстренько забанили...):Ну да ладно, раз мадератор педалит мнение Sw00p aka Jerom и просто для общей пользы
- мне почти не сложно(ну, всего-лишь весь выходной испортил!) ответить на то
почему я считаю (любые) «Цифровые подписи» - фейком или юридически подлогом:Я когда то на другом методе показывал, но это лень искать. Тем более что есть и другой, даже более понятный/наглядный не требующий никаких спецзнаний для понимания, метод доказательства:
Положение-1: Как нельзя гарантированно сжать условный 1 kB/MB/GB (любых...)данных - например в 1 байт
(иначе сказать: в весьма ограниченные числом - 256 значений комбинаций оригинала),
так нельзя сжать их - в применяемые в «Цифровой подписи» число байт.Положение-2: Любые сжатые данные без потерь(LOOSELESS)
- являются не только эквивалентом оригинала, но и т.ск.гарантированной «Цифровой подписью без шифрации»
(наравне с например передачей оригинальных данных по альтернативному более защищённому каналу).Но, вот в современном мире "почему то" «Цифровая подпись» - аналог вовсе не перечисленному,
а сжатию с потерями (LOOSE-сжатию)! Т.е.вроде JPG или Wavelet сжатию.Кому сложно понять пример с JPG, можно вообще уйти от картинок - перейдя хоть к реальной(бумажной) подписи! Достаточно пропустить следующий абзац.
В типичиной «Цифровой подписи» - сжимая даже куда сильней чем у JPG - фактически без ограничений, например в 1:1000000, когда по сути после сжатия полученная картинка/блок - станут одноцветны(как бы одним пикселом растянутым) если всё распаковать, и что всё с внушений пиаристов «Цифровых подписей»/Internet-вещей/НМП - фактически якобы позволяется "верифицировать" этой подписью... т.ск.методом сжатия второй/проверяемой картинки и затем с последующим сравнением обоих в сжатом виде бинарно (для наглядности очень упрощённо говоря).
Несмотря на значительное отличие процесса верификации в реальной «Цифровой подписи» эта неточность является весьма подходящей условностью - для наглядности, суть та же. (В т.ч.даже разница в том что небольшие отклонения в цвете не будут вовсе заметны - в отличие от алгоритма «Цифровой подписи»: совершенно обманчива, ибо тут рассматривается пример - именно наглядно: без криптографии, о ней пойдёт речь ниже - интересующимся, а с ней - любые мелкие измененя цвета тоже превратятся аналогично «Цифровой подписи» - в непрогнозируемые, в т.ч.опционально и в крупные, точней заметные в полученном результате).
Речь про то что нам предлагается верить что с момощью «Цифровой подписи», в ч.н. с этим упрощением - картинка ставшая вырожденной в 1 пиксел: (гарантированно!)идентифицирует как отличную картину - любую иную (вопрос надёжности криптоалгоритма и фалльсификата даже не рассматриваю тут). Например, при совпадении этого пиксела: голубое небо над городом А - будет якобы гарантирванно равно небу только для города А в тот момент, а никак не любому другому городу с приблизительно таким же цветом и пропорцией к облакам. Что наглая ложь. (Ибо в данном примере они скорей вообще все совпадут - в указанных условиях).Кому сложно понять пример с JPG, или для объяснения другим людям - далёким от программировния и даже фотошопов, т.е.совсем далеких от ПК, можно вообще уйти от картинок - перейдя хоть к реальной(бумажной) подписи!
Выше речь про то что, нам всем предлагается(реальней сказать - активно и многомиллиардно навязывается - через госаппараты стран мира): проверять тождественность подписей т.ск.по соскабливанию вещества ручки(или же пера) с бумаги с оригинальной подписью человека и затем настаивании что получившийся суммарный цвет той кучки вещества(фактически то - приблизительно цвет с оттенком у самой ручки...) есть не что иное - как подпись(юридически)!...
Которая так или иначе участвует в верификации подлинности в зависимости от реализации, для наглядности упрощая - пусть это тут будет прямое сравнение цветов двух полученных кучек материала, с оригинальной и с проверяемой подписью.
(конечно в «Цифровой подписи» - всё ещё более запутанно-хитро, для оболванивания: этот полученный цвет - криптографически изменяется(необязательно одноуровнёво) на другой "цвет", под предлогом недопущения заполучения мошенниками т.ск."цвета кучки" ...т.е.оригинальной "ручки"/пароля/ключа; впрочем, шифрация ущербна сама по себе - ибо число цветов ограниченно...; но, это криптование для понимания верификации - не важно, т.к. защита это другой уровень, и для наглядности верификации его можно безболезненно хоть вообще опустить)
Суммируя же: внушается что эта псевдо-уникальная кучка (в данном случае: «НЕцифровая "подпись"»)
- является средством (якобы гарантированной) идентификации,,,
причём даже не ручки/пера - а, даже подписи...
(На вопрос тут, технически как бы обосновывая отвечая нам неявно: что, например у разных подписей даже одной ручкой - всёравно разный объём материала останется на бумаге, что немного повлияет на усреднённость цвета перемешающегося с бумагой при соскабливании. Вот только умалчивая что несовадение верификации разных подписей тут всёравно носят заметно-случайный, иначе как любят всегда отмазываться - вероятностный, характер...
Проще сказать запросто даже непреднамеренно найдётся подпись с точно такими же характерами у её кучки материала.
В глубинах технической документации оригинальных авторов методов, как обычно, настаивают на сверх-низкой вероятности коллиизий - приводимыми сверхбольшими цифрами, но они реально: вообще любые - являющимися не такими уж и невероятными! И тем более если понимать природу методов Теории вероятности, котороя применима - только для *анализа* *больших единиц* т.ск.сверху, а уж никак не выдачи каких-либо гараний отсутствия внеплановости - на уровне ниже, вроде неожиданных коллизий у разных подписей поверющему подписи и конечному пользователю по последствиям)
Но, можно и иначе показать вместо JPG/Wavelet с ещё другой стороны:
с помощью операции Zoom уменьшить картинку *любого* размера хоть до 1-го пиксела(или n-бит Цифровых подписей), (к слову это фактически тоже Сжатие-с-потерями(LOOSE-сжатие)),
и значит нам предлагается считать этот 1 пиксел(иначе: полученный набор пикселов) - «Цифровой подписью»...
Но, тут в отличие от предлагаемых нам в «Цифровой подписи» - всё в чистом виде: без замыливающих глаза общественности криптографий, которую легко учесть/наглядно показать даже в этих примерах - надо только вставить криптографический блок с [случайно сгенерированным] паролем/ключём - перед сжатием-JPG/Wavelet или анализом цвета ручки из примера с бумагой или ZOOM-ужатием картинки каждый раз, т.е. при генерации такой формы «Цифровой подписи» и затем уже при сверки её. Это конечно тоже показательное упрощение алгоритма.Тут неизбежно остаётся момент с откидыванием мной применяемой криптографии - можно ли так поступать? Можно!
Для наглядности же, т.к.упрощение это такой минимум-философский приём.
Более того, потому что она реально т.ск. фиктивна (да, защищает - но,поверхностно… Как и дверные замки: только от "честного вора…", т.е.от распахивания ветром и мимопроходящего менее честных правил - чем у того вора… А, иначе замок этот даже тупо перебором открывается, не говоря уже про случай мастерства и опыта):
Можно. Раз, в соответствии с "Положение-1", в этот условно 1 байт(или n-бит «Цифровой подписи»)
- нереально запихнуть оригинальные данные даже сжатием c потерями! (к которым можно отнести и «Цифровую подпись» просто расжатие до оригинала не требуется).
Т.е.например и визуальная верификация будет хуже чем у JPG с типичным сжатием 1:3-5 размера
(для приемлемого однозначно различимого человеком качества картинки, но и соответствующего размера)..., а будучи тождественно ему но с сжатием что то вроде 1:1000-1000000 в зависимости от исходного размера - имеем что, в оставшийся этот условно 1 байт - нужное несчётное число комбинаций значений оригинальных данных: просто никак невместить. Иначе сказать качество «Цифровый подписей» из-за их смешных размеров - заведо отвратное для даже приблизительной идентификации, а уж про точную... (Впрочем, про неё - прямо ниже).И "Положение-1" - собственно про сжатие без потерь... - как это только и может считаться "однозначной подписью без всяких если пронесёт!" в смысле отсутвия гарантированных коллизий (о чём и речь в "Положение-2"). И тем более коллизий выше даже чем у CRC! О этом подробней далее, а у него к слову - число коллизии: "2 pow (8*(msg_len-crc_len))"... т.е. очень-очень много.
Но, я понимая что всем промыли мозги на тему того что "что можно в 1 байт вместить любой 1 GB" если перефразировать что "условно 1 байтом можно верифицировать подлинность условно 1 GB")
- на необходимости тогда уж именно сжатия без потерь даже не буду останавливаться,
а продолжу рассмотривать особенности предлагаемого миру - аналога сжатия с потерями.Рассмотрим сам блок криптографии:
* с одной стороны: пряча от злоумышленника пароль/ключ и хэш данных(или в терминологии примеров - цвет);
* с другой стороны: не только невлияет на величину числа коллизий - а, даже повышает риск их появления! Чем без шифрации... (Ну т.е.такая вот "цена"). Про них же - см.ниже."Хорошее" на этом не заканчивается... значит эта «Цифровая подпись» - менее приемлема, менее точна в ч.н.для случая отсутсия злого умысла(а, с ним полюбому будет 100% тождественность при его успехе это аксиома, ибо оставленна лазейкой сама возможность успеха), менее точна даже чем тот же JPG с типичным k сжатия 80! (ибо «Цифровая подпись» будучи его аналогом но, при k=1 или даже 0.00001, т.е.фактически проще считать это тем самым "zoom в 1...n пикселов" + навеска из шифро-перетасовки, которую тоже ж можно навесить на JPG/Wavelet сугубо для усиления чувствителности к изменениям значения цветов в оригинале - о чём писалось выше)
Но, ещё более: реально то - из-за т.ск.нелинейности алгоритма(ов) шифрации (если например обычные ChkSum или CRC обозначить тут «линейными») - необязательно но, может так быть что и даже при тождественности или даже большем размере «Цифровой подписи» чем размер самих подписываемых данных: всёравно - всё вышесказанное верно! (а, не только для типичных небольших размеров «Цифровой подписи» относительно размера данных) - не смотря на то что даже любое сжатие в таком случае уже вполне возможно, для уменьшения размера оригинала. Т.е, а «Цифровая подпись» так и останется чёрным ящиком автору исходного послания и доверенному лицу - с гарантированными коллицизями... что тоже вполне себе показатель же!
Про коллизии: тот же CRC, считающийся лучше многих других всяких там ChkSum, реально очень ненадёжный хоть это как то неаффишируется, но ещё давно где то читал что гарантированно выявляет 1 битную ошибку в 512 битном блоке, а всеголишь 2-х битную - уже может тупо незаметить... (и обычно далее начинается свистопляска с числами вероятностей этого, хоть недолжно быть ничего незамеченного для однозначности верификации, далее примеры на почему?), как и более битную ошибку понятно тоже пропускать с всё большими вероятностями вовсе не заоблачными как выглядит в числах... Всё аналогично и при увеличении размера блока...
Кто пользовался DialUp-модемами в наших постсоветских телефонных сетях - знает что, никакие CRC, а то и даже двух-трёхуровнёвые CRC (модем аппаратно-сжимая + поверх X/Y/ZMODEM протокол [+позже архиватор распаковывая может незаметить]) - непомогали выявлять ошибки 100%/гарантированно.
Или вот у меня лично есть даже винчестер на котором не раз(повторяемо) автовосстановление битых секторов: (втихую)авто-восстанавливало сектора - некорректно... И что было видно только по дисфункции ПО или бинарному сравнению с оригиналом. Ибо все алгоритмы коррекции - подразумеают наличие 100%-ой уверенности что сектор бит или цел, а вот с этим то проблема!...
Т.е.получилось что лучше бы Восстанавливающие-коды производители - не применяли... В общем опять маркетинговая разодка.. Сами Восстанавливающие коды, даже вопреки имеющейся опции от стандарта диска - не выключаются: почти целый и почти новый диск - в мусорку, а им доп-ный PROFIT.
А, ныне модное применение .MD5 или .sha1 файлов для обнаружения даже просто дисковых(и сетевых)ошибок (или скажем TTH, торрент и прч.хэшей идентификации для файлов в P2P сетях)
- реально ещё хуже CRC метода (за счёт значительного увеличения коллизий, как из-за "цены" криптоблока тут ненужного, так и просто непредсказуемости нелинейного алгоритма).
Т.е.как можно говорить про противодействие подлогу данных по сети при скачивании у MD5/SHA методов которыми даже дополнительно помечают странички скачек - при зашкаливающих то до бесконечности коллизиях, причём до практически бесконечности - уже в предсказуемой в этом плане CRC, а тут(с той самой шифрацией и прочим) - их ещё больше... Вообще непредсказуемо больше! Всёравно что надеяться на случай, "на авось"... (авось коллизий не будет, если будут - авось будет мало и незаметно и притом не в жизненно неподходяще моменты).
Так что как ни глянь: «Цифровые подписи» - лапша на ушах всем.P.S.
Кстати, данные примеры относятся не только к «Цифровым подписям»,
но и к «Шифрованию с публичным ключом»(https, PGP, и т.д.), понимая это - становиться и ясна реальная изначальная причина ажиотажа например перевода WWW на https - ибо пользы то ноль, зато осуществляется привязка уже не только к DNS [корневым-]серверам, а и доп-но и сертификационным серверам - без которых уже точно ну никак всё чаще не обойтись... если вдруг вы выключите всякие Поисковые подсказки и Web Trust ф-ции + доп-но заблокируете все несанкционированные [эти] соединения браузера, включая понятное дело - и к сертификационным серверам.И мы же понимаем что вообще все удалённые соединения - идут через «Шифрование с публичным ключом»:
учётные записи в ОС подключённой в домен или к удалённому серверу верификации лицензионности ОС - неявно/скрытно или явно с аккаукнтом на web-сервере, любые охранные сигнализации, спутники (тем более военным совсем критично может быть в бою и не только), а в уже совсем недалёком будущем [военные и полицейские] роботы и андроиды...
ну и конечно PASSPORT-чипимплант в каждом.
Да всё.
Вам бы сперва у хорошего доктора малость пролечиться, а затем матчасть подучить.В отношении матчасти скажу кратко: энтропия ЭЦП должна быть достаточной для крайне низкой вероятности случайных коллизий, и крайне высокой вычислительной стоимости для искусственного порождения коллизий (собственно, как части процесса создания цифровой подделки).
Требование, чтобы энтропия ЭЦП была не ниже энтропии подписываемого сообщения - явно избыточно.
просто шикарный поток сознания. шифрование файла и цифровая подпись файла - это две большие разницы. начни учить с азов. может дойдёт.
Возомнившим себя гением вроде вас хаму, пояснять азы и параллели там - себя не уважать.
Кому надо - меня поняли.