Комп на 20 кубит позволит первопроходцам разрабатывать и тестировать алгоритмы и SDK. Как результат, если(/когда) появиться комп на 2000 кубитов, мир не будет размахивать руками и говорить «мы не знаем как этим пользоваться» :)
Не совсем одно и то-же. В D-Wave группы по _8_ связанных кубитов. Он годиться только для очень специфичных вычислении (например алгоритм имитации отжига). И даже в имитации отжига я пока не встречал доказательств что он быстрее самого быстрого из известных классических алгоритмов.
В IBM же анонсировали компьютер с 50 связанными кубитами. Поправьте если не прав.
Почему ни в одном массовом обзоре SSD не светится Crucial MX300 (1TB)? Уже пару месяцев на него засматриваюсь для покупки. Но, из-за того что о нём молчат, боюсь прогореть. Вроде в обзорах конкретно этого девайся он на уровне Samsung EVO. По цене же на много дешевле. Есть идеи почему он не в моде?
Сижу и думаю: потделать шифрованный сигнал наверное никак.
А что мешает поставить приёмник за 10км от кремля и регенерировать (в идентичности) этот сигнал возле кремля.
В таком случае военный приёмник будет думать что он в 10 км от кремля. Возможна ли такая «атака»?..
2 хэша, безусловно, не хуже чем один.
Если у вас (например) SHA1 и SHA256… и, вдруг, взломают SHA1… второй хэш позволят сидеть спокойно.
НО! при этом, речь совсем о другом. Предположим что хэши не взломаны вообще. В таком случае, сложность находки коллизии в
— MD5: 2^64
— SHA1: 2^80
— SHA256: 2^128
— MD5 + SHA1: 2^80… а не 2^144! (как большинство думает)
— MD5 + SHA256: 2^128… а не 2^208
— MD5 + SHA1 + SHA256: 2^128… а не 2^272
Так что да, в какой-то степени ваш MD5 + SHA1 + SHA256 бесполезен.
Сложность находки коллизии в MD5 + SHA1 + SHA256 почти не отличить от сложности SHA256.
Этот каскад интересен только если (очень неожиданно) взломают SHA256 и снизят сложность находки коллизии до менее чем 2^79. В таком случае, сложность SHA1 в 2^80 позволит сидеть спокойно.
Дело в том что такие «неожиданные взломы» вряд ли будут. Математики находят теоретическую брешь за долго до того как её начинают эксплуатировать на практике.
В SHA1 уже лет 10 известно что есть проблема, но только сейчас нашли коллизию.
Стоит ли «MD5 + SHA1 + SHA256 » того что ваш сервер будет тратить в 2.5 больше времени на расчет? Вам решать. Я лично для себя решил… что нет.
Эта главная (известная мне) причина почему 2 «итеративные» хэш функции не лучше самой стойкой из 2-х.
И почему на sha3 это правило не действует.
Кто его знает какие еще векторы атаки есть… о которых мне не известно но для криптографов очевидны.
да, вы правы. Это лучше чем каждый по отдельности.
На много ли? скорее всего нет. Почитайте документ который я упомянул: «Multicollisions in iterated hash functions. Application to cascaded constructions»
Если коротко. Самая простая атака будет примерно следующей:
Генерируются 2 документа с одинаковым sha1: 2^50… а вот md5 у них будет разный.
После этого, добавляем (одинаковый) мусор в конец этих 2-х документов (почитайте про «Length extension attack»). Скорее всего, этот мусор будет незаметным в бинарном документе. Получаем другие 2 документа с одинаковым sha1, но с разным md5.
Повторяем 2^64 (md5) раз с разным мусором. С большой вероятностью, найдем 2 документа с одинаковым md5 И sha1.
В конце концов, нашли хэш за 2^64 + 2^50 = 2^64.
И это «тупой перебор». В реальность же дело (скорее всего) хуже.
Как я уже говорил, этот трюк не пройдет с sha3, но у него свой проблемы.
Если хэш важен, используйте sha2 и будьте готовы заменить когда взломают. Не надо надеяться что 2 слабых хэша спасут из-за того что их 2.
Плюс к этому, есть вероятность что sha1+md5 будет медленнее чем один хороший хэш. Зачем тогда мучатся?
Мы говорим об одинаковых вещах по разному.
— Рассчитать оба хэша; конкатенировать их; а потом сравнить.
— Рассчитать оба хэша; и сравнить отдельно.
Очень часто в криптографии интуитивные выводы не верны.
И это один из таких случаев.
вероятность нахождения коллизии для идеального 160 -битного хэша: 2^-80
вероятность нахождения коллизии для идеального 128 -битного хэша: 2^-64
Вы правы, были бы эти хэши идеальными, вероятность коллизии в конкатенации была бы 2^(-80-64) = 2 ^ (-144).
Но!!! если рассчитать хотя-бы один из таких хэшей по итеративному принципу, вероятность коллизии становиться «чуть менее» 2^-80.
В реальности: и MD5, и SHA1, и SHA2… итеративные хэши; а вот SHA3 нет.
Так вот,
в SHA1 нашли возможность повысить вероятность до 2^-50
в MD5 и того хуже… 2^-40
Вероятность найти коллизию в SHA1 + MD5 где-то между 2^-50 (SHA1) и 2^-80+epsilon (теоретический максимум); но никак не 2^(-50-40) = 2^(-90)
Оказывается что, теоретически, конкатенация 2-х хэшей не лучше чем самый слабый из 2-х.
В этом конкретном случае, ша1 + мд5 будет (скорее всего) лучше чем взломанный ша1 (2^50 colision resistence); и лучше чем взломанный мд5 (2^40).
Но, при этом, не устойчивее к генерации коллизий чем качественны, не взломанный, 160-битный хэш, каким считался ша1 (2^80)
Для большей информации, искать «Multicollisions in iterated hash functions. Application to cascaded constructions»
Не знал что атрибуты могут помочь. Спасибо за идею.
А вот selinux далеко не у всех задействован. Плюс к этому, правильная его «готовка»… это уже высший пилотаж который мне не доступен.
Сделать restorecon на файл или «открыть» лишний порт… ok… но не более.
Для информации, ocserv(сервер)+openconnect(клиент) можно настроить практически так-же быстро.
1) Установка сервера и клиента
2) сгенерить серверный ключ и сертификат: одна команда openssl
(а лучше скормить ему готовый сертификат от letsencrypt )
3) Убрать комент на паре линий в настройке сервера (активировать PAM аутентификацию + дать путь на server-cert/key)
4) использовать клиент: openconnect remote_server
5) профит :)
Но решение автора тоже интересна. Именно тем что не надо быть админом на сервере. Спасибо за информацию.
Вроде и с сетями на «ты»… и с виртуализацией… и программировать вроде как получается. Но никак не понимал как эти абстрактные понятие (SDN/NFV) реализуются в реальном, приземленном, мире.
В один день решился, и попробовал все это дело в действии. Надеюсь что я не один такой и кому-то будет интересно читать далее: для сисадминов кто хорошо знаком с (старыми) сетевыми технологиями, но не в теме SDN+NFV. Смотрел я на openflow с SDN контроллером ONOS. А также на OPNFV.
Начнем с SDN.
1) упрощаем маршрутизаторы до безобразия. Они становятся совсем «тупыми». Единственное что они понимают, это команды типа: «все пакеты с dst ip 10.0.0.1 которые вошли через порт eth0, отправить в порт eth1 попутно изменив 'dst mac' на аа: аа: аа: аа: аа: аа». На этих же маршрутизаторах крутиться маленькая программа которая подключается по TCP к контролеру. Контроллер по этому соединению отправляет команды-правила на добавления/удаления/изменения. Получив новые правила, они «скомпилированны» в ASIC(Application-specific integrated circuit) и далее весь процессинг делаеться на уровне hardware.
Например, когда новый пакет получен, маршрутизатор ищет правило которое подходит в списке правил. Если находит, правило исполняется. Если нет, пакет можно отправить контролеру по TCP соединению. Он проанализирует пакет и (возможно) отправит новое правило на добавление.
2) контроллер это просто громадная программа. Например ONOS/Opendaylight написаны на ява. Его задача, воссоздать граф сети в памяти. Наверное многие уже писали алгоритмы для графов в универе. Вот и контроллер крутит всякие алгоритмы чтоб найти кратчайший/лучший путь в сеть. А потом поочередно добавит нужные правила во все маршрутизаторы по пути. Никакой магии :) Вся красота в том что можно добавить какие угодно алгоритмы самому и не надо ждать что CISCO добавит их в IOS.
Маршрутизаторы также собирают всякую статистику о сети. Например, о своих соседях-маршрутизаторах (используя протокол LLDP). А также, об загруженности соединений. Эти данные они отправляют контроллеру по тому-же TCP соединению. Именно эта информация позволяет воссоздать сеть в память контролера и понять что «интерфейс eth0 у switch2 загружен, надо бы какой-то трафик перевести в обход».
В случае NFV, все вроде еще проще:
Вместо того чтоб крутить DHCP/ DNS/ ..../Firewall/..../[new network function] в роутерах, используем магию (в смысле, виртуальную машину/контейнер): на одной запускаем DHCP сервер, на второй BIND, на третей настроим iptables… и так далее. А можно еще купить магическую программу от [крутой организации] и поставить в 4-ую вм. После этого, добавим по правилу через СДН чтоб трафик распределялся по правильным вм.
Как это сделать? В этом то и вся проблема, а SDN и NFV пока что взлетают, взлетают, да не взлетят. Плохо это? хорошо?: не мне решать.
Например, OPNFV это ОГРОМНЫЙ монстр. Первое что надо сделать для его установки, это поднять Openstack кластер. Потом, в этом кластере поднимется пара виртуальных машин в которые устанавливается SDN контроллер с «high availability», blackjackom и шл…
Напомним, SDN контроллер это еще один монстр на пару сотен тысяч линий кода (если не миллионов).
На данный момент я ужасно боюсь что «это» взлетит и мне придется администрировать его, честно боюсь
Я ведь только-только привык к DevOps, а тут DevOps в 5-ой степени
Странно что об ocserv так мало говорят.
По моему мнению он на много лучше OpenVPN по всем параметрам (абсолютно по всем).
Например:
Стандартный TLS: считаю что это хорошо, хоть и не все согласятся. Зато пробивается через великий Китайский… :)
Из коробки умеет параллельно соединяется по TLS+DTLS и предпочитает UDP когда он работает.
У каждого клиента свой TUN/TAP интерфейс на который можно повесить все правила маршрутизации и firewall которые нужно. (думаю многие и не знают что в опенвпн есть встроенный самописный велосипедный «firewall» :) )
У каждого клиента собственный процесс, суммарная скорость не ограничивается одним потоком.
Нормальная поддержка многих видов авторизации… из коробки: прощайте плагины которые работают через раз. Кто пытался прикрутить радиус к опенвпн: поймут. Можно быстро, за 1 минуту поднять сервер с авторизацией по логин/пасс из файла; или строить каскад из сертификатов и радиуса… (это уже не за минуту :) ).
При этом есть клиенты для виртуально любой платформы. Для многих open source, для остальных от Cisco (за ответом «а разрешено ли? » надо идти к юристам, не могу ответить)
Вы частично правы: вычислительные ресурсы в любом случае надо откуда-то взять.
Но все дело в мутуализации, ведь «простаивающий сервер» = «ресурсы на ветер».
На примере хранения данных:
есть 1000 рабочих станций. Можно поставить 2тб жесткий диск в каждую станцию для хранения документов.
А документы то важные ..., значит используем рейд 1. Как результат, нужны 2*2тб. Из этих 1тб, некоторые пользователи будут использовать от силы 100гб. А другим будет мало. При 1000 станциях, последнее с чем вы хотите иметь дело, это машины с «не стандартной конфигурацией». Т.е. те которым вы поставили 4тб хдд по запросу :).
Альтернатива: используем сетевое хранилище.
Вместо 1000 * 2* 2Тб, можно обойтись, скажем, суммарными 500тб. Там вам будет и сохранность данных… и дедубликация. Об проблемах этого решения я не говорю… они очевидны. С другой стороны, снижение стоимости и потребляемой энергии на лицо.
В случае с автомобилем: двигатель внутреннего сгорания выбрасывает углекислый газ. А вот электродвигателю плевать как электричество сделано. Вероятно эти машины сегодня и хуже чем обычные (производство/реутилизация аккумуляторов грязное дело) + энергия часто выработана в «экологически грязных» термоэлектростанциях. Но,
1) кто знает как мы эту энергию будем добывать через 50 лет?
2) даже сегодня… на термоэлектростанциях можно на законодательном уровне заставить использовать фильтры… ведь станций мало и проверить их легко. Заставить всех граждан менять фильтры вовремя труднее ;)
В IBM же анонсировали компьютер с 50 связанными кубитами. Поправьте если не прав.
А что мешает поставить приёмник за 10км от кремля и регенерировать (в идентичности) этот сигнал возле кремля.
В таком случае военный приёмник будет думать что он в 10 км от кремля. Возможна ли такая «атака»?..
2 хэша, безусловно, не хуже чем один.
Если у вас (например) SHA1 и SHA256… и, вдруг, взломают SHA1… второй хэш позволят сидеть спокойно.
НО! при этом, речь совсем о другом. Предположим что хэши не взломаны вообще. В таком случае, сложность находки коллизии в
— MD5: 2^64
— SHA1: 2^80
— SHA256: 2^128
— MD5 + SHA1: 2^80… а не 2^144! (как большинство думает)
— MD5 + SHA256: 2^128… а не 2^208
— MD5 + SHA1 + SHA256: 2^128… а не 2^272
Так что да, в какой-то степени ваш MD5 + SHA1 + SHA256 бесполезен.
Сложность находки коллизии в MD5 + SHA1 + SHA256 почти не отличить от сложности SHA256.
Этот каскад интересен только если (очень неожиданно) взломают SHA256 и снизят сложность находки коллизии до менее чем 2^79. В таком случае, сложность SHA1 в 2^80 позволит сидеть спокойно.
Дело в том что такие «неожиданные взломы» вряд ли будут. Математики находят теоретическую брешь за долго до того как её начинают эксплуатировать на практике.
В SHA1 уже лет 10 известно что есть проблема, но только сейчас нашли коллизию.
Стоит ли «MD5 + SHA1 + SHA256 » того что ваш сервер будет тратить в 2.5 больше времени на расчет? Вам решать. Я лично для себя решил… что нет.
Почитайте предложенную мною статью: там правильный метод.
Вот и я положился на интуицию в криптографии… и она меня подвела.
И почему на sha3 это правило не действует.
Кто его знает какие еще векторы атаки есть… о которых мне не известно но для криптографов очевидны.
Я погорячился сказав «опять» ))
$ sha1sum shattered-*.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
$ echo «musssor» >> shattered-1.pdf
$ echo «musssor» >> shattered-2.pdf
$ sha1sum shattered-*.pdf
589dec295aaa1fb915e767db80d5b7533b1b7e16 shattered-1.pdf
589dec295aaa1fb915e767db80d5b7533b1b7e16 shattered-2.pdf
На много ли? скорее всего нет. Почитайте документ который я упомянул: «Multicollisions in iterated hash functions. Application to cascaded constructions»
Если коротко. Самая простая атака будет примерно следующей:
Генерируются 2 документа с одинаковым sha1: 2^50… а вот md5 у них будет разный.
После этого, добавляем (одинаковый) мусор в конец этих 2-х документов (почитайте про «Length extension attack»). Скорее всего, этот мусор будет незаметным в бинарном документе. Получаем другие 2 документа с одинаковым sha1, но с разным md5.
Повторяем 2^64 (md5) раз с разным мусором. С большой вероятностью, найдем 2 документа с одинаковым md5 И sha1.
В конце концов, нашли хэш за 2^64 + 2^50 = 2^64.
И это «тупой перебор». В реальность же дело (скорее всего) хуже.
Как я уже говорил, этот трюк не пройдет с sha3, но у него свой проблемы.
Если хэш важен, используйте sha2 и будьте готовы заменить когда взломают. Не надо надеяться что 2 слабых хэша спасут из-за того что их 2.
Плюс к этому, есть вероятность что sha1+md5 будет медленнее чем один хороший хэш. Зачем тогда мучатся?
— Рассчитать оба хэша; конкатенировать их; а потом сравнить.
— Рассчитать оба хэша; и сравнить отдельно.
Очень часто в криптографии интуитивные выводы не верны.
И это один из таких случаев.
вероятность нахождения коллизии для идеального 160 -битного хэша: 2^-80
вероятность нахождения коллизии для идеального 128 -битного хэша: 2^-64
Вы правы, были бы эти хэши идеальными, вероятность коллизии в конкатенации была бы 2^(-80-64) = 2 ^ (-144).
Но!!! если рассчитать хотя-бы один из таких хэшей по итеративному принципу, вероятность коллизии становиться «чуть менее» 2^-80.
В реальности: и MD5, и SHA1, и SHA2… итеративные хэши; а вот SHA3 нет.
Так вот,
в SHA1 нашли возможность повысить вероятность до 2^-50
в MD5 и того хуже… 2^-40
Вероятность найти коллизию в SHA1 + MD5 где-то между 2^-50 (SHA1) и 2^-80+epsilon (теоретический максимум); но никак не 2^(-50-40) = 2^(-90)
Но в моем посте есть ошибка. Должно быть: не лучше чем самый стойкий из 2-х
Оказывается что, теоретически, конкатенация 2-х хэшей не лучше чем самый слабый из 2-х.
В этом конкретном случае, ша1 + мд5 будет (скорее всего) лучше чем взломанный ша1 (2^50 colision resistence); и лучше чем взломанный мд5 (2^40).
Но, при этом, не устойчивее к генерации коллизий чем качественны, не взломанный, 160-битный хэш, каким считался ша1 (2^80)
Для большей информации, искать «Multicollisions in iterated hash functions. Application to cascaded constructions»
А вот selinux далеко не у всех задействован. Плюс к этому, правильная его «готовка»… это уже высший пилотаж который мне не доступен.
Сделать restorecon на файл или «открыть» лишний порт… ok… но не более.
к сожалению, сменить владельца не поможет. Пользователь имеет право запись на папку ~/
$ mv .bashrc .trololo
$ cat .trololo > .bashrc
1) Установка сервера и клиента
2) сгенерить серверный ключ и сертификат: одна команда openssl
(а лучше скормить ему готовый сертификат от letsencrypt )
3) Убрать комент на паре линий в настройке сервера (активировать PAM аутентификацию + дать путь на server-cert/key)
4) использовать клиент: openconnect remote_server
5) профит :)
Но решение автора тоже интересна. Именно тем что не надо быть админом на сервере. Спасибо за информацию.
Вроде и с сетями на «ты»… и с виртуализацией… и программировать вроде как получается. Но никак не понимал как эти абстрактные понятие (SDN/NFV) реализуются в реальном, приземленном, мире.
В один день решился, и попробовал все это дело в действии. Надеюсь что я не один такой и кому-то будет интересно читать далее: для сисадминов кто хорошо знаком с (старыми) сетевыми технологиями, но не в теме SDN+NFV. Смотрел я на openflow с SDN контроллером ONOS. А также на OPNFV.
Начнем с SDN.
1) упрощаем маршрутизаторы до безобразия. Они становятся совсем «тупыми». Единственное что они понимают, это команды типа: «все пакеты с dst ip 10.0.0.1 которые вошли через порт eth0, отправить в порт eth1 попутно изменив 'dst mac' на аа: аа: аа: аа: аа: аа». На этих же маршрутизаторах крутиться маленькая программа которая подключается по TCP к контролеру. Контроллер по этому соединению отправляет команды-правила на добавления/удаления/изменения. Получив новые правила, они «скомпилированны» в ASIC(Application-specific integrated circuit) и далее весь процессинг делаеться на уровне hardware.
Например, когда новый пакет получен, маршрутизатор ищет правило которое подходит в списке правил. Если находит, правило исполняется. Если нет, пакет можно отправить контролеру по TCP соединению. Он проанализирует пакет и (возможно) отправит новое правило на добавление.
2) контроллер это просто громадная программа. Например ONOS/Opendaylight написаны на ява. Его задача, воссоздать граф сети в памяти. Наверное многие уже писали алгоритмы для графов в универе. Вот и контроллер крутит всякие алгоритмы чтоб найти кратчайший/лучший путь в сеть. А потом поочередно добавит нужные правила во все маршрутизаторы по пути. Никакой магии :) Вся красота в том что можно добавить какие угодно алгоритмы самому и не надо ждать что CISCO добавит их в IOS.
Маршрутизаторы также собирают всякую статистику о сети. Например, о своих соседях-маршрутизаторах (используя протокол LLDP). А также, об загруженности соединений. Эти данные они отправляют контроллеру по тому-же TCP соединению. Именно эта информация позволяет воссоздать сеть в память контролера и понять что «интерфейс eth0 у switch2 загружен, надо бы какой-то трафик перевести в обход».
В случае NFV, все вроде еще проще:
Вместо того чтоб крутить DHCP/ DNS/ ..../Firewall/..../[new network function] в роутерах, используем магию (в смысле, виртуальную машину/контейнер): на одной запускаем DHCP сервер, на второй BIND, на третей настроим iptables… и так далее. А можно еще купить магическую программу от [крутой организации] и поставить в 4-ую вм. После этого, добавим по правилу через СДН чтоб трафик распределялся по правильным вм.
Как это сделать? В этом то и вся проблема, а SDN и NFV пока что взлетают, взлетают, да не взлетят. Плохо это? хорошо?: не мне решать.
Например, OPNFV это ОГРОМНЫЙ монстр. Первое что надо сделать для его установки, это поднять Openstack кластер. Потом, в этом кластере поднимется пара виртуальных машин в которые устанавливается SDN контроллер с «high availability», blackjackom и шл…
Напомним, SDN контроллер это еще один монстр на пару сотен тысяч линий кода (если не миллионов).
На данный момент я ужасно боюсь что «это» взлетит и мне придется администрировать его, честно боюсь
Я ведь только-только привык к DevOps, а тут DevOps в 5-ой степени
По моему мнению он на много лучше OpenVPN по всем параметрам (абсолютно по всем).
Например:
Стандартный TLS: считаю что это хорошо, хоть и не все согласятся. Зато пробивается через великий Китайский… :)
Из коробки умеет параллельно соединяется по TLS+DTLS и предпочитает UDP когда он работает.
У каждого клиента свой TUN/TAP интерфейс на который можно повесить все правила маршрутизации и firewall которые нужно. (думаю многие и не знают что в опенвпн есть встроенный самописный велосипедный «firewall» :) )
У каждого клиента собственный процесс, суммарная скорость не ограничивается одним потоком.
Нормальная поддержка многих видов авторизации… из коробки: прощайте плагины которые работают через раз. Кто пытался прикрутить радиус к опенвпн: поймут. Можно быстро, за 1 минуту поднять сервер с авторизацией по логин/пасс из файла; или строить каскад из сертификатов и радиуса… (это уже не за минуту :) ).
При этом есть клиенты для виртуально любой платформы. Для многих open source, для остальных от Cisco (за ответом «а разрешено ли? » надо идти к юристам, не могу ответить)
Но все дело в мутуализации, ведь «простаивающий сервер» = «ресурсы на ветер».
На примере хранения данных:
есть 1000 рабочих станций. Можно поставить 2тб жесткий диск в каждую станцию для хранения документов.
А документы то важные ..., значит используем рейд 1. Как результат, нужны 2*2тб. Из этих 1тб, некоторые пользователи будут использовать от силы 100гб. А другим будет мало. При 1000 станциях, последнее с чем вы хотите иметь дело, это машины с «не стандартной конфигурацией». Т.е. те которым вы поставили 4тб хдд по запросу :).
Альтернатива: используем сетевое хранилище.
Вместо 1000 * 2* 2Тб, можно обойтись, скажем, суммарными 500тб. Там вам будет и сохранность данных… и дедубликация. Об проблемах этого решения я не говорю… они очевидны. С другой стороны, снижение стоимости и потребляемой энергии на лицо.
В случае с автомобилем: двигатель внутреннего сгорания выбрасывает углекислый газ. А вот электродвигателю плевать как электричество сделано. Вероятно эти машины сегодня и хуже чем обычные (производство/реутилизация аккумуляторов грязное дело) + энергия часто выработана в «экологически грязных» термоэлектростанциях. Но,
1) кто знает как мы эту энергию будем добывать через 50 лет?
2) даже сегодня… на термоэлектростанциях можно на законодательном уровне заставить использовать фильтры… ведь станций мало и проверить их легко. Заставить всех граждан менять фильтры вовремя труднее ;)