Появилась какая-то псевдопроблема с пересылкой информации для установления защищенного соединения. Вообщем, как мне наиболее безболезненно послать пароль по сети серверу. Не в чистом ведь виде ?
Есть ли альтернатива ssh/ssl ?
тема частично родилась из http://forum.vingrad.ru/topic-132676/unrea...ml#entry1004118

А чем тебе ssh/ssl не нравится?

Отправляй не пароль, а какие-либо данные, шифрованные этим паролем.
Если расшифруются корректно - значит пароль верный.
Или, как это сделато в SSL - устанавливаешь соединение с открытым ключём, отправляешь пароль, после чего переходишь на потоковое шифрование.

Кста они используют Diffie-Hellmann http://ru.wikipedia.org/wiki/%D0%90%D0%BB%...%B0%D0%BD%D0%B0

Snowy, 

Была мысль шифровать какой-то кусок служебной информации на одном конце(сервере) хешем пароля пользователя. На другом конце препологалось отправлять шифрованный своим паролем тот же кусок информации(клиенте). В чём здесь подводные камни ?

Добавлено @ 16:10 
Упс. Если хеши паролей станут известны, а такое может быть, то и вся эта операция выше становиться бесмысленной. Защита раскручивается сверху вниз.

А зачем свой пароль?
Пароль известен обоим.
Не нужно его слать - просто использовать его для шифрования сессии и всё.

Snowy, 
нет серверу пароль неизвестен и так должно быть.

Продублирую пост, коли уж обсуждение продолжается в этой ветке, надеюсь ничего не нарушу

Очень хорошо эти моменты рассмотрены у Шнайера, в его прикладной криптографии. 




Для этого случая может быть использована криптография с открытыми ключами, в частности ассиметричный алгоритм шифрования RSA. Предварительно ты должен согласовать передачу публичного ключа одной стороне, которая будет передавать пароль на сервер. Далее следует такая схема:

1. Перед передачей пароля он шифруется публичным ключом пользователя.
2. Зашифрованный текст передаётся на сервер.
3. Предпринимается попытка расшифровать пароль приватным ключом.
4. Берётся хеш от пароля и сравнивается с хешем из базы.

Если пароль будет перехвачен на 2 стадии, то злоумышленник никак не сможет расшифровать данные не зная приватного ключа(а он известен только тебе). Если он попытается подменить данные, то 4 пункт не будет успешно выполнен.

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

Кстати, в качестве хеш-функции используй SHA. MD5 уже признан ненадёжным алгоритмом и существуют успешные атаки. 



Это сообщение отредактировал(а) W4FhLF - 19.1.2007, 16:28

Желательно также посолить.
Причём соль не должна повторяться.
Например солить миллисекундами.
Сервер должен запоминать некоторое кол-во предыдущих солей, чтобы исключить возможность записи/воспроизведения сеанса.

Добавлено @ 16:16 
Но известен хэш.
Используй его в качестве ключа.

Это большое недоразумение в общем случае (как я уже выше описал). Один человек нашёл один способ чтото сломать и  все уже кричат "ненадёжно" нез тоог, чтобы посмотреть КАК работает алгоритм "ломания". Пару простых проверок сделают мд5 хэш "достаточно надёжным для хранения паролей. 

Для подписи в общем виде, действительно мд5 не надёжный, так как длина подписанного документа не ограничена. Но SHA к сожалению тоже не панацея и её ломали. На данный момент насколько я знаю не существует 100% защиты. Поэтому приходится помогать себе самому. Например сравнивая не только хэш, но и длину подписанного сообщения.



Хэшь может быть известен нападающему, так как он хранится в базе на сервере и может быть украден.


Ты читал по ссылке про Диффи-Хельман?

Не хочатеся тратить много времени на описание того, как работает ssh (и почему ты его не берёшь, ты так и не сказал. Ведь достаточно пару либ подлючить и вуаля!), но видимо придётся...

Дано:
Сервер А
Клиент Б

• А имеет открыты/закрытый ключи. Открытый известен всем, закрытый только А
• Б посылает на А рандомную мессагу с просьбой подписать её, случайное число r, которое будет базисом для Хельмана и простое число p, для арифметики по модулю. r и p можно передавать в открытую. r должно быть первообразным корнем p.
• А подписывает мессагу приватным ключём.
• Таким образом Б, сверяя подпись открытым ключём от А, узнает, что действительно общается с А, а не с каким нибудь врагом "Жё" 

Дальше -Хельман (знак ^здесь означает степень)

• A генерирует случайное натуральное число aх - закрытый ключ и генерит открытый ключ ay по формуле ay=r^ax mod p
• Также Б генерит ключи bx и by 
• Стороны обмениваются ключами ay,by
• Вычисляют общий секретный ключ K, используя открытый ключ удаленной стороны и свой закрытый по формуле: К= ay^bx mod p (для Б) и K=by^ax mod p (для А).
• Ключи равны, потому что смотри википедию.

Этим ключём и шифруется всё остальное общение.

Можешь имплементить это сам, но я бы либу заюзал 

(в принципе там немного, но вот найти большие простые числа и работать сними самому - лишние заморочки)

А лучший алгоритм ты вряд ли придумаешь. Над этим большие умы работали и чуть нобеля не получили!

Да ясное дело, что криптоаналитиков, которые могут подвергнуть хеш-функцию анализу довольно мало. Но то, что MD5 признан не устойчивым - это официальная информация, которая опубликовывалась уже больше года назад, источников не припомню, но легко можно найти. Точно так же есть факты подтверждающие наличие коллизий и заявление это было сделано не кем-то там-то, а процессором Китайского института, правда описания нет(оно и понятно, кто такую бомбу выложить захочет). Шнайер кстати в своей книге тоже сказал, что относится настороженно к этой хеш-функции. Дело-то ещё в том, что md5 очень распространён, это делает его использование более уязвимым.

А когда это SHA ломали? Об успешных атаках на этот алгоритм нигде даже не упоминалось. Я надеюсь, простой перебор ты не считаей атакой на алгоритм. SHA является частью стандарта DSA, а этот алгоритм используется в  военных ведомствах США, поэтому если кто-то из твоих знакомых успешно взломал SHA, то пусть заляжет на дно

Если есть заимплементованный алгоритм, это может сделать любой.


Думаешь, почему переполоха не случилось, когда о неустойчивости узнали? Потому что она именно в общем случае, а для частных с ней можно бороться. 


Лучше надо информироваться  Вот описание: http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf
А вот прямая ссылка на исходник  http://www.stachliu.com/md5coll.c



Ёлки, я конечно понимаю, что всё подряд человек прочитать не может, но если я упомянул об этом, можно ведь хотя бы гугль попробовать напрячь 

http://www.schneier.com/blog/archives/2005...ha1_broken.html
http://ru.wikipedia.org/wiki/SHA-1

Ну и об оставшихся системах хеширования:


И никто на дне лежит, потому что этот "взлом" не даст практически ничего по вышеописанным причинам.

Да это описание и исходник мне известны, уже давно, я же говорил, что это было заявление китайского криптоаналитика. Ещё один камень в сторону MD5, кстати  Правда заставить работать эту программу под виндой мне не удалось.



Зря ты меня в гугл отправляешь, то, что ты показал не является взломом алгоритма как таковым. Отрицать то, что SHA более надёжнее MD5 глупо, это же очевидно, хотя бы исходя из реализации и длины хеша.



Да причём здесь это, дело совсем в других факторах. Фундаментальные знания в этой области, определённые вычислительные мощности, материальные возможности и наличие времени. 




Переполоха не случилось потому, что данные были довольно косвенные. Очевидно, что использование MD5 в некоторой схеме в частном случае делает её надёжнее, я этого нигде не отрицал, я лишь утверждаю, что SHA является более стойкой хеш-функцией и посоветовал её, ты на меня накинулся и вцепился зубами в этот md5  Ради Бога, право выбора за автором темы.

sergejzr, 

А что если просто составить словарь из простых чисел ? Мегабайт 100 могу в ОЗУ под них выделить...

Добавлено @ 19:26 

Я не могу найти "простую" либу, использующую данный алгоритм. Может подскажешь другие реализации кроме ssh ?

Добавлено @ 19:28 

просто мне бы крайне не хотелось связываться с GPL, а тем более частными лицензиями.

Так же как и коллизия взломом по сути не является. Какая разница, если оба метода сами по себе никуда не годятся?  А в гугль отправил, потому что ты написал "Об успешных атаках на этот алгоритм нигде даже не упоминалось." Когда это даже в википедии написано.

Притом, что защита не только в алгоритме, но и подходе программиста к вопросу. На алг надейся, а сам не плошай, тогда и коллизии не страшны.

Извиняюсь, если это действительно выглядело так  Просто голословные утверждения не нравятся. Почему я должен выискивать ссылки на информацию, которую мне другие пытаются пытаются доказать? В общем сорри, если случайно зубы почуствовал, постараюсь впредь полегче быть 


А как раз я игрался с ней. пожалуйста, можешь попробовать. (только плз не распространяйте прогу направо и на лево).
пасс: molokoslo

Добавлено @ 19:33 

возможно ты не понимаешь, о каких размерах чиесл здесь идёт речь. простого int будет маловато, а с бОльшими числами очень тяжело работать.
http://www.openssl.org/

Самый стандарт сейчас. Насчёт лицензий - не знаю, насколько они тебя ограничат.

Присоединённый файл ( Кол-во скачиваний: 10 )
 md5coll.zip 11,69 Kb

Кто-нибудь может объяснить, всё же, смогу ли я продавать программу использующую OpenSSl ? А то я не очень силён в тонкостях англ. языка 

Ну всё-таки наличие коллизии является непосредственным взломом отдельно взятого хеша. Да какая это атака, пару слов о непонятном методе, я считаю это не назовёшь успешной атакой. 



Я говорю о том, что грамотных криптоаналитиков, способных подвергнуть фундаментальному анализу серьёзные алгоритмы, в мире не так много, а ты мне про подход



Ну компилировать я слава Богу пока не разучился, скомпилировать и заставить работать разные вещи Или у тебя получилось найти коллизию к какому-нибудь хешу?
PS: http://www.securitylab.ru/software/232876.php
Сам не качал, нет возможности проверить, поэтому насчёт работоспособности ничего сказать не могу, но учитывая статус ресурса стоит задуматься

ссылка дохлая

ХЫ-ХЫ-ХЫ долго ржал, все дружно идем сюда:
http://www.aisys.ru/mdcrack/

Добавлено @ 21:40 
W4FhLF, 

Это обычный переборщик. И как правильно заметил товарищ(если нажать "прикинуть")
 по ссылке http://www.aisys.ru/mdcrack/ то в среднем при средних условиях это займет столько времени, что "Даже если начать прямо сейчас, то хрена мы дождемся...".

En_t_end, ну, написано, что якобы коллизии ищет, поэтому я и обратил внимание. Не написали бы они это просто так?

Ну в целом, конечно оно можно, но этож надо каждый раз генерировать такие большие простые числа. 



Эт схема мне больше симпотизирует, однако, для дальнейшего обмена по закрытому каналу лучше сгенерировать сессионый ключ для какого-нибудь симметричного алгоритма. Асимметричное шифрование (с откртым ключом) очень ресурсоемко, так что обычно с его помощью передают сессионый ключ для симметричного шифрования и далее уже обмен идет с помощью сим. алгоритма.



Видимо это и имел ввиду Snowy, тока вот потоковое-надо на симметричное заменить. (Потоковое шифрование может быть и асимметричным, впринципе любой блочный алгоритм, можно легко использовать для потокового шифрования)
На мой взгляд данный метод лучше Хельман: на клиенте не надо постоянно генерировать большие простые числа для ключей, а на сервере подобные ключи можно генерировать раз в пол года и затем постоянно использовать один и тот же ключ. 



Эт точно, чтоб написать библиотеку работы с большими числами - уйдет много свободного вермени, проще использовать уже готовые открытые реализации.
А вот поиск больших чисел - это простите не от программиста зависит, он не должен писать какой-то сверхумдренный алгоритм их поиска. Просто случайно генерируются числа и проверяются на простоту каким-нибудь полиноминальным алгоритмом. Единственно, что можно сделать, чтобы теоретически ускорить поиск в 2 раза - это менять последний бит на 1, чтоб числа были нечетными.


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


PS. По-моему уже давно пора создать специализированный раздел форума для подобных тем, думаю, мало кому в голову придет искать подобные темы в разделе Технологии защиты программного обеспечения.

Пароль есть небольшой объём информации и передаётся он один раз за сессию. Если каждый раз не генерировать ключи, а использовать готовые, то ресурсов тут будет требоваться не больше, чем для симметричного. 




Да не, помнится, когда было опубликовано это сообщение кто-то даже примеры коллизионных хешей приводил, была выложена md5coll.c которая под вендой ни у кого не пахала, но говорили, что под никсами на приличной машине люди за 2 часа находили коллизию к хешу. Потом ещё одна статья вышла описывающая способ взлома md5 за 8 часов, после ещё несколько публикаций о уязвимостях. Было это уже больше полутора лет назад, поэтому я забыл подробности. 

 Ну как то я не думаю, что будет переслан только один пароль к чему это?

Alexandr87, 

На данный момент мне нужно лишь передать пароль таким образом, чтобы его не заснифили. Дальнейший обмен я по видимому буду вести через потоковые алгоритмы.
ЗЫ блин, уже голова болит. Мне надо каким-то образом заюзать Хельмана, но не ввязываясь в авантюры с лицензиями. Может есть где-то в сети любительские реализации Хельмана ? вместе с решенным вопросом генерации больших простых чисел.

Про это и разговор - перечитайте еще раз посты. Разговор, как раз про то, чтобы передать сессионый ключ для, как вы говорите, "потокового" алгоритма.

Добавлено @ 12:57 
Не заморачивайтесь с Хельманом - используйте SSL. На мой взгляд - использование Хульмана в данной ситуации избыточно, или тогда нужно вообще пересмотреть систему аутентификации и построить её на открытых ключах, тогда впринципе волнение, что пароли будут сперты с сервера проподет.




Это сообщение отредактировал(а) Alexandr87 - 20.1.2007, 13:11

Единственные заморочки там с  p и r, а они открытые(т.е одного раза их достаточно сгенерить на всё жизнь). Остальные - обыкновенные интегеры.


В России насколъко я знаю вообще такая криптография вообще запрещена  законом  


Нет, это можно сделать, чтобы ускорить поиск практически, дополнительно можно не рассматривать числа менъше корня числа. А для теории, также применяемой на практике,  существует множество быстрых способов определения, что число НЕ простое (эх, криптографией уже года с 2 не занимался , а то бы побольше рассказал там Якоби, Эйлер итд.). Этими способами отсекается куча мусора. К тому же простые числа встречаются довольно часто даже оооочень большие. Это теорема и она не доказана(это как раз повод получить Нобеля).

sergejzr, 

Т.е. каким это образом ?

Добавлено @ 15:37 

Как же тогда https'ы в России, работающие через SSL, в котором этот алгоритм(там он называется DH) реализован ?

Мне тоже интересно  В подробности законодательства РФ я не вникал, но погуглил немного.


То есть спецслужбы хотят иметь все ключи. ИМХО - полный маразм.

Кстати, помоему, Нобелевскую Премию не дают за математику...

En_t_end, почитай про Эйлера. Великий математик он так же работал в областях физики, механики, астрономии итд. Математика  - одно дело, её применение - другое.

ИМХО, надо бы за такую фигню подать в жалобу в Мжд. Суд По Правам Человека, ибо нефиг. Интересно, почему тогда не пресуют PGP'шников ?
Отсюда вообще следует, что в России запрещается использовать какие-либо "стойкие" алгоритмы, ибо под определение "сильной защиты" они то как раз и относятся 

Добавлено @ 15:56 
sergejzr, 
Я имел ввиду чистую математику, как то простые числа.

Добавлено @ 16:07 
sergejzr, спасибо за информацию, я этого вообще не знал. Прочитал документ по твоей ссылке и был неприятно удивлен.

Это сообщение отредактировал(а) En_t_end - 20.1.2007, 15:55

таким образом возникает еще одна проблема - их хранение на клиенте. Если же использовать второй алгоритм - такой проблемы просто нет.


Всмысле не рассматиравать? Для детерменированной проверки? Даже если их не рассматривать то умрешь раньше чем он проверит одно число. и это действительно практически.



А я это и не отрицал, я про это и говорил

Вот накалякал, ИМХО, решение моей проблемы.
В левом верхнем углу решение №1 всё остальное - №2

Это сообщение отредактировал(а) En_t_end - 22.1.2007, 15:35

Присоединённый файл ( Кол-во скачиваний: 15 )
 Shem.jpg 20,72 Kb

а чем тебе не понравилась идея ассиметричного шифрования... имхо в данной ситуации это лучший вариант!!.. 
.... или я не правильно понял твою диаграмму))

Это сообщение отредактировал(а) v2v - 22.1.2007, 17:30

Что-то не понять мне никак вашей схемы, поясните пожалуйста словами.

Это сообщение отредактировал(а) Alexandr87 - 23.1.2007, 05:58

Alexandr87, 

В левом верхнем углу:
На сервере хранятся пароли в виде F(password)
При каждом соединении генерируется новой массив байтов r.
Клиент получает r и использует формулу: G(F(Password)+r) для посылки пароля серверу.
Сервер соответсвенно выполняет команду:
G(F(Password)+r)==G(F(Password)+r)
Чтобы удостверится, что пароль действительно правильный.
F,G - хеширующие.
НО! здесь я обманываю сам себя... ведь зная F(Password) который хранится на сервере(не исключаем возможности похищения хешей) BadMan может зайти на сервер под видом клиента. Т.е снова плохо.
Случай №2 гораздо предпочтительней описан он здесь:
http://forum.vingrad.ru/s/3232d0997705d45e...ml#entry1008574
Но мне кажется, что и тут меня ждет фиаско, ибо слишком уж много я требую от хеширующих функций...

В общем моё мнение по поводу 1.("в левом верхнем углу"), ага только теперь кроме той проблеммы, которую назвали вы:

Ведь этот пароль еще нужно при регистрации клиента нужно передать на сервер, или если он гененрируется на сервере до предать то клиента.(В этот момент его могут перехватить). Если вы только не намерены раздавать пароли пользователям из рук в руки. 
А как вы собираетесь хранить хэши паролей, что не исключаете возможность их кражи.(Можно предпринять некие меры, для предотвращения возможности их кражи, например выненсения процедуры проверки присланных значений на отедльную машину)

Я бы не советовал замарачиваться с подобными вещами и изобретать еще один велосипед, берите уже готовые решения (библиотеки) SSL, и работайте.

По идее "по правилам криптографии" по настоящему секретным может считаться только ключ, который нигде не хранится (кроме головы пользователя). Что касается всей остальной инфы, мы должны исходить из того, что она может попасть в руки врага полностью или частично. 

Враги вообще повсюду )))



Тем более, что этот велосипед всегда будет хуже. 

(ну если только изобретающий не гуру-криптограф, второй диффи-хельманн  )

ПС:
Большой оффтоп
Я сейчас тоже комплексной системой занимаюсь. Так вот, на яве такое писать - одно удовольствие. Включая SSL, private/public key, сокеты итд.

ОФФТОП

))) насколько память мне не изменяет - это  два человека.

http://www.securitylab.ru/news/289448.php

W4FhLF,

с твоей ссылки