2012-04-23 3 views
2

Поиск того, как выполняется подписка. Я столкнулся с некоторыми довольно сложными образцами кода. Но следующий код кажется достаточно. Там что-то отсутствует здесь, например, соль, или соли не нужны при подписании? Я не шифрую, просто подписываю.Этого достаточно для подписи данных?

RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(); 

byte[] data = Encoding.ASCII.GetBytes("hello"); 
byte[] signature = rsa.SignData(data, "SHA1"); 

byte[] dataTest = Encoding.ASCII.GetBytes("hello"); 
bool verified = rsa.VerifyData(dataTest, "SHA1", signature); 
if (verified) Text = "True"; else Text = "Untrue"; 
+0

В чем ваш вопрос? –

+1

Зачем нужна соль при подписании *? –

+0

Кроме того, вы не должны использовать SHA-1, если выбор за вами. Как известно, SHA-1 имеет недостатки, которые могут быть использованы. Вместо этого используйте 256-битные или 512-битные версии SHA-2. –

ответ

13

ли соли ненужными, когда только подписание?

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

Если вы не понимаете, почему вам нужна соль, увидеть мою серию статей по этой теме:

http://blogs.msdn.com/b/ericlippert/archive/tags/salt/

Есть ли что-то здесь отсутствует?

Да, самый важный шаг отсутствует. Как вы собираетесь передавать открытый ключ? Безопасность всей системы зависит от этого шага, о котором вы даже не упомянули.

Предположим, что Алиса хочет отправить сообщение Бобу и Бобу, чтобы проверить, что это произошло от Алисы. Они выполняют следующие действия:

  • Алиса создает пару ключей и надежно хранит закрытый ключ.
  • Алиса публикует открытый ключ.
  • Боб получает открытый ключ Алисы.
  • Alice опубликовывает сообщение.
  • Алиса хэширует сообщение и шифрует хэш своим личным ключом.
  • Боб читает сообщение.
  • Боб читает зашифрованный хэш.
  • Боб расшифровывает зашифрованный хэш с открытым ключом Алисы.
  • Боб хэширует сообщение.
  • Боб сравнивает дешифрованный хэш с хэшем сообщения. Если они совпадают, тогда Боб знает, что сообщение было поручено Алисой.

Это правильно?

Вывод неверный. Вывод должен быть:

  • Боб сравнивает дешифрованный хеш с хешем сообщения. Если они совпадают, то Боб знает, что сообщение было поручено тем, у кого был закрытый ключ, который соответствует открытому ключу, который Боб считает открытым публичным ключом Алисы.

Исходный вывод верен , если у Боба есть дополнительные доказательства того, что у него есть открытый ключ Алисы. Потому что Bob может быть в таком положении:

  • Алиса создает пару ключей и надежно хранит закрытый ключ.
  • Mallory создает пару ключей, а безопасность хранит закрытый ключ.
  • Алиса публикует открытый ключ.
  • Мэллори перехватывает публикацию Алисы и заменяет открытый ключ Алисы открытым ключом Мэллори.
  • Боб получает публичный ключ Мэллори, но считает, что это Алиса.

И теперь все это ушло в ад. Мэллори теперь может публиковать сообщения, которые Боб считает пришедшими от Алисы, и Алиса не может!

Вы должны сказать , как вы собираетесь публично публиковать открытый ключ. Вся система опирается на две вещи: закрытые ключи остаются закрытыми, а есть механизм, с помощью которого открытые ключи могут быть правильно связаны с их владельцами.

+0

Спасибо вам за подробное объяснение. – ispiro

+0

Кажется, что для безопасного опубликования открытого ключа мне нужно будет купить сертификат SSL. – ispiro

+4

@ispiro: Если вы покупаете сертификат, орган по сертификации ручается за вас. Вы можете использовать сертификат подписи кода, если подписываете код. Вы также можете публиковать свой публичный ключ (или внедрять его в загрузку) на надежном сайте SSL (теперь сайт SSL обручивается для вас, а центр сертификации сайта ручается за сайт), предоставить компакт-диск с голографической безопасностью (в запутанным способом, так как Microsoft ручается за открытые ключи органов сертификации), вызовите пользователя по телефону и зачитайте открытый ключ в шестнадцатеричном формате и т. д. – Brian

Смежные вопросы