Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
Ассиметричному шифрованию ассиметричная производительность
 
Применение ассиметричного шифрования, которое я хочу обсудить может показаться весьма специфическим. Сразу хочу сказать что в криптографии я соображаю слабо, поэтому мне нужно если не разъяснение, то хотя-бы пинок в нужную сторону (если RTFM, то fucking manual должен быть слегка конкретнее толстого тома по криптографии).
Итак. Насколько я успел понять, то, в RSA, скорость шифрования равна скорости расшифровывания (при равных вычислительных возможностях). Так вот)), мне нужен такой шифр, который зашифровать гораздо труднее чем расшифровать. И даже более того, должно быть 3 ключа: ключ быстрого шифрования, ключ медленного шифрования и ключ быстрого расшифровывания. Быстрый и медленный ключи должны приводить к одному и тому-же результату, но скорость скорость получения этого результата должна расходитья, как минимум, на порядок. Быстрый ключ шифрования не должен вычисляться из остальных 2х в обозримый промежуток времени. Медленный ключ должен генерироваться как минимум на порядок быстрее чем шифрование сообщения им же.
Если я в чём-то попрал фундаментальные принципы криптографии, прошу понять и простить)
Сей трюк требуется совсем не для защиты информации, это лиш некий proof of work.
 
Немного разобрался. Несколько ключей шифрования в RSA сделать можно.

Вот пример с http://www.e-nigma.ru/stat/rsa/ :

Выберем p=3 and q=11.
Определим n= 3*11=33.
Hайдем (p-1)*(q-1)=20. Следовательно, d будет равно, например, 3: (d=3).
Выберем число е по следующей формуле: (e*3) mod 20=1. Значит е будет равно, например, 7: (e=7).
Представим шифруемое сообщение как последовательность чисел в диапозоне от 0 до 32 (незабывайте, что кончается на n-1). Буква А =1, В=2, С=3.

Теперь зашифруем сообщение, используя открытый ключ {7,33}
C1 = (3^7) mod 33 = 2187 mod 33 = 9;
C2 = (1^7) mod 33 = 1 mod 33 = 1;
C3 = (2^7) mod 33 = 128 mod 33 = 29;

Теперь расшифруем данные, используя закрытый ключ {3,33}.
M1=(9^3) mod 33 =729 mod 33 = 3(С);
M2=(1^3) mod 33 =1 mod 33 = 1(А);
M3=(29^3) mod 33 = 24389 mod 33 = 2(В);

Теперь на основе этого примера можно создать ещё один ключ шифрования:

Выберем e = 27, (27*3) mod 20 = 1;

Проверка:
C1 = (3^27) mod 33 = 9;

Таким образом имеем 2 ключа шифрования: e_fast = {7,33}, e_slow = {27,33};
И один ключ для дешифрации: d = {3,33}

e_slow и d в моей системе будут открытыми.
e_fast будет использоваться только один раз при первом получении шифрованного сообщения.

Меня волнует вопрос: нельзя ли по по e_slow и d быстро подобрать e_fast?
 
Вопрос снимается. По 2м известным ключам элементарно вычисляется 3й)
 
Я думаю можно поудмать не на счет алгоритмов, а на счет протоколов шифрования..
например каждый раз информация шифруется новым ключем симметричного алгоритма, а сам ключ, и его обрезанная на N бит версия шифруется двумя разными публичными ключами.
Первый ключ секретный ключ, восстанавливающий симметричный ключ полностью, назовем быстрым ключем
А второй, котоыре востановит не полностью - медленным. Так как понадобится еще перебор осташихся битов симметричного ключа, что займет время.
Для организации перебора вместе с сообщением можно посылать какую нить ее подпись (например sha256)
Таким образом у нас имеется
Секретный ключ, состоящий фактически из дух публичных ключей двух ключевых пар
быстрый секретный ключ
медленный секретный ключ
и крипто-текст, состоящий из зашифрованного симметричным алгоритмом исходного сообщения, зашифрвоанного первым публичным ключем, симметричного ключа, зашифрованного вторым секретным ключем обрезанной версии симметричного ключа, и подписи исходного сообщения...
 
Вместо подписи самого сообщения думаю целесообразно иметь подпись симметричного ключа... тогда время на подбор не будет зависеть от длины сообщения
 
Наверное надо было конкретнее рассказать о предпогаемом применении. Назначение медленного ключа в подтверждении наличия куска файла на жёстком диске удалённого узла. Т.е. если куска нет, то он будет вынужден "попросить" кого-то, у кого есть кусок, посчитать CRC. Это займёт время. По этому времени и будет обнаружен обман.
Но этот способ имеет как минимум 2е сложности.1я это сабж темы. 2я состоит в том, что производительность железа у всех разная.
Шифрование ключа ключом проблемы не решит, т.к. любой ключ занимает гораздо меньше места чем сами данные и можно будет выкинуть данные, а хранить заблаговременно восстановленый ключ.
Ко 2ой проблеме я вообще не знаю с какого конца подступиться.
К счастью я нашёл решение проблемы. Оно лежит не в плоскости криптографии.
Страницы: 1
Читают тему