IT в России и мире в реалиях мирового кризиса

Цитата: Senya от 28.10.2019 16:19:17Это актуально для подписи, где сообщение может вообще не шифроваться. Для подтверждения целостности зашифрованного сообщения, как совершенно верно указали, используется MAC (код аутентификациии сообщения). В простейшем варианте это хэш, зашифрованный _другим_ ключом. При равенстве длин, как понимаете, для абсолютно любого варианта сообщения можно подобрать пару ключей шифрования-аутентификации, дающие правильный хэш. Ну если пространство ключей плоское конечно, но вроде сейчас это обязательно.

ЦитатаОдин из архитектурных дефектов версий TLS до 1.3 состоит в том, что соответствующие спецификации предписывают сперва вычислять MAC, а потом шифровать сообщение. То есть, вычисленный код аутентификации присоединяется к открытому тексту сообщения, а потом все вместе зашифровывается. При этом принимающая сторона должна сперва расшифровать полученные данные, а потом - проверить MAC.

Цитата: Поверонов от 28.10.2019 15:15:59про хэш который вычисляется на оригинальном сообщении или замешанном с ключом  и оригинальным сообщением

Цитата: Explorer-2000 от 29.10.2019 03:10:10...
Разумеется в реале никакой гарантии, что выбранный вами алгоритм шифрования следует всем требованиям никиакой нет.

Цитата: Head790 от 27.10.2019 15:21:02В гитарных примочках, они, бесспорно актуальны) В частности благодаря ОС:)

Это всё теория. Фильтрация фонового шума качества звучанию не прибавит. 99% людей адекватно не смогут оценить, какой из ваириантов лучше. Условно качественный(_{может быть обратили внимание, что последние полноценные обзоры с измерениями объективных параметров были лет 10 назад, а нынче - лишь субъективная оценка обзорщика различными эпитетами?}) ламповый усилок на лампах стоит бешеных денег, а ещё нужно чем-то воспроизвести звук - слабым звеном будут кленовые аудиофильские колышки акустические системы. 
Ещё добавлю - подавляющее большинство, если не все, изданные композиции поступают в продажу с безвозвратно убитым звуком(в аудиоредакторе часто можно увидеть задранные до безумия уровни), а мастер-копии не продаются.

Цитата: Senya от 27.10.2019 16:24:24Я здесь не вижу смысла бежать впереди паровоза. Продемонстрированный максимум это разложение числа 15 на простые множители 3 и 5. Даже до 512-бит RSA... долго.  На государственном уровне тоже шевелений нет. RSA не стандартизовали никогда, DH в электронной подписи не продержались и 5 лет (считаем что у нас, что у амеров), а принятой почти 20 лет назад эллиптике на замену даже теоретически ничего не рассматривают. Это при том, что в стойкой подписи в гражданском применении (в отличие от стойкого шифрования) государство по настоящему заинтересовано.
Что же касается энтузиастов, я им по-хорошему завидую, но их энтузиазма не разделяю. Взлом современных алгоритмов на квантовом компьютере для меня на уровне марсианской базы. Без фанатиков дела не будет никогда, с фанатиками - когда-нибудь. Не при моей жизни.

Цитата: slavae от 29.10.2019 20:37:48Не то чтобы это было как-то невероятно, мы уже давно готовы к этому, думаю. Нейросеть синтезирует голоса

Цитата: adolfus от 30.10.2019 01:53:10512 бит RSA – это середина 90-х.

Цитата: adolfus от 30.10.2019 01:53:10Сегодня обычно ключ ssh 2к, а многие и поболее генерят.

Цитата: Поверонов от 29.10.2019 09:35:45В реальности все пользуются не selfmade алгоритмом шифрования, а тем или иным протоколом передачи шифрованных сообщений. И вопрос в том откуда берутся такие протоколы и какой влияние на них имеют спецслужбы. Обычный пользователь даже представать себе не сможет все взаимозависимости полей протокола, и тем более не в состоянии влиять на их формирование и даже выбор.
"Надежда свыше нам дана".
PS В давнее время ( лет 20 назад ) программируя коммерческий протокол шифрования был поражен тем что хэш в протоколе вычислялся по исходному нешифрованному сообщению. Имел единственное объяснение что так нужно кому надо.

Цитата: qurvax от 30.10.2019 09:23:13К слову, я тут когда-то приносил исследование возможности забацать изначально ущербную кривую для ECC. Толком оценить адекватность которого мне мозгов не хватило, но смотрелось весьма убедительно Как страшна жидь.

Цитата: Explorer-2000 от 30.10.2019 15:41:28Так это давно известно, рекомендованные к использованию кривые тоже опубликованы, их можно и самому проверить если есть сомнения.

Цитата: qurvax от 30.10.2019 16:31:00Там был пример создания "заряженной" кривой. Не зная, что оная заряжена, доказать что "таки да" - задача того же порядка, что и собсно вскрытие шифрования с ее использованием вообще. Так же обосновывалось, что "самому проверить" доступными средствами факт заряженности не вскрывает. Тобишь вопросы к "рекомендованым" кривым, и вообще к самой практике "рекомендации" оных кем-то там, подымались. Хз, мож и гнали, конечно, это надо в суровом криптоматане шарить, чтобы поймать.

Цитата: Explorer-2000 от 30.10.2019 18:08:12Похоже на конспиралогию.

Цитата: slavae от 02.11.2019 18:51:26Интересная статья https://habr.com/ru/post/473694/

Российская отрасль инженерного программного обеспечения насчитывает более 50 компаний-разработчиков. По меркам мирового рынка САПР это уже заметная величина. Но знаете ли вы, что российский след есть и в известных западных продуктах, например, в CATIA, BricsCAD, Altium Designer? Многие зарубежные САПР-вендоры открыли в России свои R&D центры или сотрудничают с местными аутсорсинговыми компаниями. Кто они – узнаем под катом.

Дальше по ссылке.

Цитата: Explorer-2000 от 30.10.2019 15:41:28Так это давно известно, рекомендованные к использованию кривые тоже опубликованы, их можно и самому проверить если есть сомнения.

Цитата: slavae от 03.11.2019 15:20:57Думаю, DES.

Цитата: plazma от 03.11.2019 08:42:53Не так давно реализовывали шифрацию по алгоритму DES для одного применения. Там сильной криптостойкости было не нужно, а размер имел значение.
Так вот. 2 команды, embedded и на ПК одновременно написали код шифрации-дешифрации и все заработало.
Библиотеки стандартные, чего там делать?
Спустя некоторое время, при тестировании дотошный товарищ вдруг выяснил, что можно расшифровывать сообщения не зная секретного пароля.
WTF, сказали все и начали копать.
Оказалось, что в описании, исходниках 2-х различных реализаций "закралась" очепятка. Поля секретный ключ и начальный вектор инициализации были перепутаны названиями.
Также были "перепутаны" все примеры и схемы.
Т.е. секретный ключ становится вектором инициализации и наоборот. Т.е. вектор был константным - то первый блок был ещё зашифрованным, а вот последующие кололись как орехи, самостоятельно.
И нигде нет описания такой "ошибки". Сколько тысяч программ использует стандартную библиотеку с таким троянским конем?
Так что даже кривые специальные не нужны...