2017-01-20 12 views
3

В соответствии с моей понимаемой цифровой подписью используйте асимметричное шифрование. Владелец подписывает контент, шифруя [закрытый ключ], и все остальные пользователи дешифруют с помощью открытого ключа, а затем сравнивают с обычным текстом. Это правильно?Понимание цифровой подписи

Кроме того, на одном из шагов протокола SSL-подтверждения TLS пользователь отправляет серверу сообщение, которое содержит: Signature_user (PreMasterKey, ...). Как я понимаю, третья сторона может просто расшифровать с помощью открытого ключа и получить PreMasterKey, который должен быть секретным.

Что мне здесь не хватает?

+4

Я голосую, чтобы закрыть этот вопрос как не по теме, потому что это криптовый вопрос, а не вопрос программирования. –

ответ

3

Ваше понимание цифровой подписи близко к правильному. Поскольку асимметричное шифрование ограничено тем, сколько данных он может фактически шифровать и дешифровать (например, RSA-4096 может шифровать не более 446B), цифровая подпись обычно равна Encrypt(Hash(message), privateKey), где Hash() является криптографической хэш-функцией, такой как SHA-256. Это значение может быть расшифровано любым, кто использует открытый ключ подписывающего лица, и тот же алгоритм хеширования, применяемый локально к подозрительному сообщению, чтобы проверить подпись. Вы можете продемонстрировать это для себя, например, при использовании gpg:

hw12203:/Users/alopresto/Workspace/scratch (master) alopresto 
14s @ 15:49:46 $ echo "This is a test" > sign.txt 
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto 
11s @ 15:52:30 $ gpg --sign sign.txt 
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto 
60s @ 15:53:22 $ xxd sign.txt.gpg 
0000000: a301 014d 02b2 fd90 0d03 000a 013c 6ef6 ...M.........<n. 
0000010: 5b2f 7def 6901 ac1d 6208 7369 676e 2e74 [/}.i...b.sign.t 
0000020: 7874 5882 a322 5468 6973 2069 7320 6120 xtX.."This is a 
0000030: 7465 7374 0a89 021c 0400 010a 0006 0502 test............ 
... 
0000250: 1999 83c9        .... 
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto 
100s @ 15:54:11 $ gpg --verify -vvv sign.txt.gpg 
gpg: using character set `utf-8' 
:compressed packet: algo=1 
:onepass_sig packet: keyid 3C6EF65B2F7DEF69 
    version 3, sigclass 0x00, digest 10, pubkey 1, last=1 
:literal data packet: 
    mode b (62), created 1484956450, name="sign.txt", 
    raw data: 15 bytes 
gpg: original file name='sign.txt' 
:signature packet: algo 1, keyid 3C6EF65B2F7DEF69 
    version 4, created 1484956450, md5len 0, sigclass 0x00 
    digest algo 10, begin of digest 98 8e 
    hashed subpkt 2 len 4 (sig created 2017-01-20) 
    subpkt 16 len 8 (issuer key ID 3C6EF65B2F7DEF69) 
    data: [4092 bits] 
gpg: Signature made Fri Jan 20 15:54:10 2017 PST using RSA key ID 2F7DEF69 
gpg: using PGP trust model 
gpg: key 00D026C4: accepted as trusted key 
gpg: key 51BF2B79: accepted as trusted key 
gpg: key 2F7DEF69: accepted as trusted key 
gpg: Good signature from "Andy LoPresto <[email protected]>" [ultimate] 
gpg:     aka "Andy LoPresto <[email protected]>" [ultimate] 
gpg: binary signature, digest algorithm SHA512 
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto 
10s @ 15:54:22 $ 

Обратите внимание, что операция подписи не шифрует сообщений (вы можете увидеть открытый текст сообщения в файле подпись), и что подпись использует базовую хэш-функцию SHA-512 (отображается, если вы подтвердите с помощью -vvv).

Что касается вашего второго вопроса, тайна предварительного мастерства никогда не делится по открытым каналам. Он выводится на обеих сторонах канала независимо друг от друга с использованием совместно используемого материала (т. Е. Nonce и т. Д.). Это можно сделать с помощью (ephemeral) Diffie-Hellman Key Exchange (иначе «смешивание краски») или другого процесса. Если для обмена ключами используется необработанный RSA, клиент отправляет зашифрованный зашифрованный с открытым ключом сервера, чтобы обеспечить секретный ключ.

Чтобы полностью понять процесс рукопожатия TLS, прочитайте this explanation by Thomas Pornin (лучшее, что я когда-либо видел). Как только вы прочтете это, IETF RFC 5246 (TLS 1.2) будет иметь гораздо больше смысла, и вы можете попасть в сорняки, если хотите.

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

  • Нет связанных вопросов^_^