Простой аналог ЭЦП на коленке

велосепедя RSA

Что там велосипедить-то, несколько несложных формул. Но велосипедить всеравно не стоит, т.к. уязвим не алгоритм, а конкретные реализации.

Простой аналог ЭЦП на коленке

убедиться что он пришел от нужного сервера, не побился и не был подменен

Классические параграфы. Неужели ты думаешь, что gpg-сотоварищи специально усложнены?

Ну у тебя RSA или аналог и получится.

Неужели ты думаешь, что gpg-сотоварищи специально усложнены?

Видимо нет, во всяком случае простого решения я не вижу :)

http://www.tedunangst.com/flak/post/signify

http://mdoc.su/o/signify

Делает именно то и именно так, как ты спрашиваешь.

Делает именно то

Еще одна эцп на основе экзотического публичного ключа имплементации которого хрен найдешь?

HMAC тебе надо.

не передавая закрытый ключ.

А без этого никак. Либо сторонняя authority, которая подтверждает подлинность сервера, либо передача секретного ключа каким-то другим способом.

Если злоумышленник умудряется перехватить передачу файла, кто мешает ему перехватить html'ку с текстом открытого ключа?

Если злоумышленник умудряется перехватить передачу файла, кто мешает ему перехватить html'ку с текстом открытого ключа?

Считаем что открытый ключ рид-онли и «вшит» в клиент

HMAC тебе надо.

По-моему то что надо, спасибо!

кто мешает ему перехватить html'ку с текстом открытого ключа?

Кажись, кто-то не совсем понимает ассиметричную криптографию. ;)

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

Еще одна эцп на основе экзотического публичного ключа имплементации которого хрен найдешь?

А пройтись по ссылкам, не? ;)

Поскажите, как бы вы решили такую задачу без openssl

не надо решать эту задачу без openssl, проще его осилить

даже подсказку дам, всё делается одной командой «openssl dgst», читай соответствующий ман

Желательно всё сделать без лишних либ. Пока читаю про http://ru.wikipedia.org/wiki/HMAC очень похоже на то что надо

либа не нужна, бинарь openssl и так есть практически в любой *nix системе

HMAC тебе надо.

А нет, оно симметричное, не прокатит

наверное он говорит про подмену открытого ключа

наверное он говорит про подмену открытого ключа

От чего, собстенно, ассиметричная криптография и защищает. ;)

не, не защищает

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

не, не защищает

Защищает, закрытый для подписи, открытый для проверки. Зная открытый не получить закрытый

Зная открытый не получить закрытый

а откуда ты будешь уверен, что ты именно тот, правильный открытый ключ знаешь? :)

в общем случае да, у меня же

Считаем что открытый ключ рид-онли и «вшит» в клиент

Подпись — это не шифрование. Точне почти тоже самое, но в обратную сторону.

Сообщение подписывается закрытым ключём. Открытый ключь раздаётся всем желающим.

Имея открытый ключь, ты можешь сказать верная ли подпись — да или нет. И всё.

Подменив открытый ключь, мы получим «нет».

Подменив сообщение, мы получим «нет».

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

ну вот, как я и говорил, нужен физический контакт для передачи ключа

Я неправильное слово использовал. Вместо «перехватить» нужно было использовать «подменить». Если есть возможность показать пользователю произвольную информацию, никто не может запретить сгенерировать новую пару ключей и подписать новым ключом поддельный файл, а пользователю показать подконтрольный открытый ключ.

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

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

ключ без мягкого знака пишется

Да, тут я согласен. Кому-нибудь, да доверять надо: или ключу или сообщению. Полученные по одному каналу сообщение и ключ доверию не подлежат.

Думаю он имеет ввиду подмену открытого ключа на свой.

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

Проблема тут другая: люди — главная дыра. Кто-нить может взять и унести сервак к себе домой/продать/и т.п.

Вообще, проблему на уровне доставки решает VPN, IPSec. Туннель IPSec сложно скомпроментировать, а при настроенном файрволле так вообще не прошибешь.

Что касается самих файлов, то можно воспользоваться PGP (лучше локально развернутом).

то можно воспользоваться PGP (лучше локально развернутом).

а то многие любят пользоваться облачным PGP? :)

Я про это: https://en.wikipedia.org/wiki/Pretty_Good_Privacy#Certificates

Поскажите, как бы вы решили такую задачу без openssl, сертификатов, RSA и тп. (md5, sha1, и тп использовать можно)

Как приготовить пельмени, но без теста? Серьезно?

GnuPG, не? Да, там есть ключи. Но это лучше, чем твоя идея изобрести велосипед.

А пройтись по ссылкам, не? ;)

Первым же делом прошелся. Сишка в самом худшем ее виде. За байтолюбством алгоритма не видать.

За байтолюбством алгоритма не видать.

А djb по другому не умеет, но мужик он всёж головастый. ;)

Симмитричное шифрование зря выкидываешь

Если ключ один на клиенте и на сервере, а на клиенте он в открытом виде, то безопасность нулевая

Без знания алгоритмов никто тебя не взломает

Ну смотри, например у нас есть некий открытый ключ, например у нас алгоритм: циклично смещаем на пару байт и делаем xor md5 файла с ключем. Т.к. код клиента открыт любой кулхацкер сможет по открытому ключу собрать закрытый.

Поэтому тут надо такой алгоритм, который позволяет получить открытый ключ из закрытого (но не наоборот), сгенерировать закрытым ключем подпись и проверить открытым ключем её.

Без знания алгоритмов никто тебя не взломает.

Security through obscurity ломается первой. Конфиденциальность должна зависить от ключа, а не алгоритма. Проприсные истины же.

Всем спасибо, решил взять openssl и не велосипедить. Вопрос был скорее академический

Не зная закрытого ключа, которым была сделана подпись

Не «закрытого», а секретного.

Security through obscurity ломается первой.

Тут еще эффект Неуловимого Джо играет роль.

Твоя проблема в том виде в котором ты описал решается HTTPS. + extended ev сертификаты. Корневые сертификаты должны быть вшиты в программу-качалку https/tls траффика. Сервер, с которого производится считывание, должен иметь ev сертификат.

Т.к. код клиента открыт

Про это я не знал. Из постановки задачи неясно какой клиент и какой сервер. Я понял, что оба закрытые.