Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет olegmi ([info]olegmi)
@ 2008-07-11 15:25:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Прочитав это, я решил, что мне с AES крайне не по пути...
===================
http://www.ixbt.com/soft/alg-encryption-aes.shtml
NIST установил всего два обязательных требования к алгоритмам-участникам конкурса [4]:

1. 128-битный размер блока шифруемых данных,

2. не менее трех поддерживаемых алгоритмом размеров ключей шифрования: 128, 192 и 256 бит.

Однако, несравнимо больше было «рекомендательных» требований к будущему стандарту шифрования США. Поскольку соответствовать обязательным требованиям было достаточно просто, анализ алгоритмов и выбор из них лучшего производился именно по его соответствию «необязательным» характеристикам. «Пожелания» института NIST были, в частности, таковы [4]:

1. Алгоритм должен быть стойким против криптоаналитических атак, известных на время проведения конкурса.

2. Структура алгоритма должна быть ясной, простой и обоснованной, что, во-первых, облегчало бы изучение алгоритма специалистами, а во-вторых, гарантировало бы отсутствие внедренных авторами алгоритма «закладок» (т.е. в данном случае, особенностей архитектуры алгоритма, которыми теоретически могли бы воспользоваться его авторы в злоумышленных целях).

3. Должны отсутствовать слабые и эквивалентные ключи (т.е. ключи, являющиеся различными, но приводящие к одному и тому же результату шифрования).

4. Скорость шифрования данных должна быть высокой на всех потенциальных аппаратных платформах — от 8-битных до 64-битных.

5. Структура алгоритма должна позволять распараллеливание операций в многопроцессорных системах и аппаратных реализациях.

6. Алгоритм должен предъявлять минимальные требования к оперативной и энергонезависимой памяти.

7. Не должно быть ограничений для использования алгоритма; в частности, алгоритм не должен ограничивать свое использование в различных стандартных режимах работы (см. [10]), в качестве основы для построения хэш-функций (см. статью «Назначение и структура алгоритмов шифрования», содержащую классификацию криптографических алгоритмов и описание наиболее часто встречающихся структур алгоритмов шифрования), генераторов псевдослучайных последовательностей и т.д.
=====
В переводе на простой язык это звучит так: "чтобы АНБ было удобно его ломать атакой грубой силы и таблицами".


(Читать комментарии) - (Добавить комментарий)


[info]anonymous
2008-07-14 11:39 (ссылка)
Да ничего не будет. Пользуйтесь самодельным одноразовым блокнотом, никто и слова не скажет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-18 10:27 (ссылка)
Если средний джон изобразит "самодельный одноразовый блокнот" то это будет ломаться на ура. А если случится чудо, м джоны таки серьезно займутся блокнотным делом, то главному организатору очень скоро будут кранты.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anonymous
2008-07-18 11:12 (ссылка)
> Если средний джон изобразит "самодельный одноразовый блокнот" то это будет ломаться на ура.

Когда я говорил "самодельный одноразовый блокнот" я имел в виду именно самодельный одноразовый блокнот.

> А если случится чудо, м джоны таки серьезно займутся блокнотным делом, то главному организатору очень скоро будут кранты.

Главный организатор - это кто? Автор брошюры (или странички в интернете) "как сделать одноразовый блокнот"? Да ничего ему не будет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-18 11:54 (ссылка)
Вы пробовали сгенерить мегабайт энтропии руками?
Лично у меня на это уйдет неделя писания исходников, если с нуля. Но это у меня. А как это будет делать джон? Или он копи-пастом размножит секретную фразу "fuck_u" и использует это в качестве маски?

Один мой сослуживец реально думал, что этнтропию можно генерить подсчетом CRC32 от предидущих 4 байт. Ну а инициализировал он эту муть от таймера. И это продвинутый програмист с опытом! А что мы будем ждать от джона?

Чтобы организовать блокноты, нужно написать прогу. Найдется куча законов, по которым посадят ее автора. В крайнем случае - автомобильная катастрофа.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anonymous
2008-07-18 14:23 (ссылка)
> Чтобы организовать блокноты, нужно написать прогу.

Еще раз - я говорил про одноразовый блокнот. Прогу писать не надо, надо брать два листа бумаги и игральную кость.

Мегабайт энтропии вовсе не требуется - для того, чтобы осбудить с друзьями готовящийся теракт, нужны гораздо меньшие объемы гаммы. Да, устроить нелегальный обмен песнями Бритни Спирс не получится. Но, увы, именно лаконичные парни представляют гораздо больший интерес для NSA, чем те, кто занимается файлообменом.

> Лично у меня на это уйдет неделя писания исходников, если с нуля. Но это у меня.
> Один мой сослуживец ... инициализировал он эту муть от таймера. И это продвинутый програмист с опытом! А что мы будем ждать от джона?

А из чего собираетесь получать энтропию Вы, если не секрет?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-18 19:00 (ссылка)
Игральная кость никогда не имеет нормальной балансироваки. Так делать нельзя. К тому же только програмисты смогут реально использовваь этот метод.

Энтропию я беру из двух источников.
1. регистр тиков проца. Но читать регистр нужно не подряд, а опереться на дополнительные события(клава, крыса, сик винта или сидюка) или хотя бы задержать чтение слипом, если компьютер не простаивает.
2. wav с локального микрофонна + rar -m5

Оба источника содержат только маленькую часть энтропии. Поэтому их нужно тщательно размешать, снизив по дороге объем раз в 10 минимум. Реально топчу раз в 100-1000, в зависимости от сопутствующих обстоятельств, чтобы не ломать голову над степенью случайности.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anonymous
2008-07-18 21:41 (ссылка)
> Игральная кость никогда не имеет нормальной балансироваки. Так делать нельзя.

Сверхточная балансировка в данном случае не критична. А на наличие грубых отклонений кость легко проверить. Поэтому так делать можно, NSA ничего расшифровать не сможет. Я гарантирую это.

> К тому же только програмисты смогут реально использовваь этот метод.

О том, что такое одноразовый блокнот, и как им пользоваться, я впервые услышал в семь лет от своего родственника, служившего в 1960-ых в ВДВ. Программистом он не был.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-20 01:28 (ссылка)
Смотря какой разбаланс, сколько и как шифровать. Если маска и расбаланс 10%, то уже через 10к появятся мутные кореляции. Если абсолтный сдвиг, - кажется то же, но я не обдумал хорошо. Если диференциальный сдвиг, то это полегче, но такой метод требует безошибочности исполнения...

Солдаты ВДВ приравнивабтся к компьютерам. :)
А у гражданских будет проблема, если подряд три одинаковых числа. Наверняка соблазнятся одно убрать...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anonymous
2008-07-20 02:10 (ссылка)
> Смотря какой разбаланс, сколько и как шифровать. Если маска и расбаланс 10%, то уже через 10к появятся мутные кореляции. Если абсолтный сдвиг, - кажется то же, но я не обдумал хорошо. Если диференциальный сдвиг, то это полегче, но такой метод требует безошибочности исполнения...

Звучит довольно бессвязно.

> А у гражданских будет проблема, если подряд три одинаковых числа. Наверняка соблазнятся одно убрать...

Это, конечно, нехорошо, но тоже не критично.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-20 14:40 (ссылка)
Переформулирую.

Попустим, у Вас есть для каждого знака Pn от 0 до 35.
Вы можете сделать Cn=(Mn+Pn)%36. Но если балансировка плохая, то могут возникнуть кореляции. А можно Cn=(Mn+P0+P1+...+Pn)%36. Так надежнее. Но одна ошибка исполнителя и последующий текст будет нечитабельным...

(Ответить) (Уровень выше)


[info]olegmi
2008-07-20 14:41 (ссылка)
Вот на всех этих мелких проколах блокнот и колется...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]anonymous
2008-07-20 16:30 (ссылка)
> Вот на всех этих мелких проколах блокнот и колется...

Блокнот не колется. Даже с более крупными проколами - для советских блокнотов случайные числа вообще живой человек генерировал.

Абсолютная надежность шифроблокнота определяется не столько тем, что любые открытые тексты равновероятны, сколько тем, что их вероятность не равна 0. Поэтому некоторая неслучайность гаммы не критична.

> Попустим, у Вас есть для каждого знака Pn от 0 до 35. Вы можете сделать Cn=(Mn+Pn)%36. Но если балансировка плохая, то могут возникнуть кореляции.

Теоретически - это нехорошо. Практически - эти корреляции не помогут расшифровать текст.

> А можно Cn=(Mn+P0+P1+...+Pn)%36. Так надежнее.

Очевидно, что по надежности это эквивалентно С'n=C(n)-C(n-1)=M(n)-M(n-1)+Pn=M'n+Pn, где M'(n)=M(n)-M(n-1). Да, разбаланс гаммы будет от этого несколько уменьшен.

Иными словами, того же (в смысле надежности) результата можно добиться, записывая на бумагу не результаты бросков, а разность между текущим и предыдущим броском. Поскольку корреляцию между бросками можно исключить, то это улучшит гамму. В этом случае можно не бояться того, что

> Но одна ошибка исполнителя и последующий текст будет нечитабельным...

Впрочем, есть и более простые способы улучшить качество гаммы. Но, повторюсь, особой необходимости в этом нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]olegmi
2008-07-20 17:45 (ссылка)
Сейчас - может Вы и правы. Но тут скорее лингвистов нужно подключать. Я над ломом этого дела думал мало, так что не рискнул бы делать смелые ходы. Лучше этим не увлекаться.

(Ответить) (Уровень выше)


(Читать комментарии) -