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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ну если алгоритм, а не библиотечную функцию, то единственный... 02.12.05 11:11  Число просмотров: 1582
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 02.12.05 11:18  Количество правок: 3
<"чистая" ссылка> <обсуждение закрыто>
> Подскажите, пожалуйста, наиболее простой алгоритм. Проще -

Ну если алгоритм, а не библиотечную функцию, то единственный простой, надежный, логичный алгоритм, это зашифровать пароль, используя в качестве ключа сам пароль (можно выполнив над ним какие-либо преобразования, для адаптации к размеру ключа). Причем, поскольку пароль достаточно короткий, сжимать его самого для использования в качестве данных для щифрования нет необходимости, а для ключа может потребуется. Вполне достаточно использовать симметричный алгоритм, но можно и с открытым ключем, тогда открытый ключ уж точно надо получать некоторыми преобразованиями пароля.
Доказать стойкость несложно. Чтобы расщифровать - нужен ключ, а ключ - сам пароль, а его мы не знаем. Он есть, но зашифрован стойким алгоритмом. Ключ был пароль или получен известным образом из пароля и "забыт" или уничтожен.
Из определения стойкости алгоритма шифрования - для получения пароля (расшифровывание зашифрованного пароля или получения ключа) обязательно нужно знать ключ.
В принципе можно и шифровать известные данные, опять же используя в качестве ключа пароль или его производную.

> лучше. К стойкости особых требований нет. Может что-нибудь
> из готового и простого в использовании.
> Апи?
>
> Спасибо.
<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-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach