Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
| | | | | | | | |
Балин! Место хранения пароля определяется самим паролем! 26.05.04 02:52 Число просмотров: 1531
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
Точнее, не пароля, а каждого из его байтов. Зная пароль, алгоритм находит эти байты и сравнивает их с паролем. И весь файл расшифровывать не надо.
|
|
<beginners>
|
Куда спрятать пароль 24.05.04 01:55
Автор: Lutien Статус: Незарегистрированный пользователь
|
Вот тут, захотелось попрактиковаться в криптографии, типа шифрацию файлов написать.
Вроде все просто, спрашиваем у юзверя пароль, вставляем его в алгоритм шифрования и понеслась.
Вроде все ок, но вот как автоматизировать проверку пароля на правильность, а то получается белеберда, при расшифровке, если вести неправильный пароль то, прога выводит белетристику. Понятно что это из-за того что расшифровка проводится не на том ключе :((((
В общем как отметать при неправильном вводе пароля?
Первая мысль, хранить пароль в шифруемом файле? Но имхо, это не есть гут, его же оттуда достанут ?
В общем, может кто поможет мне бедной?
Особая благодарность, кинувшим в меня ссулкой на статью какую по этому поводу.
Заранеи всем огромный респект!
|
|
Заранее извиняюсь, если повторяю чей-то каммент, просто... 02.06.04 14:38
Автор: Heller <Heller> Статус: Elderman
|
Заранее извиняюсь, если повторяю чей-то каммент, просто времени всё читать нет, а решение гарантированное подсказать могу.
Просто пароль надо хранить отдельно в файле в зашифрованном виде. НО! Зашифрованном необратимой функцией (остаток от деления, например после каких-то преобразований). Саму функцию ты не разглашаешь. Тогда при вводе пароля тебе надо не расшифровывать пароль из файла, а зашифровывать введённый и сравнивать. Вот и всё, в общем-то.
ЗЫ. А за риспект спасибо :-)
|
| |
"стойкость шифра зависит только от стойкости ключа" к.шеннон 02.06.04 15:31
Автор: Garick <Yuriy> Статус: Elderman
|
> деления, например после каких-то преобразований). Саму
> функцию ты не разглашаешь. Тогда при вводе пароля тебе надо
Функцию надо не только "не разглашать", а именно "разглашать", а если средства позволяют - спонсировать поиск слабых мест, что бы всеумный all помог найти ошибки алгоритма.
Как все работает в PGP
Генериться случайных симетричный ключ, этим ключом и симметричным алгоритмом шифруется исходное сообщение. Этот ключь уже шифруется несиммитричным паблик ключом получателя и присоединяется к зашифрованному сообщению.
Из полученного сообщения выкусывается зашифрованный ключ и расшифровывается приват ключом получателя, а потом уже и само сообщение.
А проверка идентичности (правильности расшифровки) сообщения производится по CRC. Есть исходники PGP, программеры могут посмотреть и более точно осветить этот вопрос.
|
| | |
Ну просто по поводу Шеннона.. Как тебе такой шифр:... 02.06.04 21:46
Автор: Heller <Heller> Статус: Elderman
|
|
Ну просто по поводу Шеннона.. Как тебе такой шифр: Y=X+(K*0). Даже если K будет больше X - пофиг. Это конечно не шифр, но согласись, тут принципеален вопрос, можно ли выделять слово "ТОЛЬКО" заглавными..
|
| | | |
РЕ: Как тебе такой шифр:... 03.06.04 10:58
Автор: Garick <Yuriy> Статус: Elderman
|
Некоторые допущения:
1. Поиск правильного ключа возможен только путем прямого перебора (брутефорсе)
2. стойкость ключа - "расход" ресурсов (не важно каких- человеческих, материальных, временных)
3. ключ (ключевая информация) может быть не единственный(-ая)
> Ну просто по поводу Шеннона.. Как тебе такой шифр:
> Y=X+(K*0). Даже если K будет больше X - пофиг. Это конечно
> не шифр, но согласись, тут принципеален вопрос, можно ли
> выделять слово "ТОЛЬКО" заглавными..
любой К будет ключом (это и понятно:-)))) и его стойкость будет низкой...
соответсвенно "стойкость ключа является функцией от алгоритма и его реализации", но не от доступности/недоступности алгоритма. Это было доказано К. Шенноном в работах по теории информации. STFW.
ЗЫ: доступность/недоступность может увеличить или даже уменьшить стойкость, в зависимости от проффесиональности криптолога и криптоаналитика...
|
| | | |
Полагаю фраза была сокращенная. Следует добавить что-то... 02.06.04 22:53
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> не шифр, но согласись, тут принципеален вопрос, можно ли
> выделять слово "ТОЛЬКО" заглавными..
Полагаю фраза была сокращенная. Следует добавить что-то подобное: "..., при условии, что в алгоритме нет принципиальной ошибки.", тогда все от ключа и зависит. И слово "ТОЛЬКО" можно заглавными выделить, хотя это само собой разумеется.
|
| |
Лучше, все-таки, прочитать. Можно было бы сэкономить время... 02.06.04 14:56
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Заранее извиняюсь, если повторяю чей-то каммент, просто
> времени всё читать нет, а решение гарантированное
> подсказать могу.
Лучше, все-таки, прочитать. Можно было бы сэкономить время на написание поста.
> Просто пароль надо хранить отдельно в файле в зашифрованном
> виде. НО! Зашифрованном необратимой функцией (остаток от
> деления, например после каких-то преобразований). Саму
> функцию ты не разглашаешь. Тогда при вводе пароля тебе надо
> не расшифровывать пароль из файла, а зашифровывать
> введённый и сравнивать. Вот и всё, в общем-то.
Если это можно назвать хеш-преобразованием, то было, как, впрочем, и ЦРЦ.
> ЗЫ. А за риспект спасибо :-)
Да и вообще за недельку тут много полезных идей накидали - выбирай любой. Люсьен должна быть довольна.
|
| |
И ещё способ.. Если это не просто какие-то там файлы, а с... 02.06.04 14:52
Автор: Heller <Heller> Статус: Elderman
|
|
И ещё способ.. Если это не просто какие-то там файлы, а с вполне определёнными данными (например, текстом, числами и т. д.), ты можешь в случае не особо мудрёного алгоритма шифрования пытаться проверить, что у Тебя на выходе. Например, если алгоритм нужен для шифрования худ. лит. то вряд ли там встретятся управляющие символы.. Если же буквы шифруются в буквы - можешь попробовать организовать проверку с помощью тервера.
|
|
Привет!
02.06.04 01:06
Автор: Lexy Статус: Незарегистрированный пользователь
|
Привет!
В качестве примера можно взять описание шифрования в ZIP-архивах.
Идея очень проста - в файле хранится хеш, зависящий от пароля + случайных данных, которые хранятся там же (на самом деле это результат зашифрования случайных данных, из которых один или два предопределены). Он используется для быстрой проверки вводимого пароля (чтобы не расшифровывать гигабайты). Вероятность случайного совпадения очень мала. На случай, если все-таки совпадет, к файлу приписывается контрольная сумма (CRC32) от всего содержимого (расшифрованного). Т.о., если расшифровался мусор - CRC не сойдется.
Детали можно найти на www.info-zip.org
Где-то там же рядом есть исходники библиотеки, в которой все это реализовано.
Сам алгоритм имеет ряд недостатков, поэтому для серьезных систем защиты я бы его не рекомендовал. Но идею иллюстрирует вполне хорошо, быстрый, и очень простой в реализации.
В новых версиях появилось более стойкое шифрование (strong encryption). При желании можно и на него посмотреть :))
По поводу упоминавшегося коллегами Protected Storage - к сожалению, защита там не выдерживает никакой критики. Ломается "на раз" :)) Есть куча программ, это реализующих, ссылки приводить не буду, желающие найдут сами.
Успехов :))
|
|
А надо ли??? Иногда очень даже полезно выдавать именно то,... 24.05.04 11:14
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Вот тут, захотелось попрактиковаться в криптографии, типа
> шифрацию файлов написать.
> Вроде все просто, спрашиваем у юзверя пароль, вставляем его
> в алгоритм шифрования и понеслась.
> Вроде все ок, но вот как автоматизировать проверку пароля
> на правильность, а то получается белеберда, при
> расшифровке, если вести неправильный пароль то, прога
> выводит белетристику. Понятно что это из-за того что
> расшифровка проводится не на том ключе :((((
> В общем как отметать при неправильном вводе пароля?
А надо ли??? Иногда очень даже полезно выдавать именно то, что получилось.
> Первая мысль, хранить пароль в шифруемом файле? Но имхо,
> это не есть гут, его же оттуда достанут ?
Идея проста - после расшифровки проверить что получилось. Первый вариант в том случае, если шифруемые данные заведомо обладают какими-то свойствами, например сигнатурой в определенном месте или обладают свойством текста - все символы только буквы, знаки препинания, пробелы и при применении неправильного пароля на расшифровку гарантированно получатся непечатные символы, тогда после расшифровывания проверить это свойство. В противном случае нужно это свойство создать. Вариантов много: самый простой - приписать сигнатуру (в начало или в конец не важно, хоть в середину, главное знать где потом искать), состоящую, скажем, из наименование алгоритма, номера версии реализации, можно даже самого пароля - не страшно, но не желательно. Чуть посложнее - приписать ЦРЦ, поскольку его считать надо, проверять, опять же. Ну а после расшифровки проверить эту сигнатуру. Если все нормально - "выкусить" ее и направить расшифрованные данные куда надо. Ну а если сигнатура не совпала - значит пароль не подошел или шифровка была измененна, выдаем соответствующее сообщение об ошибке.
Есть еще вариант, который используется во многих упаковщиках - к шифровке приписывается хэш от пароля. При расшифровке проверяем хэш - если не совпал, то и расшифровывать не пытаемся. Стойкость всего метода шифрования будет складываться из стойкости хэша (если атака будет приходится на него) и метода шифрования данных.
|
|
Не надо никуда прятать 24.05.04 08:29
Автор: Slava_Verbov Статус: Незарегистрированный пользователь
|
|
Перед шифровкой вычислить CRC16 (или 32, по вкусу) файла, и дописать его к зашифрованному файлу. После расшифровки вычисляем CRC полученного файла, если совпадает с записанным, значит пароль с большой вероятностью верный.
|
| |
А если файл 10Г, как у Скрамдиска? 24.05.04 12:28
Автор: Zef <Alloo Zef> Статус: Elderman
|
> Перед шифровкой вычислить CRC16 (или 32, по вкусу) файла, и
> дописать его к зашифрованному файлу. После расшифровки
> вычисляем CRC полученного файла, если совпадает с
> записанным, значит пароль с большой вероятностью верный.
Скрамдиску проще: он расшифровывает FAT, и если полученное таковым не является - обламывается.
А если в файле может быть любая инфа?
|
| | |
Во во, какраз и интересно если файлы с произвольной информацией... 24.05.04 13:03
Автор: Lutien Статус: Незарегистрированный пользователь
|
> А если в файле может быть любая инфа?
Во во, какраз и интересно если файлы с произвольной информацией, может кто знает, как подобные задачи решают на практике всякие там рары, pgp, и прочие проги с шифрованием.
|
| | | |
Если шифрование блочное (с фикс. размером блока), то в самый раз... 25.05.04 07:51
Автор: HandleX <Александр М.> Статус: The Elderman
|
> Во во, какраз и интересно если файлы с произвольной
> информацией, может кто знает, как подобные задачи решают на
> практике всякие там рары, pgp, и прочие проги с
> шифрованием.
...пусть первый блок содержит в себе служебную информацию — в частности, пусть он содержит свою контрольную сумму (CRC). Для проверки правильности расшифровки достаточно расшифровать первый блок... Если crc корректна, то считаем, что пароль был правильный и поехали расшифровывать дальше.
Если шифрование поточное, то всё равно — в начале потока добавляешь служебку с информацией о crc, дальше всё тоже самое.
|
| | | | |
Сказали же: файл! Т.е. один блок известной длины. Тогда 25.05.04 11:50
Автор: Zef <Alloo Zef> Статус: Elderman
|
лучше всего "застеганографить" пароль в тело файла, что-нить по принципу:
Место_1го_Байта = mod(4_байта_Начиная_с_1го, Длина_Файла)
Место_2го_Байта = mod(4_байта_Начиная_сщ_2го, Длина_Файла)...
Тогда расшифровшику предстоит дабл-трабл: найти место и значение каждого байта, что нереально.
|
| | | | | |
А какая разница по каким байтам раскидывать пароль? А зачем... 25.05.04 13:48
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 25.05.04 13:49 Количество правок: 1
|
> лучше всего "застеганографить" пароль в тело файла,
> что-нить по принципу:
>
> Место_1го_Байта = mod(4_байта_Начиная_с_1го, Длина_Файла)
> Место_2го_Байта = mod(4_байта_Начиная_сщ_2го,
> Длина_Файла)...
>
> Тогда расшифровшику предстоит дабл-трабл: найти место и
> значение каждого байта, что нереально.
А какая разница по каким байтам раскидывать пароль? А зачем так сложно? А может просто приписать пароль в конец (начало), а за паролем (перед паролем, если он в начале) еще один байтик - его длина, чтоб просто его "выкусывать" потом.
|
| | | | | | |
Если я знаю, где пароль - я знаю пароль. 25.05.04 14:53
Автор: Zef <Alloo Zef> Статус: Elderman
|
> А какая разница по каким байтам раскидывать пароль? А зачем
> так сложно? А может просто приписать пароль в конец
> (начало), а за паролем (перед паролем, если он в начале)
> еще один байтик - его длина, чтоб просто его "выкусывать"
> потом.
Если я не знаю, где пароль - я не знаю его "в квадрате"
|
| | | | | | | |
Если место хранения пароля определено алгоритмом, то... 25.05.04 15:10
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 25.05.04 15:11 Количество правок: 1
|
> Если я не знаю, где пароль - я не знаю его "в квадрате"
Если место хранения пароля определено алгоритмом, то безразницы - будет ли он лежать в одном месте (начало/конец) или размазаным по контейнеру. Пароль, разумеется, следует инкапсулировать в исходные данные и проверять по нему корректность расшифровки, соответственно, после самой расшифровки.
Алгоритм шифрования должен быть достаточно стоек, чтобы даже зная где он храниться невозможно было его получить без расшифровки, а для этого надо знать сам пароль. То есть никаким методом, кроме как перебором всего множества паролей, невозможно расшифровать данные и убедиться в корректности сравнив его каждый раз с тем, что было вставлено в данные до из шифровки. В этом случае стойкость системы защиты информации не уменьшится от того, что перед шифрацией в данные вставляется сам пароль.
|
| | | | | | | | |
Балин! Место хранения пароля определяется самим паролем! 26.05.04 02:52
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
Точнее, не пароля, а каждого из его байтов. Зная пароль, алгоритм находит эти байты и сравнивает их с паролем. И весь файл расшифровывать не надо.
|
| | | | | | | | | |
Ну а в чем такая штука принципиально труднее для взлома... [upd] 26.05.04 03:35
Автор: Killer{R} <Dmitry> Статус: Elderman
Отредактировано 26.05.04 03:43 Количество правок: 2
|
Ну а в чем такая штука принципиально труднее для взлома нежели обычная зашифрованная строка?
Взломщик знает алгоритм нахождения байтов в файле по паролю. Те у него есть функция F(p) которая дает распределение наших данных (пароля) по файлу в зависимости от пароля (p)
Вот он берет и тупо перебирает это самое р находя данные согласно алгоритму
Принципиально не вижу никаких различий между расшифровкой пароля который размазан по файлу согласно какой то функции либо который записан одной строкой зашифрованной какй либо функцией
Разве что если сделать достаточно большой файл (>4Gb) который не влезет в память любого х86 компа, тогда перебор сильно замедлится засчет тормознутости винта
Кстати интересно было бы сделать такую систему криптования - имеем 2 разных алгоритма шифрования. А и Б, причем А абсолютно левопридуманный (те не имеет ключа, просто кусок кода преобразующий наши данные), а Б шифрует инфу по ключу. Шифруем при помощи алгоритма А наши данные. Затем шифруем при помощи Б код алгоритма А и зашифрованные данные. Поскольку А взлоищику неизвестен (скажем так сами его создатели придумали - и забыли) то ему надо будет последовательно перебирать ключи алгоритма Б, исполнять А, и проверять корректность данных "зашифрованных" при помощи исполнения алгоритма А... Вот тут то и будет %опа - так как надо как минимум делать эмулятор виртуальной машины чтобы неверно расшифрованный код А не похерил сам брутфорсер банальной записью в леву. область данных Ж\
|
|
|
подробно о проекте
Анализ криптографических сетевых...
