информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Я не понял про 108 бит. Это что уязвимость MD5? Тогда можно... 11.01.07 11:37  Число просмотров: 4787
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > > Чтобы дешифровать достаточно известных первых 16
> байт
> > > текста и получения прообраза 108 битов для MD5 на
> 108
> > > битах(Пароль нам не нужен, достаточны найти хэш
> от
> > него).
> > > Увеличение длины блоков даст прирост в стойкости,
> но
> > тогда
> > > ты еще больше отстанешь по скорости.
> Ты поспорь с тем, что сказано выше, про твои хэши я все
> понял, ты внимательно текст прочитай.
Я не понял про 108 бит. Это что уязвимость MD5? Тогда можно использовать SHA-1. Алгоритм от этого не меняется. Знание первых 16 байт ничего не дает. т.е. не помогает при расшифровке следующего блока данных. Можно подробнее про 108 бит, если можно, то ссылку.
Пример:
key=значение;
delta=первоначальное значение;
EncData[0]=Data[0] ^ Hash(key+delta); // первый блок
delta=Data[0];
EncData[1]=Data[1] ^ Hash(key+delta); // второй блок
delta=Data[1];
Т.е. даже зная EncData[0], Data[0], delta, Hash(key+delta) и EncData[1] как найти Data[1] или Hash(key+delta) или key ?
Математической формулы нет. Если только уязвимость конкретной хеш-функции.

> А ты спроси у кого-нибудь, кто дизассемблировал наваянное
> на vc++ c шаблонами и прочим ооп. Оптимизация компилятора
> все это неплохо убивает.
Я прекрасно знаю, как раскрываются шаблоны. Вот простой пример:
vector<int> a;
a.resize(16);
for(int i=0; i<a.size(); i++) a[i]=~a[i];
В этом примере в выражении a[i]=~a[i] при каждой итерации происходит проверка значения индекса i на допустимость диапазона (реализовано в самом шаблоне vector), хотя она здесь явно не нужна. И в шаблонах таких проверок очень много. С одной стороны, это копейки, но когда это все находится в цикле на несколько милльонов итераций - это тоже сказывается на производительности. Плюс в программе есть места простого копирования блоков памяти, без которого тоже можно обойтись. На мой взгляд имеет смысл оптимизировать, пока загрузка процессора станет ниже скорости чтения данных с винчестера. Вот тогда будет действительно хорошая скорость.
<theory>
Криптоанализ 18.11.06 16:14  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Подскажите, пожалуйста, как можно проверить криптостойкость алгоритма? ;)
Родилась идея одного алгоритма и хочется проверить его криптостойкость.
Я не особо силен в криптографии, только базовые знания. Может подскажет кто ссылки на толковые статьи по этой теме? Какие основные недостатки существующих алгоритмов шифрования с закрытым ключем?
Вынужден Вас огорчить. Если Вы ничего не понимаете в... 18.11.06 19:28  
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 18.11.06 19:37  Количество правок: 1
<"чистая" ссылка>
Вынужден Вас огорчить. Если Вы ничего не понимаете в криптоанализе, то нет никакой универсальной методики что-либо проверить, и никто не будет этим заниматься. Равно как никто не будет просчитывать сопроматом чертеж самолета сделанный трехлетним ребенком.

Любое движение в сторону создания такой методики или сбора готовых - фактически и будет погружением в криптоанализ. Отчасти можно проверить алгоритм на "вшивость" статистическими методами. Но провал таких тестов означает, что и тестировать собственно нечего. Положительный результат ровно ни о чем ни говорит.

Отчасти оценить ваш алгоритм можно представив его в виде цепочки S и P блоков (и проанализировав их), либо в виде сети Файстеля (и оценив функцию генерации модифицирующего кода). Но это достаточно банально. Реально без опыта и понимания вы сможете оценить только наличие жутких дыр (т.е. отсутствие шифрования), но не криптостойкости в полном смысле.

Как уже много раз здесь говорилось можно начать с книги Брюса Шнайера "Прикладная Криптография" (Bruce Schneier "Applied Cryptography").
Я, собственно, и прошу ссылки на литературу (по возможности... 18.11.06 23:52  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Я, собственно, и прошу ссылки на литературу (по возможности онлайн ;)
Да и скорее это и не алгоритм, а больше на методику похоже, основанную на необратимости хеш функций. А конкретная реализация может сильно отличаться от выбранной хеш функции и некоторых других факторов.
О, к стати, пожоже можно что-то подобное сбацать. Например... 21.11.06 13:24  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Да и скорее это и не алгоритм, а больше на методику похоже,
> основанную на необратимости хеш функций. А конкретная
> реализация может сильно отличаться от выбранной хеш функции
> и некоторых других факторов.

О, к стати, пожоже можно что-то подобное сбацать. Например каждый последующий блок гаммируется хешем сцепки предыдущего с ключем. Для первого возьмем последний или второй, например, еще незашифрованый. Если блок один, то гаммируем просто хешем ключа.
Здесь гамму не найти без ключа (хотя есть и "предыдущий" блок).
"Вычисление" ключа упирается в необратимость хешфункции.
Короче стойкость методики (при отсутствии явных дыр) сводится к стойкости используемого хеширования.
Причем мне здесь один прикол понравился. Заключается он в коллизиях. Допустим подобрали якобы ключик по одному из блоков довольно быстро, а он к другому не подходит!
В общем, если увлечетесь теорией, следуйте совету - читайте книжку. Если нет - не замарачивайте голову и спите спокойно.
Именно так я и реализовал. т.е. к хешу добавляется... 21.11.06 13:53  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Именно так я и реализовал. т.е. к хешу добавляется предыдуший открытий фрагмент и заново хешируется. Реализацию сделал на md5. Правда скорость низкая... Сейчас ищу другие варианты хеш функций, более оптимальных по скорости.
Не так. "К хешу" - это к результату хешфункции. Как... 21.11.06 16:28  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Именно так я и реализовал. т.е. к хешу добавляется
> предыдуший открытий фрагмент и заново хешируется.

Не так. "К хешу" - это к результату хешфункции. Как добавляется? Почему "предыдущий" - "открытый"?

> Реализацию сделал на md5. Правда скорость низкая... Сейчас
> ищу другие варианты хеш функций, более оптимальных по
> скорости.

В принципе скорость хеширования не велика, она теоретически должна быть равна шифрованию. Я уж писал как-то здесь на форуме о необратимости хеширования и как пример приводил шифрования открытого текста, используя в качестве ключа этот же открытый текст (или его часть, или его модификацию).
В принципе можно реализовывать хеширование и более быстрыми методами, учитывая специфику и отличительную особенность от щифрования - здесь расшифровывать не требуется и не надо об этом заботится при разработке алгоритма. Мало того - это противопоказано.
Скорость подобного метода будет в любом случае меньше, так как добавляются дополнительные операции и обрабатываются данные бОльшего в сумме объема.
Поскольку шифрование - процесс медленный, имеет смысл разрабатывать более быстрые алгоритмы и это реально. Поскольку в шифровании не требуется обеспечить необратимость преобразований, можно шифрование реализовать достаточно высокоскоростное за счет упрощения вычислений.
Будем ждать мнения авторитетов.
0)Есть некий набор подходов к изучению различных параметров... 10.12.06 22:23  
Автор: MadBinom Статус: Незарегистрированный пользователь
<"чистая" ссылка>
0)Есть некий набор подходов к изучению различных параметров шифров и функций, учат такому в АФСБ ИКСИ. Возможно, скоро криптографов будут выпускать в МГУ...
1)Просто сразу огорчу - такая цепочка даст как максимум "НЕУХУДШЕНИЕ" почти всех полезных показателей используемых в цепочке хэш-функций. И даже такой "как максимум" обойдется НЕОДХОДИМЫМ примением в цепочке некачественных функций.
2)Термин "Изучение криптоскойтости" подходит к алгоритмам шифрования, а не хэширования.
3)А смысл в изобретении велосипеда? Есть стойкие алгоритмы шифрования, есть хэш функции с хорошими показателями - так что не надо ничего другого с более плохими показателями.
Почему необходимо применение некачественных функций???... 11.12.06 11:28  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> 1)Просто сразу огорчу - такая цепочка даст как максимум
> "НЕУХУДШЕНИЕ" почти всех полезных показателей используемых
> в цепочке хэш-функций. И даже такой "как максимум"
> обойдется НЕОДХОДИМЫМ примением в цепочке некачественных
> функций.
Почему необходимо применение некачественных функций??? Например MD5 к каким относится?

> 2)Термин "Изучение криптоскойтости" подходит к алгоритмам
> шифрования, а не хэширования.
так здесь и есть шифрование, только для него используется хеш функция.

> 3)А смысл в изобретении велосипеда? Есть стойкие алгоритмы
> шифрования, есть хэш функции с хорошими показателями - так
> что не надо ничего другого с более плохими показателями.
Смысл есть, например в том, что все достаточно хорошие алгоритмы защищены патентами и ограничениями на экспорт. Т.е. при их использовании могут возникнуть некоторые трудности.

Я ниписал программку, реализующую данный алгоритм, вот некоторые результаты:
- скорость шифрования на уровне 3DES (с учем ассемблерной оптимизации MD5 и без оптимизации моего собственного кода). Т.е. скорость можно поднять еще выше. Сравнивал с реализацией в TrueCrypt.
- для получения маски наложения используется значение предыдущего незашифрованного блока и текущей модификации ключа. это дает то, что даже на одном ключе шифрования разных данных, маски наложения будут разными (кроме первого блока, для MD5 - 16 байт). Как от этого избавиться - я пока не вижу, кроме искуственного добавления в файл дополнительных случайных 16 байт в ег о начало.
- исходный файл, содержащий большое количество одинаковых или повторяющихся данных, шифруется нормально. повторений в зашифрованном файле не наблюдается.

кому интересно, могу дать программку для экспериментов :-)
необходимо только для неухудшения показателей. Т.е... 13.12.06 00:01  
Автор: MadBinom Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Почему необходимо применение некачественных функций???
необходимо только для неухудшения показателей. Т.е. композиция двух хэш-функций будет иметь не менее коллизий чем любая из композиции. А чтобы достигнуть пресловутое НЕ(т е стоко же а не более)
надо, например, чтобы на образе первой функции вторая вообще не имела коллизий. Просто пример. Можно и про другие параметры обсудить, но лучше забей.

>2)Термин "Изучение криптоскойтости" подходит к
> алгоритмам
> > шифрования, а не хэширования.
> так здесь и есть шифрование, только для него используется
> хеш функция.
Тогда объясни подробнее свою идею. Термин хэш почти всегда означает потерю количества информации, а шифрование на ключе - по определению биекция.

> > 3)А смысл в изобретении велосипеда? Есть стойкие
> алгоритмы
> > шифрования, есть хэш функции с хорошими показателями -
> так
> > что не надо ничего другого с более плохими
> показателями.
> Смысл есть, например в том, что все достаточно хорошие
> алгоритмы защищены патентами и ограничениями на экспорт.
> Т.е. при их использовании могут возникнуть некоторые
> трудности.

STWB.

> Я написал программку, реализующую данный алгоритм, вот
> некоторые результаты:
> - скорость шифрования на уровне 3DES (с учем ассемблерной
> оптимизации MD5 и без оптимизации моего собственного кода).
> Т.е. скорость можно поднять еще выше. Сравнивал с
> реализацией в TrueCrypt.
> - для получения маски наложения используется значение
> предыдущего незашифрованного блока и текущей модификации
> ключа. это дает то, что даже на одном ключе шифрования
> разных данных, маски наложения будут разными (кроме первого
> блока, для MD5 - 16 байт). Как от этого избавиться - я пока
> не вижу, кроме искуственного добавления в файл
> дополнительных случайных 16 байт в ег о начало.
Ну, сожми их и поксорь с ключем например.
> - исходный файл, содержащий большое количество одинаковых
> или повторяющихся данных, шифруется нормально. повторений в
> зашифрованном файле не наблюдается.
>
> кому интересно, могу дать программку для экспериментов :-)
Програмку лень смотреть, а вот если есть какая картинка наглядная(хоть от руки на бумажке и сканер) то пришли, посмотрю.
А вот одна правдивая история:
Одному уважаемому криптографу в молодости(он работал в КГБ) поставили задачу пообщаться с человеком, который обивал пороги МГУ в просьбе рассмотреть его изобретение алгоритма шифрования, который кроме стойкого шиврования еще и ВСЕГДА не увеличивает длину исходного сообщения(т е либо длина такая же либо меньше) типа архивирует.Для математиков очевидно, что это бред. Побеседовав с ним, молодой офицер был просто ошеломлен математическим кругозором этого человека - он слышал о вещах, которые только начали изучаться в то время в России(западные труды, а был СССР). В итоге он нашел ошибку, и чел пошел ее исправлять :).
А привел я историю к тому, что "почти наверное" (в твисте это значит, что вероятность равна нулю, но результат все таки может быть) ты где то сделал ошибку.
Не увеличивает, как раз и обозначает, что длина такая же... 13.12.06 12:01  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 13.12.06 12:02  Количество правок: 1
<"чистая" ссылка>
> пороги МГУ в просьбе рассмотреть его изобретение алгоритма
> шифрования, который кроме стойкого шиврования еще и ВСЕГДА
> не увеличивает длину исходного сообщения(т е либо длина
> такая же либо меньше) типа архивирует.Для математиков

Не увеличивает, как раз и обозначает, что длина такая же либо меньше. Простое гаммирование, перестановка или замена, а так же их комбинации и последовательные применения при всем желании не увеличат размер, как впрочем и не уменьшат. С небольшими изысками можно изваять что-то увеличивающее, например добавляя имитовставки или еще как-нибудь, но это уже отдельная тема.

> очевидно, что это бред. Побеседовав с ним, молодой офицер

Бред был бы в гарантированом уменшении размера.

> был просто ошеломлен математическим кругозором этого
> человека - он слышал о вещах, которые только начали
> изучаться в то время в России(западные труды, а был СССР).
Подразумевалось наличие уменьшений, поэтому и бред 13.12.06 22:46  
Автор: MadBinom Статус: Незарегистрированный пользователь
<"чистая" ссылка>
То есть злоумышленнику достаточно знать первые байты... 11.12.06 12:38  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 11.12.06 12:41  Количество правок: 1
<"чистая" ссылка>
> - для получения маски наложения используется значение
> предыдущего незашифрованного блока и текущей модификации
> ключа. это дает то, что даже на одном ключе шифрования
> разных данных, маски наложения будут разными (кроме первого
> блока, для MD5 - 16 байт). Как от этого избавиться - я пока

То есть злоумышленнику достаточно знать первые байты исходного текста, чтоб открыть его целиком. А именно "разгаммируем" первый блок открытым текстом - получим то, что нужно для вычисления хеша для второго блока, то есть незашифрованый предыдущий и модифицированый ключ.
Может я что не понял. "Стойкость не должна падать даже если в руки злоумышленнику попадет комплект другого открытого текста и его шифр, полученый на этом же ключе". Еще добавлю: "Стойкость должна сохраняться, даже если у злоумышленника есть возможность получить большое количество шифровок специально подготовленных открытых текстов тем же ключем+алгоритмом". Сможет ли злоумышленник получить все для взлома, подсунув под этот алгоритм+ключ файл, состоящий из всех нулевых байтиков?

> не вижу, кроме искуственного добавления в файл
> дополнительных случайных 16 байт в ег о начало.
> - исходный файл, содержащий большое количество одинаковых
> или повторяющихся данных, шифруется нормально. повторений в
> зашифрованном файле не наблюдается.

ДайХардом полезно протестировать, хотя это не о чем не говорит, как в данном случае. Думается результат тестирования будет неплохой - ведь используется хорошая хешфункция, а алгоритм требованиям удовлетворять не сможет.
нет, не текст целиком, а только первые 16 байт, т.к... 11.12.06 13:22  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> То есть злоумышленнику достаточно знать первые байты
> исходного текста, чтоб открыть его целиком.
нет, не текст целиком, а только первые 16 байт, т.к. следующий блок гаммируется из сцепки ключа и открытого текста. т.е. знание любой части исходного текста не позволяет расшифровать остальной текст (естественно без знания ключа).

еще раз про алгоритм:
1. получаем хеш значение пароля и заносим его в переменную "ключ"
2. модифицируем ключ на основе предыдущего незашифрованного блока (для первого блока - константа)
3. получаем хеш значение от модифицированного ключа
4. сохряняем открытый блок, который собираемся зашифровать для последующей модификации ключа в пункте 2.
5. гаммируем исходные данные на полученном хеше. это знячение хеша больше нигде не используется. т.е. кахдый кусок данных гамируется на уникальном хеше.
6. идем в пунк 2. и так до конца данных.

как отсюда видно, ненадежно только шифрование первого блока, т.к. для него используется константа.

> ДайХардом полезно протестировать, хотя это не о чем не
> говорит, как в данном случае. Думается результат
> тестирования будет неплохой - ведь используется хорошая
> хешфункция, а алгоритм требованиям удовлетворять не сможет.
А можно ссылочку на ДайХард ?
Исходя из п. 5: Зная первый блок, получаем то, что выползает... 11.12.06 15:08  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 11.12.06 15:10  Количество правок: 1
<"чистая" ссылка>
> > То есть злоумышленнику достаточно знать первые байты
> > исходного текста, чтоб открыть его целиком.
> нет, не текст целиком, а только первые 16 байт, т.к.
> следующий блок гаммируется из сцепки ключа и открытого
> текста. т.е. знание любой части исходного текста не
> позволяет расшифровать остальной текст (естественно без
> знания ключа).
>
> еще раз про алгоритм:
> 1. получаем хеш значение пароля и заносим его в переменную
> "ключ"
> 2. модифицируем ключ на основе предыдущего незашифрованного
> блока (для первого блока - константа)
> 3. получаем хеш значение от модифицированного ключа
> 4. сохряняем открытый блок, который собираемся зашифровать
> для последующей модификации ключа в пункте 2.
> 5. гаммируем исходные данные на полученном хеше. это
> знячение хеша больше нигде не используется. т.е. кахдый
> кусок данных гамируется на уникальном хеше.
> 6. идем в пунк 2. и так до конца данных.

Исходя из п. 5: Зная первый блок, получаем то, что выползает из п. 3, операция обратима какая бы она не была XOR (ADD или другая), проксорив зашифрованый первый блок с его исходным текстом. Затем выполняем п. 2, ксорим со вторым блоком и так далее.

> как отсюда видно, ненадежно только шифрование первого
> блока, т.к. для него используется константа.

> А можно ссылочку на ДайХард ?

А в поисковите слабо набрать "Diehard статистические тесты для измерения качества набора случайных чисел". На память и я ссылки не помню.
Хорошо получается. Напишу алгоритм по другому 11.12.06 21:43  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Исходя из п. 5: Зная первый блок, получаем то, что
> выползает из п. 3, операция обратима какая бы она не была
> XOR (ADD или другая), проксорив зашифрованый первый блок с
> его исходным текстом. Затем выполняем п. 2, ксорим со
> вторым блоком и так далее.

Хорошо получается. Напишу алгоритм по другому

key=хеш значение пароля
data=предыдущий блок открытых данных

// начало цикла
key=key+data // модифицмруем значение ключа на основе исходных данных
hash1= MD5(key) // получаем значение для гаммирования
data=data1 // заносим новое значение для модификации ключа
crypt1=data1 XOR hash1 // шифруем
// конец цикла

отсюда видно, что даже зная crypt1, hash1 и data1это нам не помогает в вычислении следующего значения data2, т.к. hash2 вычисляется как хеш функция от key+data1, а не просто data1. Так же как и значение hash1 не участвует в последуюших вычислениях. Значение key получить нельзя, даже зная исходный текст целиком. т.е. в выражении
hash = MD5( key + data )
при известных hash и data, значение key вычислить нельзя. только перебором.
Теоретически надежность метода сводится к надежности хеш функции, а, например, у MD5 или SHA1 устойчивость высокая.
Гм. Смысл шифрования в том, чтобы потом расшифровать. А тут... 13.12.06 00:11  
Автор: MadBinom Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> // начало цикла
> key=key+data // модифицмруем значение ключа на основе
> исходных данных
> hash1= MD5(key) // получаем значение для гаммирования
> data=data1 // заносим новое значение для модификации
> ключа
> crypt1=data1 XOR hash1 // шифруем
> // конец цикла
Гм. Смысл шифрования в том, чтобы потом расшифровать. А тут ты не сможешь.
Как это не смогу? как раз могу. Причем алгоритм расшифровки... 13.12.06 10:33  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Гм. Смысл шифрования в том, чтобы потом расшифровать. А тут
> ты не сможешь.
Как это не смогу? как раз могу. Причем алгоритм расшифровки полностью аналогичный, за исключением того, что при шифровании исходные данные для смешивания берутся до наложения маски, а при расшифровании - после снятия маски. Именно по этому и стоит проблемма первого блока, т.к. для него предыдущих данных нет и по этому используется константа. А это значит что при одном ключе на разных файлах маска наложения для первого блока будет всегда одинаковая. Но только для первого. С остальными все впорядке.
Это не проблема. Нет ничего в этом страшного. Если очень... 13.12.06 12:28  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Именно по этому и стоит проблемма первого блока, т.к. для
> него предыдущих данных нет и по этому используется

Это не проблема. Нет ничего в этом страшного. Если очень хочется избавиться от проблемы первого блока, то перед ним можно вставить блок из случаных чисел, индивидуально сгенеренных для каждого сеанса шифрования. После расшифровывания этот блок просто выкинуть. Размер шифра чуть увеличиться на один блок.

> константа. А это значит что при одном ключе на разных
> файлах маска наложения для первого блока будет всегда
> одинаковая. Но только для первого. С остальными все
> впорядке.
Именно это решение и напрашивается, просто, на сколько я... 13.12.06 12:47  
Автор: Maksim Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Это не проблема. Нет ничего в этом страшного. Если очень
> хочется избавиться от проблемы первого блока, то перед ним
> можно вставить блок из случаных чисел, индивидуально
> сгенеренных для каждого сеанса шифрования. После
> расшифровывания этот блок просто выкинуть. Размер шифра
> чуть увеличиться на один блок.

Именно это решение и напрашивается, просто, на сколько я помню, одно из правил симметчного шифрования, это то, что размер исходных данных и зашифрованных должен быть одинаковым. Хотя, может это просто пожелание...
1) В пределах блока то все нормально. 13.12.06 13:36  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Именно это решение и напрашивается, просто, на сколько я
> помню, одно из правил симметчного шифрования, это то, что
> размер исходных данных и зашифрованных должен быть
> одинаковым. Хотя, может это просто пожелание...

1) В пределах блока то все нормально.
2) Очень часто дописывают ключ, зашифрованый для нескольких корреспондентов.
3) Не менее часто приписывают инфу о ключе (номер, время_дата шифрования и много всяких атрибутов).

Все равно эффекта от данного метода нет. Не будет выигрыша ни в скорости, ни в стойкости.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach