Доброго дня...
Ищется подходящий механизм для обмена криптованными сообщениями между ява апплетом и С++ приложением по сети. (оба пишутся мной)
У кого какие мысли есть по этому поводу?

1. Applet po seti rabotat' ne mozhet :
http://java.sun.com/sfaq/#prevent
(tolko svyazivatsa so svoim hostom)

2. Dlya communikatsii application c C++ mozhno ispolzovat'

a. CORBA over IIOP (zaodno posmotrite zdes' i zdes')
b. SoniC MQ ili drugoe commercheskoe prilozhenie
c. HTTP transport (cherez servlet) - vrode v C++ est biblioteki podderzhivayushie POST/GET methods.

Это сообщение отредактировал(а) Domestic Cat - 14.5.2004, 02:39

> 1. Applet po seti rabotat' ne mozhet :
Апплет по сети работать МОЖЕТ! Он у меня подписан.

> a) b) c) ...
Ну, нет... Это совсем не то.
Есть у меня ява апплет. Работает он естественно у клиента, соединяется с С++ приложением на х.х.х.х хосте, вот только по сети бегает plain text А это есть неразумно. Если "выпускать" во внешние сети то это чревато... Вот и встал вопрос о несложном криптовании траффика. С SSL завязываться не хочется. Но и оставлять как есть тож не могу. Вот и думаю о вариантах с ксорками

Stream mozhno zashifrovat ispolzuya JCE http://java.sun.com/products/jce/index.jsp - tam est CipherInputStream i CipherOutputStream. C++ ponyat' encrypted message vryad li smozhet, no po idee mozhno napisat Java-client kotorii budet slushat socket, rashifrovyvat i peredavat C++.

Ну XOR не обеспечивает никакой крипто-стойкости, поэтому если есть или могут возникнуть в будущем, требования по защите информации то к такому методу лучше не прибегать. А JCE не такая уж и плохая идея. Я думаю найти реализацию DES или Blowfish для Си не составит труда. Берешь иформацию зашифровывываешь ее тем же DES, пересылаешь, а в сишном клиенте расшифровываешь. Единственная проблема это обмен ключами, вот тут надо подумать.

Вот я б чем и говорю... Все советы сводятся к SSL соединению, но я как уже говорил выше не хотел бы на этом завязываться... Поэтому и интересуюсь.

Цитата

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

Гм... во времена популярности Спектрума как раз очень часто именно ксорки и применяли в защите. Переломал я их тогда немало, но один подход меня таки удивил, когда следующий символ ксорился с параметром кода пердыдущего символа(это не ново), но! весь цикл повторялся 1024 раза... (great Bill Gilbelrt)
Даже на слабеньком ZX-80A (3,5МГц) эта процедура занимала доли секунды, а в результате получался очень даже привлекательный мусор Если ксорить тупо весь блок с одим параметром, то достаточно 256(макс.) проходов и текст расшифрован. а вот если повыпендриваться с точками входа, и динамически изменяемыми параметрами для ксора, то получим хороший результат.
Кхм, я отвлекся... Ностальгия...

Конечно, это всё не попадает под ТЗИ. В итоге я вижу следующие варинаты:
1. Поиск реализации DES/3DES, BLOWFISH, CRYPT алгоритмов под яву и под плюсы. Но вылазит бок с обменом ключами...
2. SSL соединение. Но тяжеловато на подъем, плюс специфическое чтение сокетов...
3...?

Цитата(Alone @ 17.5.2004, 11:14)

Гм... во времена популярности Спектрума как раз очень часто именно ксорки и применяли в защите. Переломал я их тогда немало, но один подход меня таки удивил, когда следующий символ ксорился с параметром кода пердыдущего символа(это не ново), но! весь цикл повторялся 1024 раза... (great Bill Gilbelrt)

Вот вам и доказательство ненадежности XOR. Эх ZX .
Попробуйте Kerberos вот ссылка для Java Kerboros for java.

ZX рулит!!!! вернее рулил... мдя... эх.. Был там еще регистр R (вроде так назывался. пара IR) так он с каждым выполненым байтом увеличивался на единицу - тоже источник для XOR-а. Да еще и против многих дебагеров помогал.
Но это все off...

Посмотри http://alexeenko.prima.susu.ac.ru/cryptography/sizov/ я его реализовал между C++ и Java в своей работе.