информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вобщем-то, вроде, Линукс так делает... 05.12.05 15:33  Число просмотров: 1489
Автор: whiletrue <Роман> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > Если делать гаммирование, то получится тривиальный
> случай
> > a xor a = 0!
> >
> > т.е. под это подпадает любой пароль! не факт, что
> какой-то
> > другой алгоритм не выдаст такую тривиальность
>
> Это понятно, что это специфичный случай. С ним нужно
> работать отдельно.
> Самый простой и гарантированно рабочий, это все-таки
> шифровать постоянный текст использую пароль в качестве
> ключа.

сабж

Но это я так понимаю - считается не очень стойким хэшированием... корреляция между ключом и сообщением - 100%, шифр обычно блочный - можно там извращаться проходя не все раунды, находя корреляцию после неполного шифрования... короче анализировать надо. Имхо, шифрование DES-ом с тем же паролем (как в Линукс) - не очень хорошая идея, хотя если требования к стойкости не велики...

Можно ж просто SHA1 реализовать - там он простой, вроде..
<programming>
[C++] Хэш пароля 02.12.05 04:46  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Подскажите, пожалуйста, наиболее простой алгоритм. Проще - лучше. К стойкости особых требований нет. Может что-нибудь из готового и простого в использовании.
Апи?

Спасибо.
Реализуй sha-1 04.12.05 20:36  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 04.12.05 20:37  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
я тут писал реализацию...

если кто увидит ошибки или че не так пишите замечания, плз
#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!

т.е. под это подпадает любой пароль! не факт, что какой-то другой алгоритм не выдаст такую тривиальность - это надо серьезно исследовать, имхо
Это понятно, что это специфичный случай. С ним нужно... 05.12.05 15:15  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Если делать гаммирование, то получится тривиальный случай
> a xor a = 0!
>
> т.е. под это подпадает любой пароль! не факт, что какой-то
> другой алгоритм не выдаст такую тривиальность

Это понятно, что это специфичный случай. С ним нужно работать отдельно.
Самый простой и гарантированно рабочий, это все-таки шифровать постоянный текст использую пароль в качестве ключа.
Вобщем-то, вроде, Линукс так делает... 05.12.05 15:33  
Автор: whiletrue <Роман> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> > Если делать гаммирование, то получится тривиальный
> случай
> > 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
<"чистая" ссылка> <обсуждение закрыто>
> Мда, тогда все чики-пики - стандартная задача
> криптоанализа: есть шифр, есть открытое сообщение, известен
> алгоритм - неизвестен ключ... тогда согласен - все будет
> зависетьтолькоот стойкости выбранного алгоритма
> ширования

Как раз сначала я и упоминал о шифровании пароля на пароле. Собственно главное, чтоб пароль выступал в роли ключа. Если же в качестве открытого сообщения тоже пароль брать, то не надо его хранить дополнительно. Сложнее реализация, понятно, но наверняка возможна. Насколько стойка - только споры. Можно доказать стойкость или ее отсутствие, вполне. Тогда, соответственно, пользуем или нет.
Хм.. 05.12.05 18:21  
Автор: whiletrue <Роман> Статус: 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-й, и в конце длина.

Плюс используются некие начальные значения (типа хэш 0-го блока):
H0 = 0x67452301;
H1 = 0xEFCDAB89;
H2 = 0x98BADCFE;
H3 = 0x10325476;
H4 = 0xC3D2E1F0;

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

Т.е., короткое сообщение как бы "размажется" по хэшу, и вроде как это преобразование будет стойким... все зависит от того как там все перемешивается внутри блока...
Да я не про SHA1, а вообще. И про один блок, поскольку пароли обычно в пределах 8 байт, а алгоритм 64 битный минимум. 05.12.05 19:29  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Да я пример привел... 05.12.05 19:32  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 05.12.05 19:39  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
Очевидно, надо как-то также поступить... выровнять нулями, добавить длину в конец и перемешать по блочно - чем перемешивать и какую длину блока взять, уже другой вопрос - взять ли уже придуманную функцию или изобрести свою...
[MSDN] Если не используется .NET 02.12.05 06:16  
Автор: catlion <catlion> Статус: Member
Отредактировано 02.12.05 06:17  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
#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# проект. Надо... 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# проект. Надо сделать быстро, чтобы не выгнали с работы. Потом покопаю, то что Вы сказали про апи.
1




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


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach