Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Нужен совет по ассиметрии, плиз! 09.01.02 11:30 Число просмотров: 1628
Автор: paganoid Статус: Member
|
> А если не видно разницы,
> зачем
> > плодить больше?
>
> Я хотел сделать так: Админ знает 2 ключа, Юзер -1, Гость -
> 0. Админ может и читать и изменять данные, Юзер только
> читать, Гость - ничего не может. Для этого и нужно два
> ключа.
про что говорил я - Админ знает RSA Public + RSA Private, юзер знает
RSA Public, гость не знает ничего. Количество, как ты видишь, одно и то же.
>
> Дело в том, что если шифровать с помощью RSA ключ AES, то
> не получиться разграничить доступ по чтению и изменению
> данных, в чем собственно и задача. Так, получив один раз
> открытый ключ AES можно им тут же и читать и писать.
ключ AES - это сеансовый ключ и нигде не хранится. Заполучить его можно только внедрив в систему свой исполняемый код. Кто может внедрить в систему свой код, может перехватывать все твои ключи на раз плюнуть и соответственно к криптографии этот вопрос уже не имеет никакого отношения. Сервер должен быть защищен.
вобщем, предложенная мной схема имхо вполне надёжная и проверенная. Зачем ты удваиваешь нужный объем работы, пока не могу понять, но попытаюсь...
> С тех пор как исходное сообщение написал - сам немножко
> поразмыслил:
> Первичная схема, предложенная мной, плоха минимум по 3
> причинам:
> 1) Не годится для мало-мальски серьезных по объему блоков
> данных - RSA слишком медленный для шифрования целого блока
> данных.
естественно
> 2) Ни к чему использовать для RSA и AES один и тот же ключ,
> это может быть небезопасным.
> 3) При изменении данных с неверным ключом записи (скажем
> Юзером) данные попросту испортятся, а Админ не сможет
> определить (в общем случае) этот факт.
>
> Предлагаю новую схему :-)
>
> Зашифрование:
> 1) signature=RSAencrypt(hash(block),WriteKey)
> // Т.е. к блоку дописывается подпись - хэш, зашифрованный
> ключом записи
> 2)
> {block,signature}=AESencrypt({block,signature},AccessKey)
> // Блок данных с подписью шифруются AES'ом с ключом доступа
>
> Расшифрование:
> 1)
> {block,signature}=AESdecrypt({block,signature},AccessKey)
> // Данные уже расшифрованы, следующей операцией проверим
> подпись,
> // что бы убедиться, в правомерности записанной информации
> 2) if RSAdecrypt(signature,ReadKey)=hash(block) then OK
> // Расшифровываем подпись, вычисляем хэш блока и сравниваем
> их
> // Если они равны, то все ОК, если нет, то данные изменил
> тот, кто
> // не имел на это право (Юзер)
>
> Таким образом в схеме работает 3 ключа:
> AccessKey - ключ для доступа к данным
> ReadKey - для проверки валидности данных
> WriteKey для санкционированного изменения данных
> Админ знает все три ключа, Юзер знает AccessKey и ReadKey,
> Гость ни знает ничего.
>Введем еще Юзера2, который тоже
> знает AccessKey и ReadKey.
> Админ может читать данные, проверять их валидность и
> санкционированно изменять данные. Юзер и Юзер2 могут читать
> и проврять данные на валидность, но не могут
> санкционированно изменять данные. Если вдруг Юзер изменит
> данные, Админ и Юзер2 смогут обнаружить этот факт и забить
> тревогу. Гость не может делать ничего.
да, приведенная схема вроде корректна.
А теперь самый интересный момент - как ты будешь вручать ключ ReadKey юзерам.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
