IT в России и мире в реалиях мирового кризиса
1,423,799
8,495
|
DimonT ( Слушатель ) |
| 27 окт 2019 09:49:02 |
Quantum Supremacy
новая дискуссия Новость 675
23/10/19 в Nature вышла статья что Google достиг quantum supremacy (решение задачи практически невозможной классическому суперкомпьютеру) на экспериментальном процессоре Sycamore..
(Nature) Quantum supremacy using a programmable superconducting processor
PS
Хотя еще не очень понятно насколько все это готово для практического использования, но есть подозрение что для начала вся текущая криптография вот-вот окажется на одной полке со свитками в коде Цезаря и "Энигмами"...
(Nature) Quantum supremacy using a programmable superconducting processor
PS
Хотя еще не очень понятно насколько все это готово для практического использования, но есть подозрение что для начала вся текущая криптография вот-вот окажется на одной полке со свитками в коде Цезаря и "Энигмами"...
Отредактировано: DimonT - 27 окт 2019 10:24:53
ОТВЕТЫ (34)
|
Поверонов ( Слушатель ) |
| 27 окт 2019 10:58:21 |
Цитата: DimonT от 27.10.2019 09:49:02
В практической криптографии важна не столько скорость перебора вариантов, сколько знание критерия останова, то есть распознавание что расшифровка произошла. Так что "brute force" уместен только в применении к известному протоколу передачи шифрованных данных ( с заложенной в протокол контрольной суммой ) В прочих случаях "brute force" бесполезен, то есть что-то вы прочтете, но вот то ли что было написано, лишь посвященный знает. Это как прочтение древних рукописей - вы можете придавать символам любой вам угодный смысл но тот ли это смысл который был заложен автором остается скрытым во тьме веков.
|
|
DimonT ( Слушатель ) |
| 27 окт 2019 12:49:21 |
Цитата: Поверонов от 27.10.2019 10:58:21
Ну еяпп закладывать в шифрование создание наборов "альтернативных" данных для ложных ключей - теоретически возможно, но практически - тоже требует вычислительных мощностей "несколько за пределами" практической применимости на текущей элементной базе и/или создания новых алгоритмов.
Защита же содержимого а ля "говорящие с ветром^2" - требует серьезного пересмотра всего фрэймворка до и после шифрования, так как распознавать "стандартные" типы данных и языки(**) по нынешним временами задача весьма тривиальная и является классической для дешифровки (привет послужившим контролем "шапкам" и подписям в немецких и японских шифрограммах ВМВ). Так что эта защита малоэффективна для "общих" типов данных ( специфичное же типа спец.телеметрий и сейчас не факт что легко и быстро понять даже при незащищенной передаче) .
В любом случае, всё, что сейчас защищено в т.ч. быстрой утратой актуальности (военные тактические системы связи для голоса и т.п.) или принципом "иголка в стоге сена" (деловые шифры и защита широковещательных каналов ) - будут под ударом как минимум до обретения аналогичных возможностей.
* (доб).
** (доб2) в данном случае сам язык или формат данных являются ключом
|
|
Поверонов ( Слушатель ) |
| 27 окт 2019 13:03:09 |
Цитата: DimonT от 27.10.2019 12:49:21
"деловые" сразу отбрасывайте - они в протоколе уже сейчас имеют встроенную контрольную сумму оригинального текста, что позволяет остановить перебор на совпадении контрольных сумм, что значит при необходимости их легко читают уже существующие спецпроцессоры.
Что касается военных там еще перехватить суметь надо и передать туда-обратно в зонах РЭБ, где кванты не помощники.
|
|
DimonT ( Слушатель ) |
| 27 окт 2019 13:28:49 |
Цитата: Поверонов от 27.10.2019 13:03:09
Надо заметить что в статье собственно процессор - ~400 мм^2. Т.е. если "обвязку" упихают во вменяемые размеры - в перспективе дешифраторы м.б. вплоть до ручного исполнения, тогда никаких двусторонних гоняний данных в тыл в ВЦ и обратно.
Т.е. шифрованная тактическая связь "голосом" и тп тогда сразу низведутся до эквивалента "открытого канала"...
Плюс - сложные расчетные модели для восстановления сигнала, неактуальные сейчас по причине "не могем в рилтайме без суперкомпов размером с аудиторию, которых можно посчитать не разуваясь". Физику конечно не обманешь, но вот "по сусекам намести" можно довольно много...
|
Explorer-2000 ( Слушатель ) |
| 27 окт 2019 20:45:18 |
Цитата: Поверонов от 27.10.2019 13:03:09
А зачем они это делают
чтобы упростить жизнь хакерам или их заставляют, если вы про хэш (MAC) так рекомендации сначала шифровать а потом генерить МАС
|
|
Explorer-2000 ( Слушатель ) |
| 27 окт 2019 23:13:08 |
Цитата: Поверонов от 27.10.2019 13:03:09
Вы про какую контрольную сумму говорите
хэш (МАС)? но никто не мешает сначала шифровать затем генерить хэш, это то что рекомендуют, ну и останавливаться на совпадении хэша если сначала вычисляется хэш наверно не правильно потому что вы берёте много разных ключей (MAC ведь может генериться с ключами отличными от ключа шифрования) поэтому вероятность попасть в коллизию совсем не равна нулю. Или вы про какую то другую контрольную сумму говорите но зачем её добавляют?
|
|
Поверонов ( Слушатель ) |
| 28 окт 2019 15:15:59 |
про хэш который вычисляется на оригинальном сообщении или замешанном с ключом и оригинальным сообщением
|
Senya ( Слушатель ) |
| 28 окт 2019 16:19:17 |
Цитата: Поверонов от 28.10.2019 15:15:59
Это актуально для подписи, где сообщение может вообще не шифроваться. Для подтверждения целостности зашифрованного сообщения, как совершенно верно указали, используется MAC (код аутентификациии сообщения). В простейшем варианте это хэш, зашифрованный _другим_ ключом. При равенстве длин, как понимаете, для абсолютно любого варианта сообщения можно подобрать пару ключей шифрования-аутентификации, дающие правильный хэш. Ну если пространство ключей плоское конечно, но вроде сейчас это обязательно.
|
|
Поверонов ( Слушатель ) |
| 28 окт 2019 19:54:40 |
Цитата: Senya от 28.10.2019 16:19:17
Имелось в виду следующее
ЦитатаОдин из архитектурных дефектов версий TLS до 1.3 состоит в том, что соответствующие спецификации предписывают сперва вычислять MAC, а потом шифровать сообщение. То есть, вычисленный код аутентификации присоединяется к открытому тексту сообщения, а потом все вместе зашифровывается. При этом принимающая сторона должна сперва расшифровать полученные данные, а потом - проверить MAC.
но вроде нынче это как-то поменяли.
|
|
Explorer-2000 ( Слушатель ) |
| 29 окт 2019 03:10:10 |
Цитата: Поверонов от 28.10.2019 15:15:59
Дело в том что ключи шифрования и вычисления МАС разные, они сгенерированы из первоначального ключа сессии, но получить один из другого простого пути нет (можно конечно просто обмениваться изначально разными ключами в начале сессии, но ключей может быть нужно много так что проще генерировать из одного). Так что если вы действуете перебором и взяли один ключ и расшифровали сообщение то проверить МАС вы этим ключом не сможете (более того в некоторых алгоритмах МАС применяются 2 ключа и тоже соответственно разные) так что если вы думаете, что наличие внутри зашифрованного сообщения МАС сгенерированного из исходного текста облегчает задачу хакеру то это не верно, на самом деле наоборот. Рекомендуют сначала шифровать, а потом генерить МАС потому что если шифр и МАС оба стойкие то в этом случае ваша система надёжно защищена
. Разумеется в реале никакой гарантии, что выбранный вами алгоритм шифрования следует всем требованиям никиакой нет.
|
|
Поверонов ( Слушатель ) |
| 29 окт 2019 09:35:45 |
В реальности все пользуются не selfmade алгоритмом шифрования, а тем или иным протоколом передачи шифрованных сообщений. И вопрос в том откуда берутся такие протоколы и какой влияние на них имеют спецслужбы. Обычный пользователь даже представать себе не сможет все взаимозависимости полей протокола, и тем более не в состоянии влиять на их формирование и даже выбор.
"Надежда свыше нам дана".
PS В давнее время ( лет 20 назад ) программируя коммерческий протокол шифрования был поражен тем что хэш в протоколе вычислялся по исходному нешифрованному сообщению. Имел единственное объяснение что так нужно кому надо.
|
|
qurvax ( Слушатель ) |
| 30 окт 2019 09:23:13 |
Цитата: Поверонов от 29.10.2019 09:35:45
К слову, я тут когда-то приносил исследование возможности забацать изначально ущербную кривую для ECC. Толком оценить адекватность которого мне мозгов не хватило, но смотрелось весьма убедительно
Как страшна жидь.
|
|
Explorer-2000 ( Слушатель ) |
| 30 окт 2019 15:41:28 |
Цитата: qurvax от 30.10.2019 09:23:13
Так это давно известно, рекомендованные к использованию кривые тоже опубликованы, их можно и самому проверить если есть сомнения.
|
|
qurvax ( Слушатель ) |
| 30 окт 2019 16:31:00 |
Там был пример создания "заряженной" кривой. Не зная, что оная заряжена, доказать что "таки да" - задача того же порядка, что и собсно вскрытие шифрования с ее использованием вообще. Так же обосновывалось, что "самому проверить" доступными средствами факт заряженности не вскрывает. Тобишь вопросы к "рекомендованым" кривым, и вообще к самой практике "рекомендации" оных кем-то там, подымались. Хз, мож и гнали, конечно, это надо в суровом криптоматане шарить, чтобы поймать.
|
|
qurvax ( Слушатель ) |
| 31 окт 2019 08:58:59 |
Толи я был бухой, толи че - поста с ссылкой не нахожу, хотя был свято прям уверен, что сюда тащил. Ладно, на досуге покопаю, авось в гугеле найду. А пока можете считать, что я набредил.
|
|
plazma ( Слушатель ) |
| 03 ноя 2019 08:42:53 |
Не так давно реализовывали шифрацию по алгоритму DES для одного применения. Там сильной криптостойкости было не нужно, а размер имел значение.
Так вот. 2 команды, embedded и на ПК одновременно написали код шифрации-дешифрации и все заработало.
Библиотеки стандартные, чего там делать?
Спустя некоторое время, при тестировании дотошный товарищ вдруг выяснил, что можно расшифровывать сообщения не зная секретного пароля.
WTF, сказали все и начали копать.
Оказалось, что в описании, исходниках 2-х различных реализаций "закралась" очепятка. Поля секретный ключ и начальный вектор инициализации были перепутаны названиями.
Также были "перепутаны" все примеры и схемы.
Т.е. секретный ключ становится вектором инициализации и наоборот. Т.е. вектор был константным - то первый блок был ещё зашифрованным, а вот последующие кололись как орехи, самостоятельно.
И нигде нет описания такой "ошибки". Сколько тысяч программ использует стандартную библиотеку с таким троянским конем?
Так что даже кривые специальные не нужны...
|
|
Senya ( Слушатель ) |
| 03 ноя 2019 15:45:23 |
Цитата: slavae от 03.11.2019 15:20:57
Хотел написать, что на такое случаи тестовые вектора есть, ан нет, сунулся в fips46, описание есть, вектора отсутствуют.
|
|
Explorer-2000 ( Слушатель ) |
| 03 ноя 2019 22:31:04 |
Цитата: plazma от 03.11.2019 08:42:53
Ну в реальной жизни чего только не бывает
, хотя конечно странно, DES давненько уже не используется, но использовался долго, как я понимаю вы испольховали 2 разные библиотеки на разных сторонах и в обеих была ошибка, но думаю что эти же библиотеки использовались в других сочетаниях и что ни разу не обнаружили ошибку или такая ошибка во всех, не обнаружить такую ошибку за долгое время это очень странно, какие библиотеки то хоть? Кстати этот дотошный товарищ то как это обнаружил
|
|
Поверонов ( Слушатель ) |
| 03 ноя 2019 22:37:39 |
Помнится DES использовался в PGP - "троянском коне" Циммермана.
|
|
Senya ( Слушатель ) |
| 30 окт 2019 16:50:09 |
Цитата: qurvax от 30.10.2019 09:23:13
Извиняюсь, так и не смог найти. Хотя бы когда ориентировочно по срокам?
|
|
dmitriк62 ( Слушатель ) |
| 28 окт 2019 07:24:14 |
Цитата: Поверонов от 27.10.2019 10:58:21
Например, если у вас свой агент работает начальником их разведки и приказывает каждое сообщение заканчивать словами "heil Hitler"
|
|
Senya ( Слушатель ) |
| 27 окт 2019 13:39:29 |
Цитата: DimonT от 27.10.2019 09:49:02
Я стараюсь внимательно следить за темой, но тоже не могу понять, на какой именно этап вышел Гугль. В моей молодости уже не использовались, но ещё были на слуху аналоговые вычислительные машины, где коэффициенты дифференциальных уравнений набирались сопротивлениями и конденсаторами, после чего переходный процесс за разумное время устанавливал в ключевых точках искомые напряжения - решение уравнения с достаточной для практики точностью. Чем дальше в лес, тем
Вот только к криптографии это никакого отношения не имеет. Вообще - даже если сбудутся самые оптимистичные и фантастические планы относительно квантовых компьютеров, для симметричных шифров это означает только сокращение длины ключа в два раза. От типовых на сегодня 256 бит до 128 (10^38 прогонов на квантовом компе, сколько там раз в секунду можно фиксировать состояние системы?), аналогично для хэш-функций. Для асимметричного шифрования в поле точек эллиптической кривой скорее всего так же. Диффи-Хеллман (дискретное логарифмирование) скорее всего будет разобран, и гарантированно будет разобран RSA. Ну когда от 53 кубитов перейдут как минимум к 512, и точность подтянут. Приятно конечно знать, что в рассчитанном ключе из 500 бит только 5 неправильных, всего то 34 триллиона попыток останется.
Но если первые эксперименты имели хоть какое-то отношение к разложению на множители, то сейчас Гугль сделал неизвестно что. Может аналоговую ЭВМ на квантовой базе для задачи коммивояжера или что-то в этом роде. Так что криптографии эти эксперименты не угрожают никак.
|
|
Head790 ( Слушатель ) |
| 27 окт 2019 15:10:58 |
Цитата: Senya от 27.10.2019 13:39:29
Сомнительно. Даже с учётом отсутствия их у простых смертных. Алгоритмы на основе эллиптических кривых(ECDSA) уязвимы к атакам квантового компьютера. Увеличение длины ключей - экстенсивное решение. Думаю, через несколько лет использование квантостойких хэшей, например, будет более массовым(а в случае с блокчейнами - раньше, такие уже есть - https://github.com/theQRL). Эта проблема обсуждалась за много лет до недавних новостей Гугла, "сделавшего неизвестно что", т.к. грамотнее работать на упреждение уже известной потенциальной проблемы.
Интересно, когда с SSL и др. протоколами основательно поэкспериментируют и поделятся результатами.
|
|
Senya ( Слушатель ) |
| 27 окт 2019 16:24:24 |
Цитата: Head790 от 27.10.2019 15:10:58
Я здесь не вижу смысла бежать впереди паровоза. Продемонстрированный максимум это разложение числа 15 на простые множители 3 и 5. Даже до 512-бит RSA... долго. На государственном уровне тоже шевелений нет. RSA не стандартизовали никогда, DH в электронной подписи не продержались и 5 лет (считаем что у нас, что у амеров), а принятой почти 20 лет назад эллиптике на замену даже теоретически ничего не рассматривают. Это при том, что в стойкой подписи в гражданском применении (в отличие от стойкого шифрования) государство по настоящему заинтересовано.
Что же касается энтузиастов, я им по-хорошему завидую, но их энтузиазма не разделяю. Взлом современных алгоритмов на квантовом компьютере для меня на уровне марсианской базы. Без фанатиков дела не будет никогда, с фанатиками - когда-нибудь. Не при моей жизни.
|
|
Head790 ( Слушатель ) |
| 27 окт 2019 18:48:29 |
Цитата: Senya от 27.10.2019 16:24:24
Если так рассуждать, то почему бы не откатиться обратно к использованию SSL 2 и TLS 1.0?
Цитата: Senya от 27.10.2019 16:24:24
Поищите, какие вопросы в этом плане поднимаются в NIST, в том числе про квантоустойчивое шифрование.
Цитата: Senya от 27.10.2019 16:24:24
Думаю, и в начале 2000-х находились те, кто считал шифрование трафика сайтов баловством.
Это как с ядерным оружием, например - ни США ни Россия его применять не собираются, и даже паки с индусами, но тем не менее его модернизируют и поддерживают в рабочем состоянии. На всякий случай, чтоб потом не жалеть, если с одной из сторон заведётся фанатик, который запустит ракеты. Ущерб от взлома алгоритмов шифрования, которые и банки используют, если атаку проведут на критически важные объекты, вряд ли будет маленьким.
ЦитатаВзлом современных алгоритмов на квантовом компьютере для меня на уровне марсианской базы
так от космических исследований вообще толку мало для 99.99% населения планеты, если так судить:)
Про крипту пишут, что блокчейны ряда монет в нынешнем состоянии могут быть взломаны уже через 5 лет с помощью квантового компьютера. Но даже не смотря на то, что пока их никто особо не ломал, периодически их хозяева обновляют своё хозяйство в плане безопасности.
|
|
Senya ( Слушатель ) |
| 27 окт 2019 19:21:04 |
Цитата: Head790 от 27.10.2019 18:48:29
Я в курсе этих аргументов и даже согласен с ними. Но простите мне некоторое брюзжание - я один раз и больше не буду - слышу и читаю их уже больше двадцати лет и немного устал. Квантовый обмен ключами был реален тогда и реален сейчас. А вот энтузиазм и опасения насчёт квантового взлома шифров за такой долгий срок поугасли. Ну да и без меня найдутся те, кому это интересно
|
adolfus ( Слушатель ) |
| 30 окт 2019 01:53:10 |
Цитата: Senya от 27.10.2019 16:24:24
512 бит RSA – это середина 90-х. Сегодня обычно ключ ssh 2к, а многие и поболее генерят.
|
|
Senya ( Слушатель ) |
| 30 окт 2019 08:03:47 |
Цитата: adolfus от 30.10.2019 01:53:10
Так я и привёл как минимум миниморум.
Цитата: adolfus от 30.10.2019 01:53:10
Было где-то в качестве анекдота, но почему бы и нет - что на биржах до сих пор RSA512 и DES-56 в ходу. До конца текущей сессии всё равно не сломают, а по окончании всё и так публикуется.
|
|
plazma ( Слушатель ) |
| 03 ноя 2019 08:34:24 |
Цитата: adolfus от 30.10.2019 01:53:10
Аналогичные явления мы наблюдаем и в цифровых камерах, чем больше мегапукселей тем камера ведь круче?
А по факту взломайте ка 512 бит за приемлемое время и деньги?!