Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Достаточно, чтобы было a<p, остальное дополняется нулями до... 13.05.04 16:11 Число просмотров: 2815
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > т.е. исходные данные - а?
> > в общем случае они имеют произвольный размер.
>
> Достаточно, чтобы было a<p, остальное дополняется нулями
> до размера p.
Угу. Особенно если хешируется файлик мегабайт на несколько...
> На счет особой заботы о значении p и свойствах дискретных
> логарифмов можно не заморачиваться,
> ибо функция у нас необратимая, и мы ее не знаем, а знаем
> только ее MD5. Из MD5 на 128бит
По-моему, ты очень невнимательно читаешь. Вот уже MD5 откуда-то взялся, т.е. исходный массив мы все-таки хешируем "до того, как".
Кроме того, все функции известны, просто нет обратных функций.
|
|
<theory>
|
ЭЦП в роли медленного хеша 12.04.04 10:22
Автор: cybervlad <cybervlad> Статус: Elderman
|
Hужно чтобы хеш считался очень медленно, и при этом вычисления нельзя было бы
ускорить алгоритмически.
Все "нормальные" хеши (типа SHA-1), к несчастью ;), считаются достаточно
быстро.
Что думает уважаемая общественность по поводу следующей схемы:
1) При помощи "нормального" хеша обрабатываем входные данные
2а) Вычисляем для результата цифровую подпись (ключ - константа)
или
2б) Вычисляем для константы цифровую подпись (ключ - результат с шага 1)
3) Результат еще раз обрабатываем "нормальным" хешем.
p.s. Предвидя вопрос "а нафига такой изврат?" :)
В большинстве реализаций шифрованных дисков и криптоконтейнеров, где
секретность базируется на пароле, реализована примерно следующая схема:
- собственно объект шифруется на ключе хранения;
- ключ хранения шифруется на "пользовательском" ключе и хранится в заголовке
объекта с контрольной суммой;
- пользовательский ключ получается путем хеширования вводимого пользователем
пароля.
Соответственно, схема атаки:
- берем очередной пароль (по словарю или генерируем), считаем от него хеш;
- используя хеш как ключ, расшифровываем ключ хранения и его контрольную
сумму;
- проверяем контрольную сумму ключа - если совпала с расшифрованной, значит
пароль правильный, полученный ключ хранения - тоже.
Hапример, для контейнера bestcrypt скорость перебора составляет примерно 1180
вариантов в секунду на стареньком PII-400. Т.е. 8-символьный пароль из одних
только цифр гарантированно подбирается за сутки.
Если расчет хеша из пароля будет медленным, то такая атака потеряет смысл. Hа
работе системы это (замедление) скажется не сильно отрицательно, поскольку
задержка даже в 0.5 секунды при инициализации криптоконтейнера вполне
допустима.
|
|
А если так: 13.05.04 19:12
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 13.05.04 19:20 Количество правок: 2
|
А если так:
Перебираем данные группами по несколько байтиков (все равно сколько, можно по одному, а можно чтоб размер блока равнялся разрядности ЭЦП), каждую итеррацию вычисляем H[n]=ЭЦП(D[n],H[n-1]). Начальный хеш - любое число. Может даже слишком медленно получится. "Обходных" путей вычисления конечного ЭЦП не наблюдаю.
|
|
Я бы сделал так:
12.05.04 17:09
Автор: persicum Статус: Незарегистрированный пользователь
|
> Hужно чтобы хеш считался очень медленно
Я бы сделал так:
1) x = a^b mod p;
2) y = MD5(x)
И того имеем: y=HASH(a).
Есть тут немного от цифровой подписи, и MD5 не надо миллион раз применять, и сообщение не надо в миллион раз удлиннять.
Если p - простое число на 2048 бит, b - случайное число на 2048 bit (лучше взаимно-простое с p-1),
a <= 2048 бит - задержка на 0.5 сек тебе обеспечена.
|
| |
Я бы сделал так: 13.05.04 13:33
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > Hужно чтобы хеш считался очень медленно
>
> Я бы сделал так:
>
> 1) x = a^b mod p;
> 2) y = MD5(x)
>
> И того имеем: y=HASH(a).
т.е. исходные данные - а?
в общем случае они имеют произвольный размер, т.е. нужно предварительно хешировать.
кроме того, a и p должны выбираться не совсем от фонаря.
|
| | |
Достаточно, чтобы было a<p, остальное дополняется нулями до... 13.05.04 15:56
Автор: persicum Статус: Незарегистрированный пользователь
|
> т.е. исходные данные - а?
> в общем случае они имеют произвольный размер.
Достаточно, чтобы было a<p, остальное дополняется нулями до размера p.
На скорость возведения по модулю это никак не влияет.Для криптографии можно конечно дополнить а до размера 2048 не нулями, а случайными числами,
ведь обратимость нам не нужна. Если a>p, то можно его и захешерить.
На счет особой заботы о значении p и свойствах дискретных логарифмов можно не заморачиваться,
ибо функция у нас необратимая, и мы ее не знаем, а знаем только ее MD5. Из MD5 на 128бит
дискретный логарифм на 2048бит хрен найдешь, как не старайся.
Чтобы не мучиться с делением, можно взять простое составное число мерсена на 2048 бит,
например
2^2048 - 2^448 + 2^192 + 1
2^2048 - 2^1472 + 2^1152 + 1
|
| | | |
Достаточно, чтобы было a<p, остальное дополняется нулями до... 13.05.04 16:11
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > т.е. исходные данные - а?
> > в общем случае они имеют произвольный размер.
>
> Достаточно, чтобы было a<p, остальное дополняется нулями
> до размера p.
Угу. Особенно если хешируется файлик мегабайт на несколько...
> На счет особой заботы о значении p и свойствах дискретных
> логарифмов можно не заморачиваться,
> ибо функция у нас необратимая, и мы ее не знаем, а знаем
> только ее MD5. Из MD5 на 128бит
По-моему, ты очень невнимательно читаешь. Вот уже MD5 откуда-то взялся, т.е. исходный массив мы все-таки хешируем "до того, как".
Кроме того, все функции известны, просто нет обратных функций.
|
|
А может сделать как в 3-ем WinRARe? 15.04.04 12:04
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
Там к паролю, введенному пользователем, применяется 200 с лишним тысяч SHA-1 преобразований. Это занимает примерно 1 секунду, зато самые оптимистичные прогнозы на подбор - 8 вариантов в секунду.
ЗЫ. Могу ошибиться в деталях, в свое время после выхода 3-го ВинРАРа где в инете читал про это все, здесь привожу по памяти.
|
| |
Этот вариант мне в ru.crypt расказали уже. Это, так сказать,... 15.04.04 16:21
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Там к паролю, введенному пользователем, применяется 200 с
> лишним тысяч SHA-1 преобразований. Это занимает примерно 1
> секунду, зато самые оптимистичные прогнозы на подбор - 8
> вариантов в секунду.
Этот вариант мне в ru.crypt расказали уже. Это, так сказать, экстенсивный подход - много раз считаем одно и тоже. А я предлагаю "интенсивный", т.е. считать один раз, но более сложную функцию.
> ЗЫ. Могу ошибиться в деталях, в свое время после выхода
> 3-го ВинРАРа где в инете читал про это все, здесь привожу
> по памяти.
Там немного не так. Оно пароль "размножает" с сальтом и счетчиком, а потом от получившейся офигенно длинной строки считает SHA-1.
|
| | |
Да, наверное, экстенсивный, но ведь задача так и стоит... 15.04.04 17:09
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
> Этот вариант мне в ru.crypt расказали уже. Это, так
> сказать, экстенсивный подход - много раз считаем одно и
> тоже. А я предлагаю "интенсивный", т.е. считать один раз,
> но более сложную функцию.
В конечном счете все дороги ведут в одну сторону - увеличение числа тактов процессора для выполнения какой-то задачи. А увеличение числа тактов в данном случае необходимо только с одной целью - увеличить время, необходимое на перебор вариантов пароля, так ведь? Вот этой самой "экстенсификацией" мы время-то и увеличиваем.
> Там немного не так. Оно пароль "размножает" с сальтом и
> счетчиком, а потом от получившейся офигенно длинной строки
> считает SHA-1.
Угу, и еще 128 битное AES-шифрование использует для чего-то...
|
|
Предлагаю посчитать два хеша разными методами, потом один из... 12.04.04 11:00
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 12.04.04 11:00 Количество правок: 1
|
> Hужно чтобы хеш считался очень медленно, и при этом
> вычисления нельзя было бы
> ускорить алгоритмически.
> Все "нормальные" хеши (типа SHA-1), к несчастью ;),
> считаются достаточно
> быстро.
> Что думает уважаемая общественность по поводу следующей
> схемы:
> 1) При помощи "нормального" хеша обрабатываем входные
> данные
> 2а) Вычисляем для результата цифровую подпись (ключ -
> константа)
> или
> 2б) Вычисляем для константы цифровую подпись (ключ -
> результат с шага 1)
> 3) Результат еще раз обрабатываем "нормальным" хешем.
Предлагаю посчитать два хеша разными методами, потом один из них шифрануть, используя второй как ключ. То есть отказаться от константы.
> p.s. Предвидя вопрос "а нафига такой изврат?" :)
> В большинстве реализаций шифрованных дисков и
> криптоконтейнеров, где
> секретность базируется на пароле, реализована примерно
> следующая схема:
> - собственно объект шифруется на ключе хранения;
> - ключ хранения шифруется на "пользовательском" ключе и
> хранится в заголовке
> объекта с контрольной суммой;
> - пользовательский ключ получается путем хеширования
> вводимого пользователем
> пароля.
Мне тоже не нравится эта безобразная технология.
> Соответственно, схема атаки:
> - берем очередной пароль (по словарю или генерируем),
> считаем от него хеш;
> - используя хеш как ключ, расшифровываем ключ хранения и
> его контрольную
> сумму;
> - проверяем контрольную сумму ключа - если совпала с
> расшифрованной, значит
> пароль правильный, полученный ключ хранения - тоже.
> Hапример, для контейнера bestcrypt скорость перебора
> составляет примерно 1180
> вариантов в секунду на стареньком PII-400. Т.е.
> 8-символьный пароль из одних
> только цифр гарантированно подбирается за сутки.
>
> Если расчет хеша из пароля будет медленным, то такая атака
> потеряет смысл. Hа
> работе системы это (замедление) скажется не сильно
> отрицательно, поскольку
> задержка даже в 0.5 секунды при инициализации
> криптоконтейнера вполне
> допустима.
Может просто увеличить длину ключа... Ну да пароль в 8 знаков достаточно быстро ломаем, а если взять 16... Прикинем как возрастет время взлома. А уж подбор по словарю отпадет сам собой.
|
| |
Тоже вариант...
12.04.04 13:24
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Предлагаю посчитать два хеша разными методами, потом один
> из них шифрануть, используя второй как ключ. То есть
> отказаться от константы.
Тоже вариант...
Или даже просто подписать данные, используя их же как ключ...
> > - пользовательский ключ получается путем хеширования
> > вводимого пользователем
> > пароля.
>
> Мне тоже не нравится эта безобразная технология.
Ну почему же "безобразная"? Понятно, что правильнее всего совать ключ на отчуждаемый носитель (смарт-карта, е-токен и т.п.) с защитой оного ПИН-кодом. Но это не всегда технически возможно...
> > задержка даже в 0.5 секунды при инициализации
> > криптоконтейнера вполне
> > допустима.
>
> Может просто увеличить длину ключа... Ну да пароль в 8
В смысле, длину пароля?
Нельзя. Пароль длинее 8 символов однозначно будет записан на бумажку...
> знаков достаточно быстро ломаем, а если взять 16...
> Прикинем как возрастет время взлома. А уж подбор по словарю
> отпадет сам собой.
Не факт. Для длинных паролей юзеры все равно новорят использовать сочетания словарных слов...
|
| | |
Может я излишне жесток, но справедлив. 13.04.04 11:23
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 13.04.04 11:27 Количество правок: 3
|
> Тоже вариант...
> Или даже просто подписать данные, используя их же как
> ключ...
Данные быают велики или малы (объем/размер в смысле), а алгоритм требует ключ определенной длины, поэтому все-таки следует еще один хеш посчитать (для того он и придуман). Впрочем суть мало меняется.
> Ну почему же "безобразная"? Понятно, что правильнее всего
> совать ключ на отчуждаемый носитель (смарт-карта, е-токен и
> т.п.) с защитой оного ПИН-кодом. Но это не всегда
> технически возможно...
Сейчас уже возможно. Ключи редко превышают длину 2 килобита, а в крохотную точ-мемори можно и 16 мегабайт вогнать. Пару лет назад еще нельзя было, год назад дорого было, а сейчас вполне доступно.
> В смысле, длину пароля?
> Нельзя. Пароль длинее 8 символов однозначно будет записан
> на бумажку...
Уверяю, многие юзеры на бумажку записывают пароль даже диной в 1 символ, потому, что у них может не один такой пароль в процессе работы используется для регистрации в различных системах или надо сообщить пароль сотруднику, который вместо уходящего в отпуск будет выполнять работу. Если информация, закрытая парольным доступом представляет достаточную ценность, то я считаю длина пароля должна приближаться к 16 знакам, причем под страхом "смертной казни" пароль не должен быть нигде записан.
Естественно пароль - не ключ, он не должен быть длионй в килобит (128 знаков), это действительно бред.
Весь смысл в предназначении - то ли это пароль для идентификации, то ли его хеш используется для шифрования.
Если сотрудник не в состоянии раз в год запомниь без бумажки сложный пароль, то нефига его допускать к информации, которая требует более серьезной парольной защиты. В противном случае не стоит изголяться и применять медленные хеши в этой системе, если инфа, которая за ней спрятана не так секретна.
> Не факт. Для длинных паролей юзеры все равно новорят
> использовать сочетания словарных слов...
Если добавить день рождения, номер телефона, знаки припинания, слова в падежах, склонениях, транскрибциях (латинница или без переключения на русскую раскладку)...
Я люблю слова с ошибками или те, которых в словаре никогда не будет.
|
| | | |
Ты не прав.
13.04.04 14:37
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > Тоже вариант...
> > Или даже просто подписать данные, используя их же как
> > ключ...
>
> Данные быают велики или малы (объем/размер в смысле), а
> алгоритм требует ключ определенной длины, поэтому все-таки
> следует еще один хеш посчитать (для того он и придуман).
> Впрочем суть мало меняется.
Ты не прав.
"Данные" в данном случае - результат хеширования пароля. Размер хеша совпадает с размером ключа подписи. Да и в ЭЦП подписывают не саму информацию, а хеш от нее.
Т.е. имелось ввиду следующее:
hash=H(пароль)
key=hash
signature=Fs(hash, key)
А уже signature использовать для расшифрования ключа хранения ;)
> > т.п.) с защитой оного ПИН-кодом. Но это не всегда
> > технически возможно...
>
> Сейчас уже возможно. Ключи редко превышают длину 2
> килобита, а в крохотную точ-мемори можно и 16 мегабайт
> вогнать. Пару лет назад еще нельзя было, год назад дорого
> было, а сейчас вполне доступно.
Во-первых, я не об этом ;)
Вот я в АБС хожу по SSH, потому что она реализована в виде консольного юникс-приложения. Ты мне предлагаешь бежать на 5 этажей вверх, вламливаться в серверную, искать на попе у сервера USB-разъем (железяка совсем даже не intel-based) и делить ее еще с парой сотен таких же страждущих юзеров? ;)
Во-вторых, а тач мемори 16 мегабайт не влазит. Самая "толстая" - DS1996 имеет объем памяти 16 килобит, как краевед говорю ;) У меня в ней ключи ЭЦП хранятся ;)
> > Нельзя. Пароль длинее 8 символов однозначно будет
> записан
> > на бумажку...
>
> Уверяю, многие юзеры на бумажку записывают пароль даже
> диной в 1 символ, потому, что у них может не один такой
Есть и такие. Вот от них и надо избавляться, а большинство, все-таки, нормальные, и 8-символьный пароль запоминают.
Более длинные пароли запомнить может не каждый, доказано психологами, и не за чем над людьми издеваться...
> пароль в процессе работы используется для регистрации в
> различных системах или надо сообщить пароль сотруднику,
> который вместо уходящего в отпуск будет выполнять работу.
Совершенно отнюдь! (с)
Просто назначить замещающему права необходимые...
> Если информация, закрытая парольным доступом представляет
> достаточную ценность, то я считаю длина пароля должна
> приближаться к 16 знакам, причем под страхом "смертной
> казни" пароль не должен быть нигде записан.
Нет. Это как функция с экстремумом. Увеличение длины пароля эффективно до 8 символов. Потом их либо записывают, либо забывают постоянно, либо выбирают плохие пароли (16 единиц).
|
| | | | |
Ты не прав. 14.04.04 12:38
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 14.04.04 12:44 Количество правок: 1
|
> "Данные" в данном случае - результат хеширования пароля.
> Размер хеша совпадает с размером ключа подписи. Да и в ЭЦП
> подписывают не саму информацию, а хеш от нее.
> Т.е. имелось ввиду следующее:
> hash=H(пароль)
> key=hash
> signature=Fs(hash, key)
> А уже signature использовать для расшифрования ключа
> хранения ;)
Тогда - пожалуйста, я иногда забываю, что речь о пароле идет, думаю о хешах больших текстов.
> Во-первых, я не об этом ;)
> Вот я в АБС хожу по SSH, потому что она реализована в виде
> консольного юникс-приложения. Ты мне предлагаешь бежать на
> 5 этажей вверх, вламливаться в серверную, искать на попе у
> сервера USB-разъем (железяка совсем даже не intel-based) и
> делить ее еще с парой сотен таких же страждущих юзеров? ;)
А что за станции, на которых юзеры сидят - там что никаких кард-ридеров нет? Хотя это не важно, если идентификация по паролю - даже точ мемори не надо.
> Во-вторых, а тач мемори 16 мегабайт не влазит. Самая
> "толстая" - DS1996 имеет объем памяти 16 килобит, как
> краевед говорю ;) У меня в ней ключи ЭЦП хранятся ;)
Ну сегодня нет - завтра появится: 16Мб в таблетку запихнуть не проблема, технология уже позволяет. Может пока особо не требовалось, а "завтра" всем захочется.
> Совершенно отнюдь! (с)
> Просто назначить замещающему права необходимые...
Это по-хорошему, а в жизни всякое бывает, и виноват в этом порой вовсе не "ленивый" админ.
> Нет. Это как функция с экстремумом. Увеличение длины пароля
> эффективно до 8 символов. Потом их либо записывают, либо
> забывают постоянно, либо выбирают плохие пароли (16
> единиц).
Я бы еще сделал поправку на уровень секретности 1 - типа пина (мобильник, кредитная карта) от 4 до 6 можно все цифрами. 2 - информация не представляющая особой ценности от 6 до 8 символов (может Ваш случай). 3 - Секретная инфа вплоть то военной тайны за исключением пароля к "ядерному чемоданчику" желательно выйти за пределы 8 знаков и исключить возможность особо коротких и плохих паролей.
|
| | | | | |
Вот ;) Собственно, и вернулись к вопросу: не несет ли такая... 14.04.04 16:04
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Тогда - пожалуйста, я иногда забываю, что речь о пароле
> идет, думаю о хешах больших текстов.
Вот ;) Собственно, и вернулись к вопросу: не несет ли такая схема математически/риптографически скрытых подводных граблей?
> А что за станции, на которых юзеры сидят - там что никаких
> кард-ридеров нет? Хотя это не важно, если идентификация по
> паролю - даже точ мемори не надо.
Персоналки, и ридеры TM есть. Но что толку от них, если приложение работает на толстом юникс-сервере 5 этажами выше? Криптоконтейнер файловый лежит там. Не передавать же ключ по сети в открытом виде...
> > Во-вторых, а тач мемори 16 мегабайт не влазит. Самая
> > "толстая" - DS1996 имеет объем памяти 16 килобит, как
> > краевед говорю ;) У меня в ней ключи ЭЦП хранятся ;)
>
> Ну сегодня нет - завтра появится: 16Мб в таблетку запихнуть
Но пока-то нету ;)
> Я бы еще сделал поправку на уровень секретности 1 - типа
> пина (мобильник, кредитная карта) от 4 до 6 можно все
> цифрами. 2 - информация не представляющая особой ценности
> от 6 до 8 символов (может Ваш случай). 3 - Секретная инфа
> вплоть то военной тайны за исключением пароля к "ядерному
> чемоданчику" желательно выйти за пределы 8 знаков и
> исключить возможность особо коротких и плохих паролей.
Согласен.
|
| | | | | | |
Не должно быть, если хеш расчитывается стойким алгоритмом, а... 14.04.04 17:43
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Вот ;) Собственно, и вернулись к вопросу: не несет ли такая
> схема математически/риптографически скрытых подводных
> граблей?
Не должно быть, если хеш расчитывается стойким алгоритмом, а потом правильно генерятся ключи по хешу. Здесь по определению обратный перерасчет сделать невозможно. Это как 64 битный блок зашифровать по DESу используя его же как ключ. Есть шифровка, ключа нет, алгоритм известен. Ключ получить легко, расшифровав этот 64 битный блок, только для этого нужен ключ, а он у нас есть в зашифрованном виде только. Замкнутый круг получается. Я бы еще пример с ксором привел: имеем все нулевые биты - что было "в оригинале"? К сожалению в данном случае этот метод не применим, а только для глупого примера, но DES уже нужными свойствами обладает и RSA тоже. Стойкость обычно не падает, она может остаться неизменной (при повторном применении аналогичного метода) или возрасти, если шифруем шифровку другим методом. Ослабления ниже стойкости алгоритма самого хеша не получится.
|
| | | | | | | |
Ну, естессно, надо использовать хеш, "приспособленный" к... 15.04.04 09:39
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Не должно быть, если хеш расчитывается стойким алгоритмом,
> а потом правильно генерятся ключи по хешу. Здесь по
Ну, естессно, надо использовать хеш, "приспособленный" к используемому алгоритму подписи.
> определению обратный перерасчет сделать невозможно. Это как
> 64 битный блок зашифровать по DESу используя его же как
> ключ. Есть шифровка, ключа нет, алгоритм известен. Ключ
Угу, я именно про это. Только предлагаю не симметричный DES использовать, а двухключевой алгоритм - RSA там, или Эль-Гамаля. Причем, второй ключ ренерировать не придется, обратное преобразование-то не нужно...
Но поскольку не силен в дискретке, то и возник вопрос, не получится ли там какого-нибудь вырожденного случая...
> и RSA тоже. Стойкость обычно не падает, она может остаться
> неизменной (при повторном применении аналогичного метода)
> или возрасти, если шифруем шифровку другим методом.
А вот это не факт. В ru.crypt довольно долго бойня шла на тему последовательного применения разных шифров. Были аргументы, что это может выйти боком в плане суммарной стойкости...
> Ослабления ниже стойкости алгоритма самого хеша не
> получится.
Может быть, может быть...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
