Народ, скажите свое мнение. Клиент-серверная программа, траф шифруется сабжем. Насколько это безопасно(если учесть, что на взлом потока могут кинуть не более 50 К $)
A том то и дело, что нет. Да и rsa - он ведь с двумя ключами. Для меня это неудобно. Я бы мог и crypton использовать, если б выбор был. А тут тока rc4. Я знал, что rc4 небезопасный. Просто вопрос был: на слолько небезопасный. Так значит хакнут, да?(с таким бюджетом)
Например сообщение шифруешь по ключу и просто скоришь его последовательностью кот. генерирует rc4. Если все сообщения одинаково шифровать (хотя и не обязательно): просто находишь два сообщения кот. одной поледовательностью зашифрованы и тупо их ксоришь между собой, получаются два проксореных между собой сообщения, но уже не зашифрованные, а с ними худо бедно можно что угодно сделать можно. Да и без этого подводных камней там море огромное, можно например про криптоанализ web протокола почитать. Как-то rc4 можно применять, но либо с большим умом, либо вообще не трогать. Гемору наверное всё равно больше чем от rsa. А с rsa тоже не так уж просто будет. Там лучше какой-то ключ временный генерировать, а передавать его с помощью rsa, а шифровать уже чем-то другим. Если прямо всё в rsa закатывать, то это медленно и тоже не слишком безопастно, несмотря на все навороты кот. там придумали. Т.е. всё ещё хуже. Вообще какой-нибудь blofish, idea или что-то нибудь такое.. хотя ничего безопастным не станет, если применять неосторожно....
Совет перейти на RSA и любую другую асимметричную криптографию имеет смысл, когда : А) участников обмена больше 2 и между ними требуется полносвязная передача (т.е. от каждого к каждому), либо Б) если Вы не доверяете хранилищу ключа на одной из сторон (чаще это бывает на клиентской) с точки зрения возможности кражи. Если же всех этих проблем нет, то конечно лучше использовать симметричную криптографию с двумя идентичными ключами на клиенте и сервере. К стойкости самого RC4 особых претензий нет. Хуже, что это поточный шифр, а не блочный (которые Вам советовали - IDEA, BLOWFISH, AES и т.д.). Я бы предложил вот такое решение на базе RC4, здесь в протоколе учтена защита от некоторых видов угроз, однако, возможно другие специалисты форума этот протокол дополнят/улучшат : Обменяйтесь между клиентом и сервером мастер-ключом (MK), размером не менее 128 бит (оптимально - 256), по доверенному каналу, например, "дискеткой/флешкой/компакт-диском/смской/по телефону". В начале каждого нового сеанса : 1) cгенерируйте на клиентской стороне, из стойкого (это некритично, но желательно) источника случайных чисел 224 бита + дополните их 32 битами текущего времени (UNIX-time) на клиентской стороне = получившееся 256-битное значение назовем SKS (session key seed); 2) передайте в открытом виде SKS на серверную сторону 3) на серверной стороне проверьте, что младшие 32 бита SKS строго больше, чем когда-либо передававшиеся ранее (защита от атаки "replay") 4) на сервере и клиенте cгенерируйте SK (session key) = MD5(MK||SKS||MK), знак ||-конкатенация, криптостойкую хеш-сумму можно взять любую, не обязательно MD5 ( http://habrahabr.ru/blogs/infosecurity/50434/ ) 5) активируйте шифрование потока по RC4; в первых зашифрованных пакетах в прямом и обратном направлениях удостоверьтесь, что обе стороны обладают одним и тем же ключом SK (т.е. аутентифицруйте клиента перед сервером, а сервера перед клиентом); не формируя фиксированной посылки (сигнатуры), что всегда плохо для поточных шифров, это можно сделать например следующим образом : создать случайные или псевдослучайные 64 бита, записать в первые 64 бита пакета это число, а в следующие 64 бита его арифметическое (!, не XOR) дополнение до 0хFFFFFFFF:FFFFFFFF, и если после расшифровки сумма сходится, то всё ОК; повторить это нужно в обе стороны
пропустил, надеюсь это самоочевидно : шифрование на 5-м этапе между клиентом и сервером должно вестись на ключе SK
Народ, всем огромное спасибо за ответы. Теперь картинка в голове более-менее ясная Особенный сенскс Proteus и OLS
RC4 прост для понимания и достаточно безопасен, просто не надо использовать повторно один и тот же ключ с RSA гемора гораздо больше
