Подскажите, пожалуйста, наиболее простой алгоритм. Проще - лучше. К стойкости особых требований нет. Может что-нибудь из готового и простого в использовании.
Апи?
если кто увидит ошибки или че не так пишите замечания, плз
#include <memory>
#include <cmath>
#include <stdexcept>
#include <time.h>
#include <stdlib.h>
using namespace std;
UINT K(UINT t){
if ((0 <= t) && (t <= 19))
return 0x5A827999;
else if ((20 <= t) && (t <= 39))
return 0x6ED9EBA1;
else if ((40 <= t) && (t <= 59))
return 0x8F1BBCDC;
else if ((60 <= t) && (t <= 79))
return 0xCA62C1D6;
else
return 0;
}
UINT f(UINT t, UINT B, UINT C, UINT D){
if ((0 <= t) && (t <= 19))
return (B & C) | (!B & D);
else if ((20 <= t) && (t <= 39))
return B ^ C ^ D;
else if ((40 <= t) && (t <= 59))
return (B & C) | (B & D) | (C & D);
else if ((60 <= t) && (t <= 79))
return B ^ C ^ D;
else
return 0;
}
string SHA1(string input){
UINT H0, H1, H2, H3, H4;
UINT A, B, C, D, E;
ULONG size = input.size()*8;
ULONG N = size/512 + (((size%512)>448)?2:1);
UINT i, t, s, temp;
UINT MASK = 0x0F;
struct blocks {
UINT W[16];
} *M;
M = new blocks[N];
memset(M,0,N*sizeof(blocks));
memcpy(M, input.data(), input.size());
memcpy(&M[N-1].W[14], &size, sizeof(size));
H0 = 0x67452301;
H1 = 0xEFCDAB89;
H2 = 0x98BADCFE;
H3 = 0x10325476;
H4 = 0xC3D2E1F0;
for(i = 0; i<N; i++) {
A = H0; B = H1; C = H2; D = H3; E = H4;
for (t=0; t<80; t++)
{
s = t & MASK;
if (t >= 16)
M[i].W[s] = _rotl((M[i].W[(s + 13) & MASK] ^ M[i].W[(s + 8) & MASK] ^ M[i].W[(s + 2) & MASK] ^ M[i].W[s]),1);
temp = _rotl(A,5) + f(t, B, C, D) + E + M[i].W[s] + K(t);
E = D; D = C; C = _rotl(B, 30); B = A; A = temp;
}
H0 += A; H1 += B; H2 += C; H3 += D; H4 += E;
}
delete[] M;
char buf[41]; sprintf(buf, "%0x%0x%0x%0x%0x",H0, H1, H2, H3, H4);
return string(buf);
}
---
Ну если алгоритм, а не библиотечную функцию, то единственный...02.12.05 11:11 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 02.12.05 11:18 Количество правок: 3
> Подскажите, пожалуйста, наиболее простой алгоритм. Проще -
Ну если алгоритм, а не библиотечную функцию, то единственный простой, надежный, логичный алгоритм, это зашифровать пароль, используя в качестве ключа сам пароль (можно выполнив над ним какие-либо преобразования, для адаптации к размеру ключа). Причем, поскольку пароль достаточно короткий, сжимать его самого для использования в качестве данных для щифрования нет необходимости, а для ключа может потребуется. Вполне достаточно использовать симметричный алгоритм, но можно и с открытым ключем, тогда открытый ключ уж точно надо получать некоторыми преобразованиями пароля.
Доказать стойкость несложно. Чтобы расщифровать - нужен ключ, а ключ - сам пароль, а его мы не знаем. Он есть, но зашифрован стойким алгоритмом. Ключ был пароль или получен известным образом из пароля и "забыт" или уничтожен.
Из определения стойкости алгоритма шифрования - для получения пароля (расшифровывание зашифрованного пароля или получения ключа) обязательно нужно знать ключ.
В принципе можно и шифровать известные данные, опять же используя в качестве ключа пароль или его производную.
> лучше. К стойкости особых требований нет. Может что-нибудь > из готового и простого в использовании. > Апи? > > Спасибо.
Спасибо, за частичную ликвидацию моей неграмотности в этих...03.12.05 04:17 Автор: void <Grebnev Valery> Статус: Elderman
> > Подскажите, пожалуйста, наиболее простой алгоритм. > Проще - > > Ну если алгоритм, а не библиотечную функцию, то > единственный простой, надежный, логичный алгоритм, это > зашифровать пароль, используя в качестве ключа сам пароль > (можно выполнив над ним какие-либо преобразования, для > адаптации к размеру ключа). Причем, поскольку пароль > достаточно короткий, сжимать его самого для использования в > качестве данных для щифрования нет необходимости, а для > ключа может потребуется. Вполне достаточно использовать > симметричный алгоритм, но можно и с открытым ключем, тогда > открытый ключ уж точно надо получать некоторыми > преобразованиями пароля. > Доказать стойкость несложно. Чтобы расщифровать - нужен > ключ, а ключ - сам пароль, а его мы не знаем. Он есть, но > зашифрован стойким алгоритмом. Ключ был пароль или получен > известным образом из пароля и "забыт" или уничтожен. > Из определения стойкости алгоритма шифрования - для > получения пароля (расшифровывание зашифрованного пароля или > получения ключа) обязательно нужно знать ключ. > В принципе можно и шифровать известные данные, опять же > используя в качестве ключа пароль или его производную. > > > лучше. К стойкости особых требований нет. Может > что-нибудь > > из готового и простого в использовании. > > Апи? > > > > Спасибо. Спасибо, за частичную ликвидацию моей неграмотности в этих вопросах. Идея хорошая. Я так её и представлял. Правда весьма смутно. Но вот Вы подсказали про то, что самое разумное в качестве ключа использовать сам пароль! Думаю, так и надо делать.
Спасибо.
Надеюсь без сарказма :-).05.12.05 13:52 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> Спасибо, за частичную ликвидацию моей неграмотности в этих
Надеюсь без сарказма :-).
Я просто ну услеживаю за уровнем и специализацией форумян. Кто-то может обидется от наличия во вступлении "пописных истин". Я считаю, что на всякий случай, чтобы расставить все точки над ё следует начать с определений.
> вопросах. Идея хорошая. Я так её и представлял. Правда > весьма смутно. Но вот Вы подсказали про то, что самое > разумное в качестве ключа использовать сам пароль! Думаю, > так и надо делать.
Поскольку корифеи меня не поправили, видимо хеш таким образом получить можно.
Наверняка для этого есть и более простые, быстрые, стандартные алгоритмы.
Я знаю, что отыскать описание и реализовать его несколько сложнее, чем воспользоваться готовой шифровалкой.
> Спасибо.
Мне думается, что интересно будет обсуждение нужности/полезности/смысла хеша пароля.
Это понятно, что в открытом виде хранить пароли, которые все могут посмотреть нелогично.
Понятно так же, что имея хеш нельзя (кроме как перебором) получить пароль.
Непонятна грань между "хеш выкладываем на всеобщее обозрение" и "если никто не увидит хеш, почему бы тогда и не хранить пароль незахешированным".
Пароль должны храниться еще более защищено, чем данные, к которым они регулируют доступ. Если кто-то стырил пароль, то уж данные ему стырить/изменить будет еще проще.
Где эта грань?
Если она на столько узка, то нужен ли хеш?
Кстати насчет шифрования пароля этим же паролем...05.12.05 15:08 Автор: whiletrue <Роман> Статус: Elderman Отредактировано 05.12.05 15:10 Количество правок: 1
> Если делать гаммирование, то получится тривиальный случай > a xor a = 0! > > т.е. под это подпадает любой пароль! не факт, что какой-то > другой алгоритм не выдаст такую тривиальность
Это понятно, что это специфичный случай. С ним нужно работать отдельно.
Самый простой и гарантированно рабочий, это все-таки шифровать постоянный текст использую пароль в качестве ключа.
> > Если делать гаммирование, то получится тривиальный > случай > > a xor a = 0! > > > > т.е. под это подпадает любой пароль! не факт, что > какой-то > > другой алгоритм не выдаст такую тривиальность > > Это понятно, что это специфичный случай. С ним нужно > работать отдельно. > Самый простой и гарантированно рабочий, это все-таки > шифровать постоянный текст использую пароль в качестве > ключа.
сабж
Но это я так понимаю - считается не очень стойким хэшированием... корреляция между ключом и сообщением - 100%, шифр обычно блочный - можно там извращаться проходя не все раунды, находя корреляцию после неполного шифрования... короче анализировать надо. Имхо, шифрование DES-ом с тем же паролем (как в Линукс) - не очень хорошая идея, хотя если требования к стойкости не велики...
Можно ж просто SHA1 реализовать - там он простой, вроде..
Какая стойкость нужна, пользоваться чем-то стандартным или...05.12.05 16:08 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 05.12.05 16:19 Количество правок: 3
> Но это я так понимаю - считается не очень стойким
Какая стойкость нужна, пользоваться чем-то стандартным или нестандартным и пр. пусть Валерий решает.
Мне бы хоелось заострить внимание не на то хорошо ли это или нет, стОит ли доверять Линуксовым реализациям или нет, а на том, нужен ли вообще хеш пароля. Хранить просто пароли. Одно дело страшновато. С другой стороны сознание того, что их нужно оберегать не даст расслабиться.
> хэшированием... корреляция между ключом и сообщением - > 100%, шифр обычно блочный - можно там извращаться проходя > не все раунды, находя корреляцию после неполного > шифрования... короче анализировать надо. Имхо, шифрование > DES-ом с тем же паролем (как в Линукс) - не очень хорошая > идея, хотя если требования к стойкости не велики...
Разве они там пароль на пароле шифруют. Мне помнилось, что они псевдослучайную гамму паролем шифруют. Коллизий в этом случае не будет, но ибыточность появляется - объем хеша увеличивается, поскольку он уже состоит и из гаммы и из ее шифра.
> Можно ж просто SHA1 реализовать - там он простой, вроде..
Я сначала не правильно понял твою идею, сорри05.12.05 16:41 Автор: whiletrue <Роман> Статус: Elderman Отредактировано 05.12.05 16:45 Количество правок: 1
> Разве они там пароль на пароле шифруют. Мне помнилось, что > они псевдослучайную гамму паролем шифруют. Коллизий в этом > случае не будет, но ибыточность появляется - объем хеша > увеличивается, поскольку он уже состоит и из гаммы и из ее > шифра.
сабж
Мда, тогда все чики-пики - стандартная задача криптоанализа: есть шифр, есть открытое сообщение, известен алгоритм - неизвестен ключ... тогда согласен - все будет зависетьтолькоот стойкости выбранного алгоритма ширования
Как раз сначала я и упоминал о шифровании пароля на пароле...05.12.05 16:52 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> Мда, тогда все чики-пики - стандартная задача > криптоанализа: есть шифр, есть открытое сообщение, известен > алгоритм - неизвестен ключ... тогда согласен - все будет > зависетьтолькоот стойкости выбранного алгоритма > ширования
Как раз сначала я и упоминал о шифровании пароля на пароле. Собственно главное, чтоб пароль выступал в роли ключа. Если же в качестве открытого сообщения тоже пароль брать, то не надо его хранить дополнительно. Сложнее реализация, понятно, но наверняка возможна. Насколько стойка - только споры. Можно доказать стойкость или ее отсутствие, вполне. Тогда, соответственно, пользуем или нет.
> Если же в качестве открытого сообщения тоже пароль брать, то не > надо его хранить дополнительно. Сложнее реализация, > понятно, но наверняка возможна. Насколько стойка - только > споры. Можно доказать стойкость или ее отсутствие, вполне. > Тогда, соответственно, пользуем или нет.
Хм.. а ведь блочный хэш типа SHA1 или MD5 - это и есть шифрование сообщения самим сообщением... просто следующий блок, грубо говоря, шифруется предыдущим блоком
А первый блок чем? А если блок всего один?05.12.05 18:38 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 05.12.05 18:39 Количество правок: 2
> Хм.. а ведь блочный хэш типа SHA1 или MD5 - это и есть > шифрование сообщения самим сообщением... просто следующий > блок, грубо говоря, шифруется предыдущим блоком
А первый блок чем? А если блок всего один?
Что-то я задумался на тему "как правильно шифрануть пароль паролем, таким образом получить хеш, если одним из первых шагов шифрования является наложение гаммы (XOR)"? Как коллизий избежать?
А блок не может быть один =)05.12.05 19:07 Автор: whiletrue <Роман> Статус: Elderman Отредактировано 05.12.05 19:25 Количество правок: 1
> > Хм.. а ведь блочный хэш типа SHA1 или MD5 - это и есть > > шифрование сообщения самим сообщением... просто > следующий > > блок, грубо говоря, шифруется предыдущим блоком > > А первый блок чем? А если блок всего один? > Что-то я задумался на тему "как правильно шифрануть пароль > паролем, таким образом получить хеш, если одним из первых > шагов шифрования является наложение гаммы (XOR)"? Как > коллизий избежать?
сабж
ну вот в SHA1 - блок разделен на 16 подблоков, последний блок обязательно выравнивается (добивается 0-ми), и вконец последнего блока записывается длина сообщения (если бы ее не было, то там сильно стойкость страдала, на сколько я помню). Т.е. если короткое сообщение, то будет один блок, в котором в начале сообщение, потом много 0-й, и в конце длина.
Ну и делаются операции над подблоками, а если есть еще блоки то их хэш просто суммируется к уже полученному... но стойкое преобразование - внутри операций над подблоками.
Т.е., короткое сообщение как бы "размажется" по хэшу, и вроде как это преобразование будет стойким... все зависит от того как там все перемешивается внутри блока...
Да я не про SHA1, а вообще. И про один блок, поскольку пароли обычно в пределах 8 байт, а алгоритм 64 битный минимум.05.12.05 19:29 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Очевидно, надо как-то также поступить... выровнять нулями, добавить длину в конец и перемешать по блочно - чем перемешивать и какую длину блока взять, уже другой вопрос - взять ли уже придуманную функцию или изобрести свою...
[MSDN] Если не используется .NET02.12.05 06:16 Автор: catlion <catlion> Статус: Member Отредактировано 02.12.05 06:17 Количество правок: 1
Parameters pbData - [in] Pointer to the data array.
cbData - [in] Number of elements in pbData.
pbHash - [out] Value used to return the hashed array.
cbHash - [in] Number of elements in pbHash. It should be no larger than 256.
Return Value Returns S_OK if successful, or a standard OLE error value otherwise.
Если есть возможность использовать .NET, то там есть классы Hash, DES, MD5.
Спасибо. Посмотрю .NET, т.к. сейчас в C# проект. Надо...03.12.05 04:13 Автор: void <Grebnev Valery> Статус: Elderman
> #include <shlwapi.h> > > HRESULT HashData( LPBYTE pbData, > DWORD cbData, > LPBYTE pbHash, > DWORD cbHash > ); > > Parameters > pbData - [in] Pointer to the data array. > cbData - [in] Number of elements in pbData. > pbHash - [out] Value used to return the hashed array. > cbHash - [in] Number of elements in pbHash. It should be no > larger than 256. > > Return Value > Returns S_OK if successful, or a standard OLE error value > otherwise. > > Если есть возможность использовать .NET, то там есть классы > Hash, DES, MD5. Спасибо. Посмотрю .NET, т.к. сейчас в C# проект. Надо сделать быстро, чтобы не выгнали с работы. Потом покопаю, то что Вы сказали про апи.