Почему нигде не используют примитивную шифровку заменой? Неочевидные недостатки?
О каком шифровании я говорю:
1(общий секрет) + 2(информация для восстановления) = 3(данные).
3 И 1 - на клиенте А.
2 - в облаке, или передаётся любым способом.
1 - на клиенте B. (конечно, необходимость общего секрета я включаю в очевидные недостатки)
"1" - не маленький 4096-битный "ключ", а избыточно большой массив данных, скажем, 100Мб.
Таким образом, как мне (наивному?) кажется, можно прекрасно реализовать вполне безопасный чат (предварительно поделившись общим секретом), синхронизацию между разными собственными устройствами и вообще огромное множество кейсов. Почему никто этого не делает? Или что я понимаю не так?
В чём я вижу преимущество, и проч.:
Конечно, есть AES и прочие как бы стойкие алгоритмы, с аппаратным ускорением и всё такое. Но я не понимаю, как вообще любой алгоритм может устоять против атаки mitm (men-in-the-middle), ведь и ключ, и данные так или иначе я передаю через провайдера, СОРМ, и ещё неизвестно что. Да и во всех этих алгоритмах наверняка есть какие-то закладки, вероятно, известные не только "кому положено". А как взломать такой алгоритм (конечно, если наивно предположить, что с обоих сторон нет бэкдоров) - не могу представить.
Для правильного вопроса надо знать половину ответа
Поздравляю! Вы открыли для себя шифроблокнот.
Очевидный недостаток - с точки зрения безопасности в этом шифре (Вернама) ключ нельзя использовать повторно, а значит для переписки придётся иметь копию ключа каждого, с кем переписываешься, да ещё и разработать способ секретного обновления ключа когда он закончится.
Да, но это мне и так очевидно, и я не считаю это проблемой. Например, моя переписка с девушкой в аське за много лет занимает 20Мб. Переданные фотки - допустим, гиг. Мне не жалко 10Гб места ни на компе, ни на мобильнике, ни на планшете пож это. Это же на всю жизнь хватит)
Руслан Федосеев: да, как и в случае со взломом любого другого алгоритма, разве не так? А переписку и фото вместе с использованной частью ключа никто не мешает сразу удалять.
Василий Пупкин: Делать такое шифрования для переписки только двух людей смысла нету. А если Вы переписываетесь с парой десятков человек? 200 гиг тоже не жалко?
Юридических проблем никаких. Берите любой подходящий мессенджер, пишите свой плагин и шифруйте сколько угодно.
Rsa97: я привёл настолько утрированный пример специально. На самом деле гигов 10 мне хватит исключительно на переписку, с тысячами человек, на всю жизнь. Прикиньте сами: это 10.737.418.240 байтов, или в юникоде - 2.684.354.560 символов. Делим на всю жизнь, 100 лет это 35.600 дней. Итого в день мы можем написать/принять 75.403 символа, другими словами это примерно 30 страниц ворда. Я не пишу столько в день. И это только в среднем.
Rsa97: То есть, это дейстительно так надёжно, как я думаю? И настолько просто?
Если предположить, что закрыть потенциальную дыру в методе генерации рандома относительно просто...
Rsa97: В реальности я снова преувеличивал, и мне не нужен такой запас на 100 лет, так что 1 гига будет достаточно вполне, а оставшиеся 9 - на файлы. Да, придётся с каждым обмениваться ключами лично. Хранение... конечно, наивно полагать что linux/android безопасны для хранения ключей, но пока я не вижу альтернатив. А вы чему доверяете больше?
Василий Пупкин: А представьте, что Вы захотели написать что-нибудь абоненту в Австралии, а ключ, как на грех, закончился. Сами поедете за файлом или респондента к себе пригласите?
А так, в общем случае, достаточно Диффи-Хеллмана + RSA. Да, уязвимо к MiTTM, но в большинстве случаев вполне достаточно. Для более строгих вещей есть ГОСТ (эллиптика) и предварительный обмен удостоверяющими сертификатами.
Rsa97:
Дело в том, что (я, конечно, могу ошибаться, но моя логика и интуиция приводит к таким выводам) все популярные алгоритмы, системы, где потенциально передаётся какая-то информация, представляющая для кого-либо значительный интерес, скорее всего, содержат в себе заложенную возможность лёгкого доступа для этих самых заинтересованных лиц.
И, понятно, что при особом интересе они найдут и другие простые методы, но это обойдётся им куда дороже и никогда не станет массовым. Так что да, наведаюсь к другу в Австралии, и отличный повод будет)
Василий Пупкин: Сами алгоритмы ничего не содержат. Именно их открытость позволяет любому желающему проверить криптографическую устойчивость. Конкретная реализация алгоритма может содержать бэкдор, но тогда никто не мешает встроить такой бэкдор и в мессенджер и отсылать уже расшифрованное сообщение. Опять же в Open Sorce продуктах и код программы открыт, проверяйте, ищите ошибки, уязвимости, бэкдоры.
Rsa97: Да, не содержат, однако, имеют определённую криптографическую стойкость, и, скорее всего, не превышающую каких-то допустимых пределов - то есть, пусть обычный ПК не сможет взломать ключ и за время существования вселенной, зато машина с некой определённой аппаратной архитектурой эту задачу раскусит в приемлемое минимальное время. Как происходит, например, с расшифровкой сигналов мобильных на лету.
Да, с реализациями всё очень печально. Кажется, что с текущим стеком технологий это сложнее, чем создать собственную базовую аппаратную архитектуру...
Василий Пупкин: Сотовая связь - как раз пример закрытых алгоритмов. Как только их отреверсили так сразу и обнаружилась их слабость. В результате использования специальных алгоритмов их вскрывают A5/2 вскрывается за секунды, A5/1 требует двухминутного разговора.
Открытый же RSA до сих пор не могут вскрыть за приемлемое время, при длине ключа в 1024 бита его взлом требует 1011 MIPS-лет. 224-битный ГОСТ требует порядка 1020 MIPS-лет. На современных суперкомпьютерах с производительностью 106 получим, соответственно, 105 и 1014 лет.
Rsa97: С RSA я вижу несколько проблем:
Во-первых, я не математик, не криптоаналитик и лично для меня это чёрная коробка. Может быть, я и мог бы написать свою реализацию, но у меня нет такого количества времени. А пока я не понимаю, что использую - как я могу полагаться на это?
Во-вторых, ваша информация устарела habrahabr.ru/post/120257 , да и сам подход - каждые 2-3 года просто увеличивать кол-во бит - кажется мне каким-то странным...
В-третьих, сейчас вы можете посоветовать использовать, например, 4096-битый ключ, но, даже если отмести в сторону первый пункт, написать свою проверенную реализацию, - тогда я уже столкнусь с серьёзными проблемами в скорости.
В-четвёртых, решая проблемы скорости единственным доступным способом - использованием аппаратного ускорения - я снова сталкиваюсь с чёрной коробкой, которую уже точно не могу проверить или воссоздать за какое-то адекватное время.
И, наконец, в пятых:
Cмешно, сам только что впервые зашёл на эту вики) https://ru.wikipedia.org/wiki/%D0%A8%D0%B8%D1%84%D...
"Шифр Вернама является единственной системой шифрования, для которой доказана абсолютная криптографическая стойкость[4]. При этом он является одной из простейших криптосистем[5]." Вот оно как, оказывается.
Василий Пупкин: Это известные факты. Собственно поэтому сейчас и идёт переход на эллиптическое шифрование, там при меньшей длине ключа и большей скорости шифрования криптостойкость выше. Шифр Вернама - действительно самый надёжный, но требует обязательной неповторяемости и, соответственно, непригоден в большинстве случаев.
Ну а "не понимаю, что использую" - это вся идей нынешней цивилизации. Мало кто понимает до конца как работают те или иные устройства, но при этом вполне успешно их использует. Например если Вы купили автомобиль, то вряд ли Вы будете лично перепроверять всю его конструкцию. А вдруг из-за конструктивного дефекта у него при левом повороте с одновременным торможением откручивается колесо?
Rsa97: Ну тут согласен, панацеей его никак не назвать. Но для личного пользования - отличная штука ведь, вы так не считаете?
Вечная проблема. И в то же время, каждый отвечает за себя и не обязан слепо идти за стадом. Вам, конечно, покажется это странным, но да, когда я знаю в общих чертах всю конструкцию своего автомобиля, знаю, как работает его электронная начинка, знаю потенциальные слабые места. Пусть не досконально, но до определённого компромисса с безопасностью и вложенным временем. И пусть я в этом переусердствую, меня считают странным, но я хотя бы даю окружающим повод задуматься, что, возможно, адекватность их компромисса основана на ложных данных.
Изначально стороны должны обменяться формулой-ключом заранее.
1. Проще всего генерировать ключ "бесконечного" блокнота на основе даты отправленного сообщения по формуле.
2. Формула должна генерировать КАЖДЫЙ РАЗ! уникальную последовательность "ключа" на одно и то же сообщение (через случайную последовательность части информации в формуле).
3. "Ключ" также может использоваться частично, позволяя методом "подбора" из нескольких возможных комбинаций, восстановить его истинное значение на другом конце. (частичное кодирование с неполным "ключом")
PS: По-умолчанию, для формул, можно использовать даты подтверждения авторизации (чтобы не "перегружать" мозг пользователей).
1. ИМХО, ключ должен генерироваться абсолютно рандомно, а не на основе вообще чего-либо, что как-то возможно связать с известными устройствами, данными и уж тем более - датой сообщения и формулами...
2. Всё это - псевдослучайно до вычислимой степени. Зачем?
3. Можно, но снова - зачем усложнять, если нет никакого выигрыша?
Пользователю нужно только знать, что у него лимит на данные с этим пользователем - 1гб, или столько, сколько он ему передал ключа. Больше никаких запариваний мозга, а алгоритм простой и понятный.
Василий Пупкин: Без формулы Вы не сможете восстановить первоначальный ключ, даже если он был создан на основе даты или времени. А там еще и рандомайзер внутри с частичным кодированием...
xmoonlight: Но это же замечательно? Мне и нужно, чтобы его невозможно было восстановить.
Не понял вас, зачем хорошему рандомайзеру кодирование? Я о таком не говорил.
Василий Пупкин: в формуле есть дата/время, randomize и шифрация происходит не полным, а частичным ключом, вторая часть которого, подбирается при расшифровке.
НО криптостойкость - ПОЛНОСТЬЮ! зависит от используемого выражения внутри формулы генерации ключей!
xmoonlight: вы можете наглядно пояснить (в условных битах, байтах, цифрах, примерах псевдо или реального кода)? Ответом ниже - описание основы моего алгоритма.
Там же смотрите "формулу" генерацию ключей.
Я понимаю также, что энтропия может распределяться по ключу неравномерно (например, внезапно матрица сгорела и пошли 000... или 111..). Пока в качестве борьбы с этим я рассматриваю расчёт среднего отношения 0/1 за определённое время или объём данных. То есть, если, к примеру, данные какое-то время статичны, % энтропии падает от средних 47-53% до заданного порога (скажем, 40%), то генератор переходит в режим ожидания, продолжая наблюдать за данными. Если энтропия восстанавливается, пишет дальше, в противном случае через какое-то время тестирует систему и пишет ошибку.
Василий Пупкин: как я понял, Вы описали алгоритм предотвращения генерации "слабых" ключей.
Про формулу:
SALT="jhgsdjfhs8732642jh4g2j4g2j2h3gj2g5j252"; // по-умолчанию, на основе hand-shake при добавлении в контакт-лист.
R=mt_rand(50,150);
KEY=substr(hash_function(SALT.timestamp.R.SALT),R);
Да, его самого. Я думаю, главное чтобы размер таких областей в ключе не перекрывал размер каждой значащей сущности в данных, а то мы передадим эту сущность без шифрования вовсе или в инверсии. Если вы глубже понимаете эту тему, поделитесь, какие ещё параметры стоит учитывать и каковы оптимальные соотношения, было бы интересно.
То есть это вы предлагаете запихать в заголовок к каждому сообщению, правильно понимаю? А соль - на основе сообщения? Если так, то... возможно, но вот тут уже крайне сложно понять, будет ли итоговая энтропия больше или меньше от таких "обёртываний"... Мне кажется, хотя и возможно, что энтропия будет действительно больше, но шифрование этой формулой наверняка наложит свой характерный отпечаток (достаточно взглянуть на большинство шифровок, чтобы примерно распознать, каким из известных методов это было зашифровано), что будет ярко выделять значимые сообщения на фоне цифрового "шума".
Василий Пупкин: Все зависит от формулы: я могу сдвинуть на любой интервал сгенерированой последовательности.
Передаётся в пакете: TIMESTAMP, XOR-MESSAGE и больше НИЧЕГО!
Все остальное - хранится на конечных узлах (клиентах).
SALT (соль) - я же написал: на основе hand-shake при добавлении в контакт-лист: один запросил - второй авторизовал и по любой информации, которую могут получить эти 2 клиента СТРОГО ПОСЛЕ!!! авторизации со стороны сервера - генерится соль, которую они в дальнейшем могут поменять вручную (через поле ввода).
