Как стать автором
Обновить
77
0

Пользователь

Отправить сообщение

Вместо SRP лучше использовать современные PAKE алгоритмы на основе эллиптических кривых, например, OPAQUE или SPAKE2.

>Эллиптические кривые используются в криптографии относительно недавно и ещё слабо изучены.

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

>Однако на сегодняшний день не известно методик, которые бы однозначно могли оценить надёжность кривых.

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

Если не углубляться в детали языка и историю развития, то основная проблема D в том что он "не взлетел", что лишает его синергетического эффекта, а учитывая возраст языка и наличие сильных конкурентов вероятность "взлететь" в будущем слишком мала дабы серьёзно в него инвестировать.

С Go же, на мой взгляд, ситуация следующая: если вас устраивает наличие сборщика мусора, желательна асинхронщина, разрабатываемая программа не особо крупная (скажем, в пределе нескольких сот тысяч строк) и вы готовы мириться с определённым примитивизмом языка (и тем более если для вас это является достоинством), то вариант действительно очень хороший и, вероятно, выигрывающий у Раста.

>гарантии и от того высокая цена разработки

Цена "высока" только если измерять отрезок хренак-хренак и в продакшн. Если же брать в сумме с последующим дебагингом и развитием получившегося творения, то ситуация уже далеко не так однозначна и начинает зависеть от множества факторов. Плюс цена разработки падает с увеличением опыта. Да, в первые месяцы Rust будет значительно менее продуктивен по сравнению с языками вроде Go изученными с нуля на том же сроке, но освоившись продуктивность (по моему опыту и отзывам других людей) становится сравнимой. Более того, становится страшно писать что-то крупное на языках без гарантий и возможностей которые даёт Rust.

>Один только взгляд на синтаксис отбивает желание с ним связываться.

Честно говоря, мне это нытьё про синтаксис совершенно непонятно. Да, есть неудачные моменты вроде турборыбы и дублирования ограничений в `impl` блоках, но в основной массе претензии к синтаксису выглядят либо как синдром утёнка, либо жалобами на то что компилятору нужно сообщать больше информации в сигнатурах (отсюда код для незнакомых с языком выглядит излишне "нагруженным"). Информационная плотность сигнатур, после привыкания наоборот становится плюсом.

Для чего газифицировать мусор при сжигании более-менее понятно (см. высокотемпературный пиролиз), т.к. там много органики, в частности пластика. Но для чего газифицировать уголь? Он же в основном состоит из углерода, особенно антрациты (более 90% углерода по массе). Каково содержание несвязанного углерода в саже на выходе газификатора? Если недожигается значительная его часть, то это означает что в КПД мы теряем и часть потенциальной энергии тупо закапывается в асфальт и бетон.

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

Настоятельно рекомендую ознакомиться с геометрической алгеброй, которая является натуральным обобщением кватернионов на самые разные пространства. Есть достаточно статей в которых рассматривается формулировка СТО/ОТО в терминах ГА.

Без обязательного self-custody ключей и подробно описанного протокола для которого можно написать свой клиент доверия к системе априори быть не может. Причём ключи должны быть достаточно важными (на уровне возможности создания юридически значимых ЭЦП) дабы их нельзя было собирать или покупать пачками. Блокчейны тоже по сути дела не нужны и являются пусканием модной пыли в глаза.

>Обрезать в ноль финансирование МЦСТ тоже не следует.

Так никто вроде и не говорит что нужно МЦСТ банкротить прям завтра. Но вот касательно того что на него стоит делать основную ставку (как было до сих пор), тут возникают большие вопросы.

>Ну потому что 100% существует ниша, где VLIW будет справляться лучше чем GPCPU.

Проблема в том, что эта ниша (в моём понимании) чрезвычайно мала. VLIW тут с одной стороны сильно зажат SIMD инструкциями и GPU, а с другой технологией внеочередного исполнения, которое в некотором смысле является "автоматическим" VLIW реализуемым самим железом, а не компилятором.

Нет, это сравнение одних и тех же км/ч, но в одном случае это речное судно, а во втором автомобиль. Сделать автомобиль ездящий на скорости 100 км/ч значительно проще чем аналогичное судно. Да, на судно можно загрузить больше груза тем самым скомпенсировав его меньшую скорость (числодробительные задачи по типу БПФ), но большую часть времени пользователям достаточно багажника (код с сильными внутренними зависимостями), либо они заказывают перевозку ж/д транспортом (массивный параллелизм на GPU).

>Когда-нибудь в мемуарах выяснится

Так вроде это особым секретом и не является, не?

>Я думаю, что уже надо остать от Эльбруса

Напомню с чего начался нынешний сыр-бор: в Минпромторге решили внимательно подумать над целесообразностью дальнейшего финансирования разработки Эльбруса, после чего МЦСТ начало публично жаловаться на "подрыв доверия" и захотело введения госплана. Разумеется, конкуренты делающие ставку на ARM/RISC-V начали активно суетиться в надежде отъесть кусок бюджетного пирога выделяемого на МЦСТ.

Теперь вопрос: кто на ваш взгляд имеет больше перспектив на хоть какой-то рыночный успех Эльбрус или разработки на основе ARM/RISC-V, особенно учитывая культуру тотальной закрытости первого? Иначе говоря, к Эльбрусу никто бы не приставал если бы МЦСТ разрабатывало его за собственный, а не государственный счёт.

Благо не Эльбрусом единым и в России есть компании обладающие компетенцией в разработке ARM и RISC-V процессоров.

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

Так же не увидел каких-то предметных недостатков конкретно применения блокчейна.

Ещё раз: дело не в недостатке блокчейна, а в его полной ненужности, и даже вредности если говорить об общей сложности системы, которая и без блокчейнов слишком сложна для понятия большинством граждан.


Я же вроде достаточно наглядно показал, что в целях защиты от игнорирования принятого голоса достаточно публикации условным ЦИКом архива с принятыми голосами по окончанию процесса голосования (достаточно даже простого набора блобов, без организации их в цепочку Меркла) и получения голосующими криптографической расписки подписанной ЦИКом факта принятия голоса. Если появляется хотя бы один голос подтверждённый распиской, но не включённый в финальный архив голосования, то это означает, что ЦИК мухлевал с принятием голосов и итоги голосования должны быть отменены, виновные покараны и т.д.


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


Если мы боимся, что ЦИК будет отказываться принимать голоса из оппозиционных районов прикидываясь шлангом и ссылаясь на технические проблемы, то мы вполне себе можем ввести "прокси" для приёма голосов поддерживающиеся теми или иными общественными организациями, которым ЦИКу будет значительно сложнее отказывать с приёмом голосов (и т.к. подписи электронные, то не получится отфильтровывать "неправильные" подписи). В конечном счёте, решение проблема с отказом приёма голосов всё-равно сводится к социальным методам.


Зачем здесь распределенность — кажется очевидно.

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


Вы говорите про «предъявление старой ветки дерева Меркла» в случае если централизованная БД будет изменена оператором, но как будет в реальности решаться такая коллизия?

Очень просто, если обе ветки были подписаны ЦИКом, то мы имеем на руках криптографическое доказательство того что он не выполнял свои обязанности должным образом, поэтому как и выше отменяем результаты голосования и караем виновных.


Распределённая БД в виде блокчейна это ненужная сложность в условиях неизбежного наличия центрального органа проводящего голосование и ответственного за него. Мы в любом случае полагаемся на данный "орган", от исполнения роли УЦ подтверждающего ЭЦП граждан и до поддержки инфраструктуры голосования, включающей в себя железо, софт и протоколы. Основной вклад блокчейна это практическая демонстрация возможности построения протокола в котором нет центрального авторитета, что просто напросто не соответствует обсуждаемым условиями. Да, мы хотим как можно больше повысить прозрачность работы данного авторитета и сузить возможности для неправомерного вмешательства в процесс, но как выше описано получить похожие гарантии можно и более простыми средствами.


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

Вы прочитали комментарии по ссылке или нет? Потому что "смысл" приведённый вами в статье это набор пустых маркетинговых заявлений, тогда как по ссылке я наглядно аргументирую почему блокчейн (и в смысле распределённой бухгалтерской книги и даже в смысле простой цепи Меркла) это неоправданное усложнение системы никоим образом принципиально не улучшающее свойства системы электронного голосования. Разумеется, буду рад услышать нормальную контр-аргументацию.

Будьте добры внимательно прочитать комментарии по ссылке и если после этого вы будете считать так же, то более подробно привести конкретную контр-аргументацию.

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


Как я уже писал здесь, блокчейн не добавляет ничего принципиального к свойствам системы электронного голосования по сравнению с централизованной системой выдающей подписанные подтверждения принятия голоса и публикацией принятых голосов (не важно делается это во время или по окончанию голосования). Разумеется, я здесь говорю о именно голосовании вида "один гражданин — один голос" с центральным органом определяющим кто является гражданином, а кто нет. В случае голосования вида "акционерное общество" где голос даётся владеющему токеном и имеется возможность передачи и накопления токенов использование блокчейнов и "умных" контрактов имеет определённый смысл.

Если что, этот код писался по большей части мной. :) Суть в том, что методы хотящие alloc опциональны и скрыты за feature gate'ом (и, насколько я знаю, на практике практически не используются), фундаментом же, на котором строятся остальные методы, являются методы работающие над &mut [Block<C>] (по сути &mut [[u8; Self::BLOCK_SIZE]]), т.е. которым ни только аллокатор не нужен, но и для которых принципиально гарантируется успешность исполнения (в идеале хотелось бы ещё и no_panic аннотаций, но чего нет того нет). Аналогичная ситуация с инициализацией, есть фундаментальные методы принимающие ключ и IV в виде ссылок на массивы фиксированных размеров для которых гарантируется успешность исполнения, поверх которых уже построены методы принимающие слайсы. Плюс, если обратите внимание, никакого builder pattern'а ни в этом, ни в большинстве других RustCrypto крейтов нет.


С вашими утверждениями выше про типажи (трейты) я в целом согласен.

Допустим, у нас есть алгоритм, который шифрует произвольную u8 блоками по 64 байта. На вход подают [u8;22]. И как тут быть шифроалгоритму?

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


Суть в том, что фундаментом являются no_std-дружелюбные методы не содержащие внутри паник, поверх которых уже надстраиваются более удобные методы.

В обоих случаях это выработка ключевого материала на основе пароля, разница только в том как этот ключевой материал используется дальше. Обратите внимание, что PBKDF это аббревиатура от Password-Based Key Derivation Function. Без использования подобной функции вы существенно облегчаете задачу подбора пароля даже в сценарии с шифрованием файла, т.е. условно злоумышленник может проводит атаку по словарю и смотреть получается ли при расшифровке первых блоков что-то осознанное или нет.

Я бы не назвал ваш код идиоматичным тоже. Во-первых, для чего title? Во-вторых, использование векторов, когда массивы вполне выполнят роль и позволят убрать ненужные проверки ошибок. В-третьих, использование owned-типов (предположительно снова векторов), тогда как криптографический код обычно предпочитает работать in-place (т.е. над &mut [u8]) из соображений эффективности. Ну и в-четвёртых, если мы говорим о кастомных S-box'ах, то их лучше делать константными параметрами, например, см. как сделано magma (единственное, тут из-за MSRV тут используется тип с ассоциированными константами в реализации типажа, вместо константы напрямую).


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

Примечание: я один из мейнтейнеров проекта RustCrypto.


Подобные начинания безусловно похвальны, но я бы рекомендовал не забывать о хотя бы поверхностном обзоре prior art, ибо это позволит в свой "велосипед" позаимствовать те или иные удачные идеи. Например, в крейте kuznyechik реализация принципиально идентична описанной в статье (что вполне ожидаемо), но уделяется отдельное внимание разворачиванию циклов, что позволяет получить дополнительную производительность в ущерб размеру бинарника (это разворачивание при необходимости можно отключить флагом no_unroll).


Но более существенное отличие заключается в том, что kuznyechik интегрируется в остальную экосистему RustCrypto посредством реализации типажей из крейта cipher, тем самым блочный шифр легко может использоваться с обобщённой реализацией CMAC, блочных режимов и другими крейтами (например, MGM). Это означает, что реализации подобных алгоритмов не привязаны к конкретным блочным шифрам, а значит мы можем использовать их например с Магмой или с кастомным Кузнейчиком с исправленным S-box'ом.


Ну и напоследок, упомяну о дополнительной фиче, полезной в отдельных случаях. В RustCrypto мы можем использовать как Cmac<Kuznyechik>, так и Cmac<&Kuznyechik>, т.к. типажи блочных шифров реализованы для &T если T реализует эти типажи. Разумеется, во втором случае мы не можем инициализировать структуру по ключу, только по ссылке на уже инициализированный блочный шифр.

Я конечно понимаю, что первое апреля и все дела, но таки подчеркну для тех кто не совсем в теме: влияние квантовых компьютеров на симметричную криптографию достаточно мало. В самом худшем случае они уменьшают стойкость шифров в два раза (т.е. условный AES-256 будет обеспечивать уровень безопасности равный 128 битам), так что для обеспечения нужного уровня безопасности нужно будет всего лишь использовать в два раза более длинный ключ. Основные страсти вокруг квантовых компьютеров крутятся в области асимметричной криптографии.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность