Здравствуйте, rastoman, Вы писали:
Doc>>Для начала: Наверное ты бы лучше написал в соответствующий форум. R>Не все шароварщики подписаны на "Алгоритмы"...
А кто-то не дает? По рукам лупит
R>----------------------------------------------------------------------- Doc>>У себя — подписываешь данные юзера private ключем и высылаешь ему их. Doc>>В программе проверяешь если подпись верна, то сравниваешь присланные данные с введенными. R>----------------------------------------------------------------------- R>Вот в эту чать я как раз-таки и въхать не могу, хотя вроде в здравом уме и т.п. R>Т.е. подписываешь? Зашифровываешь? Или сздаи прикрепляешь?
Ты с электронными подписями разбирался?
Еще раз наглядный пример:
У тебя:
— 1 берем (вводим) данные (имя юзера, email, имя собаки, возраст итд итп).
— 2 данные шифруем как угодно (хоть XOR-ом) или вообще оставляем как есть
— 3 подписываем эти данные своей priv/pub парой
— 4 записываем в файл данные и подпись
— 5 отсылаем файл юзеру
У юзера:
— 1 читаем из файла данные и подпись
— 2 при помощи public ключа проверяем соответствует ли подпись данным
— 3 если нет — нас дурят
— 4 если да, то расшивровываем данные (если на шаге 2 у себя мы их шифровали)
— 5 проверяем данные из файла и данные введенные пользователем.
— 6 если совпадают то значит это ключ этого юзера. версия регистрированная
где у тебя затык с пониманием?
Кстати, не получится просто сразу шифровать и расшифровывать данные?
Для расшифровки тебе нужен будет private ключ, который зашешь в программу. CryptoAPI дает или public или пару private/public. Выделть отдельно private ключ невозможно. Для подписи подписи наоборот, распостраняем public ключ и у себя держим private что есть правильный ход.
Ну, собственно, понятно, что для генерации серйных номеров для программы нужно использовать криптографию с окрытым ключом. Определился я пока на RSA. Но вот не как не могу въехать — с какой стороны этот RSA нужно грызть, чтобы сделать так, что бы генерировался какой-нибудь регистрационный ключ исходя из имени пользователя, типа лицензии, и т.д.? А потом этот ключ высылать этому пользователю и как-то прога должна определить что ключ верный!!!
Я только въехал, как можно шифровать данные этим алгоритом, а вот остальное....блин.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Советую купить что нибудь готовое (armadillo) если нет познаний.
Я придерживаюсь принципа, что лучше познать непознанное. KA>Если надо сейчас и подешевле, простое MD5 подойдет.
MD5 — согласен, что и быстро и дешево. Однако хеши нетрудно получать, зная алгоритм, — следовательно вопрос времени, когда генератор левых серийников появиться.
Здравствуйте, rastoman, Вы писали:
R>Я только въехал, как можно шифровать данные этим алгоритом, а вот остальное....блин.
Для начала: Наверное ты бы лучше написал в соответствующий форум.
Ну а по делу: простой способ (опускаю все доп. провекри и навороты работы с данными).
Делаешь пару ключей. Public зашиваешь в программу, пару private/public — себе оставляешь.
Данные шифруешь любым простым алгоритмом. Если там ничего секретного — можешь даже оставить как есть.
У себя — подписываешь данные юзера private ключем и высылаешь ему их.
В программе проверяешь если подпись верна, то сравниваешь присланные данные с введенными.
PS: Не забывай что тут описан самый примитив Делай лучше
Здравствуйте, Doc, Вы писали:
Doc>Для начала: Наверное ты бы лучше написал в соответствующий форум.
Не все шароварщики подписаны на "Алгоритмы"... Doc>Ну а по делу: простой способ (опускаю все доп. провекри и навороты работы с данными). Doc>Делаешь пару ключей. Public зашиваешь в программу, пару private/public — себе оставляешь. Doc>Данные шифруешь любым простым алгоритмом. Если там ничего секретного — можешь даже оставить как есть.
----------------------------------------------------------------------- Doc>У себя — подписываешь данные юзера private ключем и высылаешь ему их. Doc>В программе проверяешь если подпись верна, то сравниваешь присланные данные с введенными.
-----------------------------------------------------------------------
Вот в эту чать я как раз-таки и въхать не могу, хотя вроде в здравом уме и т.п.
Т.е. подписываешь? Зашифровываешь? Или сздаи прикрепляешь?
Doc>PS: Не забывай что тут описан самый примитив Делай лучше
... << RSDN@Home 1.1.3 stable >>
Re[2]: RSA и ключики
От:
Аноним
Дата:
27.05.04 08:32
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rastoman, Вы писали:
R>>Я только въехал, как можно шифровать данные этим алгоритом, а вот остальное....блин.
Doc>Для начала: Наверное ты бы лучше написал в соответствующий форум. Doc>Ну а по делу: простой способ (опускаю все доп. провекри и навороты работы с данными). Doc>Делаешь пару ключей. Public зашиваешь в программу, пару private/public — себе оставляешь. Doc>Данные шифруешь любым простым алгоритмом. Если там ничего секретного — можешь даже оставить как есть. Doc>У себя — подписываешь данные юзера private ключем и высылаешь ему их. Doc>В программе проверяешь если подпись верна, то сравниваешь присланные данные с введенными.
Не прокатит такая схема, во первых данные не подиписываются приватным ключем, а шифруются, а во вторых чтобы потом расшифровать эти данные у клиента должна быть пара ключей публичный и приватный.
Т.е. по твоей схеме зашивать в программу придется публичный и приватный ключ. А уже выкусит эту пару из бинарника, чтобы сделать кейгенератор — дело техники.
Doc>PS: Не забывай что тут описан самый примитив Делай лучше
Здравствуйте, Аноним, Вы писали:
А>Не прокатит такая схема, во первых данные не подиписываются приватным ключем, а шифруются,
Сейчас... Смотрим CryptoAPI:
— для шифрования юзается public ключ, а private расшифровывает.
тебе приходят закрытые данные. Шифрует любой (public key), а расшифровываешь только ты (private key).
— для подписи испольуется private ключ, а public проверяет подпись.
ты подписываешь, а любой адресат (с public key) убеждается что данные от тебя (private key).
А>а во вторых чтобы потом расшифровать эти данные у клиента должна быть пара ключей публичный и приватный.
Стоп. Я говорю о подписи. Сами данные кстати, уже можно не шифровать. Или юзать что-нибудь по проще.
Даже если данные расшифруют, их еще подписать надо, а это уже геморрой.
А>Т.е. по твоей схеме зашивать в программу придется публичный и приватный ключ. А уже выкусит эту пару из бинарника, чтобы сделать кейгенератор — дело техники.
Зачем пару? Отдаем в программе public и все. Не нужен private. не нужен.
Конечно можно подменить public, но это уже crack. А crack-нуть можно практически все.
Здравствуйте, Doc, Вы писали:
Doc>Ты с электронными подписями разбирался?
Не так сильно, как с самой шифрацией, однако в курсе, что в таком случае private и public ключ местами меняются.
Doc>Еще раз наглядный пример:
Doc>У тебя: Doc>- 1 берем (вводим) данные (имя юзера, email, имя собаки, возраст итд итп). Doc>- 2 данные шифруем как угодно (хоть XOR-ом) или вообще оставляем как есть Doc>- 3 подписываем эти данные своей priv/pub парой Doc>- 4 записываем в файл данные и подпись Doc>- 5 отсылаем файл юзеру
Doc>У юзера: Doc>- 1 читаем из файла данные и подпись Doc>- 2 при помощи public ключа проверяем соответствует ли подпись данным Doc>- 3 если нет — нас дурят Doc>- 4 если да, то расшивровываем данные (если на шаге 2 у себя мы их шифровали) Doc>- 5 проверяем данные из файла и данные введенные пользователем. Doc>- 6 если совпадают то значит это ключ этого юзера. версия регистрированная
Doc>где у тебя затык с пониманием?
В голове, наверное..., но ситуация заметно идёт к улучшению, скоро выпишусь...
Doc>Кстати, не получится просто сразу шифровать и расшифровывать данные? Doc>Для расшифровки тебе нужен будет private ключ, который зашешь в программу. CryptoAPI дает или public или пару private/public. Выделть отдельно private ключ невозможно. Для подписи подписи наоборот, распостраняем public ключ и у себя держим private что есть правильный ход.
Crypro API юзать не могу, т.к. под ещё и под unix генератор нужно будет делать.
Следовательно, нужно останавливаться на электронных подписях?
On Thu, 27 May 2004 08:32:40 GMT, wrote:
> Не прокатит такая схема, во первых данные не подиписываются приватным > ключем, а шифруются, а во вторых чтобы потом расшифровать эти данные у > клиента должна быть пара ключей публичный и приватный. > Т.е. по твоей схеме зашивать в программу придется публичный и приватный > ключ. А уже выкусит эту пару из бинарника, чтобы сделать кейгенератор — > дело техники.
Все правильно он сказал, не надо путать человека . Подписывание и
шифрование
это по сути одно и то же. В RSA для шифровки нужно знать приватный ключ, а
для
расшифровки достаточно публичного. Так что:
ДанныеЮзера -1-> ЗашифрованныеПриватнымКлючомДанныеЮзера -2->
РашифрованныеДанныеКоторыеМожноСравнить в -1-> использует приватный ключ
в -2-> публичный
ЗашифрованныеПриватнымКлючомДанныеЮзера — нельзя сгенерировать без
приватного ключа
On Thu, 27 May 2004 08:58:26 GMT, Gadsky <12705@news.rsdn.ru> wrote:
> ДанныеЮзера -1-> ЗашифрованныеПриватнымКлючомДанныеЮзера -2-> > РашифрованныеДанныеКоторыеМожноСравнить в -1-> использует приватный ключ > в -2-> публичный > ЗашифрованныеПриватнымКлючомДанныеЮзера — нельзя сгенерировать без > приватного ключа
Фу, господи, какое гадостное форматирование получилось .
Кстати, если кому нужно — могу послать исходники с RSA функциями.
Длина ключа — сколько памяти хватит
Posted via RSDN NNTP Server 1.9 alpha
Re[5]: RSA и ключики
От:
Аноним
Дата:
27.05.04 09:42
Оценка:
Здравствуйте, Gadsky, Вы писали: G>Фу, господи, какое гадостное форматирование получилось . G>Кстати, если кому нужно — могу послать исходники с RSA функциями. G>Длина ключа — сколько памяти хватит
выложи в форум "исходники" плз
Здравствуйте, rastoman, Вы писали:
Doc>>Кстати, не получится просто сразу шифровать и расшифровывать данные? Doc>>Для расшифровки тебе нужен будет private ключ, который зашешь в программу. CryptoAPI дает или public или пару private/public. Выделть отдельно private ключ невозможно. Для подписи подписи наоборот, распостраняем public ключ и у себя держим private что есть правильный ход. R>Crypro API юзать не могу, т.к. под ещё и под unix генератор нужно будет делать. R>Следовательно, нужно останавливаться на электронных подписях?
Мой совет: внимательно изучить подписи (понять, а то похоже ты еще не до концв понял). И остановиться на варианте — простое шифрование данных (что бы сходу не увидеть) и подпись для уверенности что их отправил ты. Ну и искать слабые места и делать хитрые проверки (что public ключ не подменили итд)
Doc>Мой совет: внимательно изучить подписи (понять, а то похоже ты еще не до концв понял). И остановиться на варианте — простое шифрование данных (что бы сходу не увидеть) и подпись для уверенности что их отправил ты. Ну и искать слабые места и делать хитрые проверки (что public ключ не подменили итд)
Спасибо.
Вот где бы исходник нормальный для RSA или HFE взять.....?
Не охота самому всю математику реализовывать....
Здравствуйте, rastoman, Вы писали:
R>А не мог бы ты описать отличия подписи RSA от прстого RSA?
Э..э..э..э.??? Прям незнаю что сказать. Вопрос ставишь некоректно. Шифрование нужно для того что бы скрыть данные от чужих глаз, а подпись что бы удостоверить что информация имеено от конкретного источника (в нашем случае твой софт должен "убедиться" что инфа о зарегистрировавшимся от тебя).
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rastoman, Вы писали:
R>>А не мог бы ты описать отличия подписи RSA от прстого RSA? Doc>Э..э..э..э.??? Прям незнаю что сказать. Вопрос ставишь некоректно. Шифрование нужно для того что бы скрыть данные от чужих глаз, а подпись что бы удостоверить что информация имеено от конкретного источника (в нашем случае твой софт должен "убедиться" что инфа о зарегистрировавшимся от тебя).
Ну, в этом я уже вкурсе, ... после второго дня поиска информации и исходников...
Здравствуйте, Gadsky, Вы писали:
G>В RSA для шифровки нужно знать приватный ключ, а G>для расшифровки достаточно публичного. Так что:
Для шифрования все как раз наоборот. Шифруется все public key, а расшивровыввается только private key.
А вот для подписи как раз — подписываем private, а все могут проверить используя public.
Здравствуйте, rastoman, Вы писали:
Doc>>Э..э..э..э.??? Прям незнаю что сказать. Вопрос ставишь некоректно. Шифрование нужно для того что бы скрыть данные от чужих глаз, а подпись что бы удостоверить что информация имеено от конкретного источника (в нашем случае твой софт должен "убедиться" что инфа о зарегистрировавшимся от тебя). R>Ну, в этом я уже вкурсе, ... после второго дня поиска информации и исходников...
Ну собственно это по большому счету все различия между подписью и шифрованием
Кстати, возми пока в качестве алогоитма CryptAPI и просто поэксперементируй.
Там все просто (особенно если есть MSDN). Подпиши данные и проверь другой прогой.
Сделаешь пару (подписывающее например указанный файл и проверяющее подпись) таких консольных приложений для теста и будешь понимать
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, rastoman, Вы писали:
R>>Вот где бы исходник нормальный для RSA или HFE взять.....? Doc>Тут же вроде предлагали ?
Здравствуйте, Sergeant, Вы писали:
S>Есть еще приятная библиотека — crypto++. Реализована хуча алгоритмов, среди них и RSA, написана на С++. Страница здесь: http://www.eskimo.com/~weidai/cryptlib.html
Я про неё давно знаю.
Если бы писал на С++, проблем бы не было.
А мне C# нужен, ну или Perl — следовательно нужно всё самому писать, т.к. готовых библиотек я не нашёл.
Здравствуйте, rastoman, Вы писали:
R>MD5 — согласен, что и быстро и дешево. Однако хеши нетрудно получать, зная алгоритм, — следовательно вопрос времени, когда генератор левых серийников появиться.
Был такой рассказ про Interbase — некие товарищи создали базу
в несколько сотен(что-ли? не помню точно) гигабайт.
Они хранили там строки с хэшами MD5.
Как тебе такой подход к обратимости? Я понимаю, что MD5("Война и мир")
сложно обратить, но что-то, например, ключики уже можно.
Здравствуйте, rastoman, Вы писали:
R>А мне C# нужен, ну или Perl — следовательно нужно всё самому писать, т.к. готовых библиотек я не нашёл.
Для C# .Net Framework есть System.Security.Cryptography.RSACryptoServiceProvider , под другие платформы есть реализация в mono (RSAManaged), понятно что это GPL.
Здравствуйте, problemsolver, Вы писали:
P>>По Вашему получается, что MD5 хэши обратимы?
P>Был такой рассказ про Interbase — некие товарищи создали базу P>в несколько сотен(что-ли? не помню точно) гигабайт. P>Они хранили там строки с хэшами MD5. P>Как тебе такой подход к обратимости? Я понимаю, что MD5("Война и мир") P>сложно обратить, но что-то, например, ключики уже можно.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, problemsolver, Вы писали:
P>>Они хранили там строки с хэшами MD5.
Doc>Так хеши от строк или строки с хешами?
С
P>>Как тебе такой подход к обратимости?
Doc>А в чем подход? Как я понимаю хранили хеши например, для проверки целостности данных.
Народ, вы ничего не поняли.
Чтобы не перебирать строки, вычисляя от них MD5,
пока не попадется тот хэш, который пытаемся обратить,
они создали готовую базу и писали что-то вроде
select str from table where md5=:param
При достаточно большом наборе строк ваш MD5 обращается
за очень короткое время.
А в 700GB(не MB!) войдет достаточно много строк, вам не кажется?
Здравствуйте, problemsolver, Вы писали:
P>они создали готовую базу и писали что-то вроде P>select str from table where md5=:param P>При достаточно большом наборе строк ваш MD5 обращается P>за очень короткое время. P>А в 700GB(не MB!) войдет достаточно много строк, вам не кажется?
От таких умников спасает "затравка" хэша (salt). Она выбирается случайным образом и увеличивает число вариантов еще на пару порядков.
Здравствуйте, Doc, Вы писали:
Doc>Для шифрования все как раз наоборот. Шифруется все public key, а расшивровыввается только private key. Doc>А вот для подписи как раз — подписываем private, а все могут проверить используя public.
Бред. Возможно в какой либо конкретной реализации так, но сам алгоритм позволяет шифровать любым из ключей, расшифровывать соответственно надо другим.
Приватный ключ светить нигде не надо — на то он и приватный. А если учесть что много где процессинг с приватным ключом реализуется через китайскую теорему то в приватном ключе в таком случае лежит очень много такого, что позволит мало того что получить из приватного публичный но и узнать P и Q, что равносильно полной компроментации ключей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
Doc>>Для шифрования все как раз наоборот. Шифруется все public key, а расшивровыввается только private key. Doc>>А вот для подписи как раз — подписываем private, а все могут проверить используя public. CC>Бред.
(глядя на дату своего поста) "Меня будить!!!!" (с)
Ну да давайте разберемся.
CC>Возможно в какой либо конкретной реализации так,
Так "бред" или нет? Если "в какой либо конкретной реализации так", то уже не бред.
CC>но сам алгоритм позволяет шифровать любым из ключей, расшифровывать соответственно надо другим.
И что вы нового сказали по сравнению с моим сообщением?
CC>Приватный ключ светить нигде не надо — на то он и приватный. А если учесть что много где процессинг с приватным ключом реализуется через китайскую теорему то в приватном ключе в таком случае лежит очень много такого, что позволит мало того что получить из приватного публичный но и узнать P и Q, что равносильно полной компроментации ключей.
В общем то же самое, но своими словами и в 4 раза объеменее.
Здравствуйте, Doc, Вы писали:
Doc>(глядя на дату своего поста) "Меня будить!!!!" (с)
Ну звиняй, я на даты редко смотрю.
CC>>Возможно в какой либо конкретной реализации так, Doc>Так "бред" или нет? Если "в какой либо конкретной реализации так", то уже не бред.
Нет, это будет частичная имплементация алгоритма. Т.е. неполная реализация. Речь шла именно о алгоритме, AFAIR
CC>>но сам алгоритм позволяет шифровать любым из ключей, расшифровывать соответственно надо другим. Doc>И что вы нового сказали по сравнению с моим сообщением?
Шифруется все public key, а расшивровыввается только private key.
Тогда как для шифрования RSA:
Если шифруется public-ом то расшифровывается только private-ом.
Если шифруется private-ом то расшифровывается только public-ом.
Суть в том, что шифрование возможно любым ключом, а не "Шифруется все public key"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Ой, такую старую тему подняли.
Я там отвечал в 2004 году в самом начале и еще раз скажу тоже самое.
Само по себе RSA или ECC (что лучше чем RSA так как подпизь покороче) это фигня.
А кароче, даже если накрутишь там RSA какой нить , то все равно надо что-то навешивать. А то сломают все равно 1 байтом.
Поэтому возми execryptor и не мучайся.
Вот например time limited ключи тоже делать надо. фички там какие нить ... в e. это есть. а так самому городить.
Может у кого конечно программа фуфельная, и 30 дней ей хватает, а вот у кого корпоративные клиенты тем нужна гибкость.
Здравствуйте, Doc, Вы писали:
CC>>Нет, это будет частичная имплементация алгоритма. Т.е. неполная реализация. Doc>Ну вот. А то сразу "бредом" обзывать
Даже скорее не неполная реализация а искуственно ограниченная реализация.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, YuriKobets, Вы писали:
Doc>>Кстати, как я понял для x64 вариантов кроме Армадилы нет?
YK>Именно так. До сих пор никакой альтернативы нет. Автор execryptor-а обещался сделать поддержку x64 но воз и ныне там Вот так теряют клиентов
Странно. Я слышал на днях, что для зарегистрированных пользователей Execryptor для х64 уже есть.
Здравствуйте, rastoman, Вы писали:
R>Нет, нет нативные 64-битные приложения не поддерживаются. R>Появился EXECryptor 2.4 RC1 для зарегистрированных пользователей, с поддержкой Vista.
А, да, точно. Спутал. Сорри.
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Ой, такую старую тему подняли.
виноват-с...
KA>ECC (что лучше чем RSA так как подпизь покороче)
Но хуже бо математика малость мозголомная... По крайней мере если хочешь сам кривые генерить а не NISTовые пользовать.
KA>Само по себе RSA или ECC это фигня.
Это смотря как пользовать. Если в конце проверки простой JNZ то да — лажа: сейфовый замок на деревяной калитке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока