FAQ обзорная информация по емаил сертификатам s/mime
Електронний цифровий підпис (ЕЦП) – це блок інформації,
який додається до файлу даних автором (підписувачем) та захищає файл від несанкціонованої
модифікації і вказує на підписувача (власника підпису).
Для функціонування ЕЦП використовуються 2 ключі захисту (які
зберігаються в різних файлах):
Таємний ключ, який зберігається у підписувача (наприклад,
на дискеті, пристрої Touch Memory, Smart-карті і т.і.)
Відкритий ключ, який, як правило, публікується в загальнодоступному
або спеціалізованому довіднику.
Для накладання ЕЦП використовується таємний (особистий) ключ,
а для його для перевірки – відкритий (загальновідомий) ключ.
Алгоритм роботи системи побудовано таким чином, що маючи доступ
до відкритого ключа неможливо відтворити таємний ключ або поставити цифровий
підпис – його можна тільки перевірити.
Доцільно зазначити, що таємний (особистий) ключ підписувача
є повною особистою власністю підписувача і не надається будь-яким іншім особам
(навіть центру сертифікації ключів). Будь-хто може перевірити цифровий підпис,
використовуючи тільки відкритий ключ.
Накладання електронного цифрового підпису (підписування)
- це операція, яка здійснюється відправником (підписувачем) документу із використанням
його таємного ключа. При виконанні цієї операції на вхід відповідної програми
подаються данні, які треба підписати, та таємний ключ підписувача. Програма створює
із даних за допомогою таємного ключа унікальний блок даних фіксованого розміру
(власне ЕЦП), який може бути справжнім тільки для цього таємного ключа та саме
для цих вхідних даних. Тобто, ЕЦП – це своєрідний "цифровий відбиток таємного
ключа і документа".
В подальшому ЕЦП, як правило, додається до вхідного документа
(або розміщується в окремому полі документу) і така комбінація даних (документ
+ ЕЦП) утворює захищений електронний документ.
Перевірка електронного цифрового підпису – це операція,
яка виконується отримувачем захищеного електронного документу з використанням
відкритого ключа підписувача (відправника). Для виконання цієї операції необхідно
отримати відкритий ключ відправника (наприклад, із довідника)
та захищеного документа (тобто даних документа та даних ЕЦП). Відповідний програмний
модуль перевіряє, чи дійсно цифровий підпис відповідає документу та відкритому
ключу. Якщо в документ або у відкритий ключ внесено будь-які зміни, перевірка
закінчиться із негативним результатом.
Для повноцінного функціонування систем ЕЦП необхідно забезпечити доступ
отримувача до достовірної копії відкритого ключа відправника (підписувача) та
можливість перевірити, що ця копія відкритого ключа належить саме цьому підписувачу.
Для виконання цього створюються спеціальні захищені довідники ключів, які ведуться
спеціальними установами – центрами сертифікації ключів.
Импорт публичного сертификата отправителя (сертификат / идентификатор отправителя).
Импортирование обычно происходит автоматически в момент открытия письма отправителя
Центри сертифікації ключів перевіряють дані власника
відкритого ключа та видають захищені електронні документи спеціального зразка
– сертифікати відкритих ключів, в яких міститься відкритий ключ та перевірена
центром сертифікації інформація про власника ключа. Сертифікат відкритого ключа
підписується електронним цифровим підписом центру сертифікації ключів. Таким
чином, достатньо отримати достовірним каналом лише один електронний документ
– сертифікат самого центру сертифікації ключів, щоб мати можливість перевірити
достовірність будь-якого сертифікату, що виданий цим центром сертифікації ключів.
Генерація таємного та відкритого ключів ЕЦП - початкова
процедура, яка виконується користувачем до виконання процедури сертифікації
відкритого ключа. Генерацію виконує спеціалізоване програмне забезпечення –
генератор ключів, який надається центром сертифікації ключів.
Для виконання сертифікації відкритого ключа до центру сертифікації подається:
Електронний документ спеціального зразка – заявка на сертифікацію відкритого
ключа, яка містить відкритий ключ та електронну картку із реквізитами власника
ключа. Заявка генерується спеціальною програмою – генератором ключів.
Комплект документів, що засвідчує особу власника ключа (для посадових
ключів юридичних осіб додатково додаються документи, що засвідчують правомочність
власника ключа діяти від імені юридичної особи).
Правила сертифікації – документ, в якому описані індивідуальні для кожного
центру сертифікації правила, за якими перевіряються відомості, що знаходяться
в сертифікаті. Тобто, не всі центри сертифікації ключів діють за однаковими
правилами та вимогами при перевірці документів, що встановлюють особу-власника
ключа (ці правила також називаються "політикою сертифікації").
Кількість перевірок та їх ретельність може бути різною в різних
центрах сертифікації ключів. Значна кількість центрів сертифікації використовують
декілька політик сертифікації одночасно, тобто видають сертифікати різних рівнів
довіри (ці рівні довіри іноді називаються «класами сертифікатів»). Існування
різних класів сертифікатів обумовлено різницею у їх вартості (більшій рівень довіри потребує більше перевірок,
більше перевірок – більше роботи, більше роботи – більша вартість).
Правила сертифікації, якими користується центр сертифікації,
та клас сертифікату безумовно безпосередньо впливають на рівень довіри до
сертифікатів ключів, які видані такими центрами сертифікації.
Тобто, довіра до сертифікату відкритого ключа залежить не
тільки від того факту, що відкритий ключ сертифіковано, а також від того, ким (яким
центром сертифікації) сертифіковано та за якими правилами (політика та клас
сертифікату).
В загальному випадку політика сертифікації та перелік
класів сертифікатів індивідуальні для кожного центру сертифікації. Для стандартизації
в цій галузі в багатьох країнах (в тому числі в Україні) водиться регульоване
законодавством поняття «Посилений сертифікат ключа» - тобто сертифікат,
виданий із додержанням певних стандартизованих та затверджених законом вимог
та правил (в тому числі - правил щодо проведення процедури засвідчення особи –
власника ключа). Для того щоб мати право видавати сертифікати
такого зразка, центри сертифікації мають пройти процедуру акредитації (засвідчення відповідності вимогам законодавства). Акредитований центр сертифікації має право видавати
посилені сертифікати ключів. Перелік акредитованих центрів сертифікації ведеться
Центральним засвідчувальним органом.
S/MIME - Secure/Multipurpose Internet Mail Extensions
S/MIME (RFC2630, 2632, 2633, 2634) "Secure/Multipurpose Internet Mail Extensions" является стандартом, позволяющим
использовать X.509 - сертификаты для защиты вашего e-mail-обмена. X.509 - сертификаты широко применяются также
для защиты других электронных коммуникаций, таких как HTTP и др. Таким образом, один и тот же сертификат
используется в различных целях и разным програмным обеспечением.
S/MIME представляет собой реализацию криптографической системы с асимметричным ключом. Система может быть
использована как для внедрения так называемой digital signature (электронной подписи) в ваши почтовые сообщения,
так и для шифрования последних. Поддерживается также комбинация двух вышеперечисленных методов. Система с
асимметричным ключом отличается от традиционной (работающей с симметричным ключом), в первую очередь, тем,
что вам не придется сообщать вашему корреспонденту по телефону или каким-либо иным методом пароль, который вы
использовали для пересылки ему секретных сведений: система с асимметричным ключом сделает это за вас. Все, что
вам надо иметь, чтобы послать такие сведения - это публичную часть S/MIME-сертификата вашего адресата, т.е. ту его
часть, которая ни в коем случае секретом не является (напротив, чем большее количество людей будет иметь у себя
публичную часть вашего S/MIME-сертификата, тем лучше!). Разумеется, ваш корреспондент должен иметь и секретную
часть своего S/MIME-сертификата, иначе он не сможет дешифровать тот текст, что вы ему пошлете (как не сможет этого
сделать и никто другой, не имея секретной части его S/MIME-сертификата).
Для использования возможностей S/MIME, прежде всего, вам необходимо получить "сертификат"
Вы должны защищать свой сертификат от несанкционированного доступа, и уж в любом случае не сообщать никому пароль,
которым защищен ваш сертификат.
В случае применения электронной подписи подписанное сообщение передается в "читабельной" форме, т.е. в
нешифрованном виде, однако получатель письма имеет возможность убедиться в том, что автором сообщения и в самом
деле являетесь вы, а главное - возможность убедиться в том, что данное сообщение никем не было изменено "по дороге".
При этом получателю письма для подобной проверки не требуется никакой дополнительной информации, так как публичная
часть S/MIME-сертификата отправителя подписанного письма (необходимая для процесса "сверки" подписи) передается
вместе с подписанным письмом. Такие электронным образом подписанные сообщения уже на протяжении нескольких
лет принимаются судами ряда западных стран в качестве свидетельских показаний.
В случае использования шифрованных сообщений прочитать текст письма сможет лишь тот человек, кому Вы отправляете письмо..
В случае применения комбинации обоих методов означает, что прочитать ваше сообщение сможет лишь тот, кому оно предназначено,
и он же сможет убедиться в том, что сообщение и в самом деле написано вами.
Вот как описывает цп Джефф Просис в журнале PC Magazine
Цифровая подпись: принципы работы
Представьте себе ситуацию: вам отправили по
электронной почте документ с конфиденциальной
информацией по финансированию на будущий год. Вам
необходима абсолютная уверенность в том, что полученный
файл совершенно идентичен оригиналу и содержащиеся в
нем цифры не были изменены "в пути". Пара
скорректированных значений могут стоить вашей фирме
круглой суммы. Подозрение, что документ "в пути" был
подделан появляется если некоторые цифры не сходятся, а
электронная передача велась через внешнюю почтовую
систему. Как убедит ся в том, что полученный вами
документ - абсолютная копия отправленного вам
оригинала?
Рассмотренная ситуация не настолько искуственна, как
может показаться с первого взгляд . В век, когда
цифровая коммерция быстро становится реальностью,
доверие пользователей к подобного рода системам целиком
зависит от безопасности таких транзакций. Если
отправить по электронной почте или передать на гибком
диске файл с электронной таблицей, то каким образом
получатель узнает о том, что никто, через кого эта
информация прошла, не внес каких-либо изменений? Если
переслать по сети Internet номер своей кредитной
карточки, то как адресат убедится в том, что именно вы
сделали этот заказ?
Решение этих вопросов придется искать в специальном
разделе математики, который называют криптографией. Часто
под этим термином подразумевается обычное кодирование,
однако область криптографии не ограничена лишь теорией
шифрования данных. Она также охватывает вопросы,
связанные с подменностью цифровых данных - как
проверить достоверность цифровых данных и как по
аналогии с рукописной подписью на бумаге проставить
визу на электронных документах, имея в распоряжении
лишь последовательности нулей и единиц. В этой статье
рассматриваются ключевые понятия аутентификации
цифровой информации - от простейших методов верификации
целостности цифровых данных до рассмотрения проекта
государственного стандарта США - Digital Signature
Standard, а также основные правила оформления цифровой
подписи.
Контрольные суммы
Наиболее простой способ проверки целостности данных,
передаваемых в цифровом представлении, - это метод
контрольных сумм. Под контрольной суммой понимаетс
некоторое значение, рассчитанное путем сложения всех
чисел из входных данных. Если сумма всех чисел
превышает максимально допустимое значение, заранее
заданное для этой величины, то величина контрольной
суммы равна коэффициенту полученной суммы чисел - то
есть это остаток от деления итоговой суммы на
максимально возможное значение контрольной суммы,
увеличенное на единицу. Если сказанное записать в виде
формулы, то для расчета контрольной суммы будет
использоваться следующее выражение:
Checkssum = Total % (MaxVal + 1)
где Total - итоговая сумма, рассчитанная по входным
данным, и MaxVal - максимально допустимое значение
контрольной суммы, заданное заранее.
Допустим, документ, содержимое которого предстоит
верифицировать, представляет собой следующую
последовательность величин, длиной 10 байт:
36 211 163 4 109 192 58 247 47 92
Если контрольная сумма 1 байт величина, то
максимальное число, которое она может содержать, равно
255 Для приведенного выше документа сумма всех его
чисел равно 1159. Таким бразом, 8-разрядов контрольной
суммы будут содержать остаток от деления числа 1159 на
256, то есть 135. Если контрольная сумма, рассчитанна
отправителем док мента, равнялась, скажем, 246, а после
получения она имеет значение 135, значит, информаци
подверглась изменению. Метод контрольных сумм - это
наиболее простая форма цифровой идентификации (digital
fingerprint); то есть величина, полученная в результате
подсчета содержимого некоторых других данных,
изменяется при коррекции данных, на основе которых он
получен. Использование алгоритма контрольных сумм
началос еще на заре вычислительной техники и до сих
пор он является базовым при проверке на ошибки в
некоторых версиях широко распространенного протокола
передачи данных XMODEM.
Недостаток метода контрольных сумм заключается в
том, что хотя несовпадение значений этих сумм служит
верным доказательством, что рассматриваемый документ
подвергся изменению, равенство сравниваемых значений
еще не дай гарантии, что информация осталась
неизменной. Можно произвольным образом изменить порядок
ледования чисел в документе, а контрольная сумма при
этом сохранит прежнее значение. И что еще хуже - можно
изменить отдельные числа в документе и подогнать
остальные таким образом, чтобы обеспечить прежнее
значение контрольной суммы. При использовании дл
контрольных сумм 8-разрядной переменной вероятность
того, что контрольные суммы двух совершенно случайно
выбранных последовательностей данных будут одинаковы,
равна 1/256. При увеличении длины переменной под
контрольную сумму до 16 или 32 разрядов, вероятность
совпадений уменьшается, однако этот механизм все равно
слишком чувствителен к возможным ошибкам, чтобы
обеспечить высокую степень доверия к представленным
данным.
Контроль CRC
Более совершенный способ цифровой идентификации
некоторой последовательности данных - это вычисление
контрольного значения ее циклического избыточного кода
(cyclic redundancy check - CRC). Алгоритм контроля CRC
уже в течение длительного времени широко используется в
системах сетевых адаптеров, контроллеров жесткого диска
и других устройств для проверки идентичности входной и
выходной информации. А также этот механизм применяетс
во многих из ныне существующих коммуникационных
программ для выявления ошибок при пакетной передаче по
телефонным линиям связи.
Механизм CRC основан на полиномиальном распределении, где каждый разряд некоторой порции
данных соответствует одному коэффициенту большого
полиномиального выражения. Напомним, что полиномом
называется математическое выражение, представленное
следующим образом:
f(x) = 4x3 + x2 + 7
Для выполнения расчетов контроля CRC полином,
представляющий байт данных со значением 85 (8-разрядный
двоичный эквивалент которого - 01010101) выглядит так:
0x7 + 1x6 + 0x5 + 1x4 + 0x3 + 1x2 + 0x1 + 1x0
или просто
x6 + x4 + x2 + 1
Ключевым принципом вычислений для механизма CRC
является то, что операции умножения и деления этих
полиномов выполняются точно так же, как с обычными
числами. Если некоторый "магический" полином
(коэффициенты которого получены в соответствии с
используемым алгоритмом CRC) разделить на полином,
представляющий какую-то последовательность данных, то в
результате получается полином-частное и
полином-остаток. Второе из этих значений служит основой
для создания контрольного параметра CRC. Так же, как и
для контрольных сумм, параметром CRC не требуется много
места (обычно их длина составляет 16 или 32 разряда);
однако по сравнению с ними, надежность обнаружени
небольших изменений входной информации теперь
значительно выше. Если в некотором огромном блоке
данных лишь один разряд стал другим, то и контрольный
параметр CRC со 100-процентной вероятностью также будет
иметь другое значение. Если же изменятся два разряда,
то вероятность обнаружения ошибки при длине параметра
CRC в 16-разрядов, составляет более 99,99%. В отличие
от контрольных сумм метод CRC сможет распознать всякие
фокусы с перестановкой двух байт либо с добавлением 1 к
одному из них и вычитанием 1 из другого.
Механизм CRC чрезвычайно полезен для проверки
файлов, загружаемых из сетевых информационных служб.
Если кто-то сообщает мне, что переданная ему через сеть
ZD Net утилита вдруг без видимой причины перестает
работать, то первым делом я прошу его создать ее
архивный файл с помощью программы PKZIP и набрать
команду PKZIP -V для просмотра созданного .ZIP файла.
Среди прочих параметров он увидит также 32-разрядное
значение параметра CRC, рассчитанное программой PKZIP
для несжатого файла. Если вычисленное значение
параметра CRC для gjkextyyjq утилиты не совпадает со
значением для исходного варианта файла, значит, при
загрузке его произошла необнаруженная ошибка передачи
данных (такое иногда случается).
Можно организовать собственный контроль CRC для
идентификации файлов; для этого потребуется переписать
через службу PC Magazine Online файл CRC.COM. (Он
находится в библиотеке Tutor форума Utilities/Tips
службы ZD Net/CompuServe и в файле V15N07.ZIP на нашем
сервере Internet по адресу http://www.pcmag.com
CRC.COM - это утилита DOS, которой в качестве входного
параметра указывается имя файла. Исходя из содержащейс
в нем информации она рассчитывает 32-разрядное значение
контроля CRC. В программе использован известный
алгоритм расчета параметра CRC-32, применяемый PKZIP и
сетевых адаптерах Token-Ring фирмы IBM. Этот алгоритм
отличается высоким быстродействием (исходный текст
полностью написан на языке ассемблера; производитс
буферизация при чтении/записи с диска; прекрасно
реализован алгоритм расчета CRC-32 - все это позволяет
сократить до минимума объем производимых вычислений) и
обработает файлы любого размера. Теперь при пересылке
файлов через модем утилита CRC.COM сможет оказать вам
неоценимую услугу - дать уверенность, что информаци
передана без искажений.
Получив по сети файл CRC.COM, первым делом проверьте
сам этот файл, набрав в строке DOS команду:
CRC CRC.COM
Если полученное значение параметра CRC не равно
86C23FA, значит файл следует загрузить снова.
Алгоритмы хэширования
Проблема в том, что даже контроль с помощью
32-разрядного значения CRC обладает определенными
недостатками - он устойчиво обнаруживает случайные
изменения во входной информации (например, возникающие
в результате сбоев при передаче данных), однако
недостаточно надежен в случае преднамеренных действий.
Если для идентификации некоторого файла вы используете
его 32-разрядный параметр CRC, то для кого-то не так уж
сложно с помощью компьютера создать совершенно другой
файл с тем же значением CRC.
Более высокой надежности, чем при контроле CRC,
можно достичь при использовании односторонних
алгоритмов хэширования; результатом их работы являютс
особые "хэшированные" значения. Под термином
"односторонние" понимается следующее: имея на входе А,
можно без особого труда получить на выходе В, но
сделать обратное - то есть из В получить А -
невозможно, или, во всяком случае, практически
невозможно. Важная отличительная особенность любого
хорошего алгоритма хэширования заключается в том, что
генерируемые с его помощью значения настолько уникальны
и трудноповторимы, что вряд ли кто-то даже с помощью
серии суперкомпьютеров Cray и затратив колоссальное
количество времени, сможет найти два набора входных
данных, имеющих одинаковые значение хэширования. Как
правило, эти параметры занимают не менее 128 разряды.
Чем больше их длина, тем труднее воспроизвести входной
набор данных, то есть найти последовательность,
обеспечивающую соответствующий результат.
Среди односторонних алгоритмов хэшировани
наибольшей известностью пользуются два из них: алгоритм
MD5 (message digest), разработанный профессором
Массачусетского технологического института Роном
Ривестом (Ron Rivest) (один из авторов популярной
криптосистемы с ключом общего пользования RSA), и
алгоритм Secure Hash Algorithm (SHA), созданный
совместными усилиями Национального института по
стандартизации и технологическим разработкам (NIST) и
Управления национальной безопасности США (NSA).
Результат анализа последовательности входных данных с
помощью алгоритма MD5 - 128-разрядный цифровой
идентификатор, а при использовании алгоритма SHA -
160-разрядное значение. Учитывая, что пока никому не
удалось подобрать ключ ни к одному из названных
алгоритмов, можно считать, что восстановление исходных
данных по некоторому хэшированному значению,
являющемуся результатом работы алгоритма SNA либо по
некоторому коэффициенту алгоритма MD5 нереально. Таким
образом, если вам отправили какой-то файл и
идентификатор, полученный в результате применения к
нему алгоритма MD5 или SHA, и если вы выполнили с ним
тот же алгоритм хэширования и ваш результат совпал с
исходным значением, определенно можно быть уверенным,
что принятый вами файл не подвергся искажениям.
Цифровая подпись и криптосистемы с ключом общего пользования
Если использовать алгоритмы хэширования вместе с
криптосистемами с ключом общего пользования, то можно
создать цифровую подпись, гарантирующую подлинность
полученного набора данных, аналогично тому, как
рукописная подпись, подтверждает аутентичность
напечатонного документа. Криптосистема с ключом общего
пользования - это метод, позволяющий осуществлять
кодирование и декодирование информации, с помощью двух
исходных ключей: ключа общего пользования, свободно
передаваемого всем желающим, и личного ключа,
известного только его владельцу.
Смысл ключа и пароля примерно одинаков. Допустим,
Том желает, чтобы Сэм мог отправить ему зашифрованный
документ, и оба они не хотели бы рисковать, передава
пароль или ключ по линиям связи, так как в этом случае
он может быть кем-то перехвачен. Тогда Том может
передать Сэму свой ключ общего пользования (схема 1).
Используя этот ключ, Сэм шифрует документ и отправляет
его Тому. Том дешифрует документ с помощью своего
личного ключа. Это единственный ключ, с помощью
которого можно восстановить документ, зашифрованный с
применением ключа общего пользования, принадлежащего
Тому. Тот факт, что ключ общего пользования Тома может
стать кому-то известен, не имеет особового значения,
потому что он абсолютно бесполезен для расшифровки
документа. А личный ключ, известный одному лишь Тому,
по открытым линиям связи не передавался; теоретически
том хранит его только в собственной памяти и наоборот,
работа других криптосистем с ключом общего пользовани
строится на обратном принципе: Сэм шифрует документ с
помощью своего личного ключа и передает свой ключ
общего пользования Тому, с помощью которого тот мог бы
расшифровать этот документ. Существующие ныне
криптосистемы с ключом общего пользования, такие,
например, как система RSA (сокращение, составленное из
первых букв фамилий трех создателей этого алгоритма),
широко используются.
Как же осуществляется цифровая подпись? Рассмотрим
еще один пример. Допустим, Сэм собирается отправить
Тому контракт или номер своей кредитной карточки в
цифровом виде. Для подтверждения подлинности этих
документов Тому необходима цифровая подпись Сема.
Сначала Сэм отправляет свой документ. Затем использует
алгоритм хэширования для вычисления идентификаторf
этого документа, шифрует хэшированное значение с
помощью своего личного ключа и отправляет его Тому. Это
и есть цифровая подпись Сэма. Том с помощью того же
алгоритма хэширования сначала вычисляет идентификатор
принятого документа. Затем он расшифровывает значение,
которое получил от Сэма, используя предоставленный
Сэмом ключ общего пользования. Если два значени
хэширования совпали, Том не только узнает, что этот
документ подлинный, но и то, что подпись Сэма
действительна. Понятно, что проведение коммерческих
транзакций по такому сценарию значительно безопаснее,
чем с использованием подписи от руки на бумаге, которую
можно подделать. А если сведения, передаваемые Сэмом
Тому, конфиденциальны (например, содержат номер
кредитной карточки), то и их можно зашифровать так,
чтобы прочитать их смог только Том.
Схема. Система цифровой подписи.
Сэм обрабатывает по специальному алгоритму
документ, который собирается отправить Тому, в
результате получает некоторый параметр,
рассчитанный на основании содержимого документа.
Обычно это занимает значительно меньше места, чем
исходный документ - параметр 128 или 160 двоичных
разрядов.
Затем Сэм с помощью своего личного ключа шифрует
полученный параметр. Итоговое значение служит
цифровой подписью Сэма.
Сэм отправляет Тому документ и свою цифровую
подпись.
Том пропускает документ, полученный от Тома,
через тот же алгоритм, которым пользовался Том.
Затем Том дешифрует цифровую подпись, полученную
от Сэма, пользуясь предоставленным Сэмом ключом
общего пользования.
Том сравнивает значение параметра, полученного
при выполнении операции 4, с расшифрованным
значением цифровой подписи. Если эти значени
совпадают, значит, подпись подлинная и документ "в
пути" не подвергся изменениям. В противном
случае, либо документ искажен, либо подпись
подделана, либо и то и другое.
Вероятнее всего именно по такой, или подобной схеме
будут вестись дела через Internet или любую другую
информационную службу. Этот алгоритм послужил основой
проекта государственного стандарта США - Digital
Signature Standard (DSS). В нем применяются: алгоритм
Secure Hash Algorithm для расчета параметров
хэширования и криптосистема с ключом общего
пользования, известная под названием Digital Signature
Algorithm (DSA) и предназначенная для получени
цифровой подписи по параметрам хэширования. Ряд пунктов
проекта DSS подверглись критике, однако многие из
замечаний исходили от групп, финансово заинтересованных
в отклонении данного проекта.
Время покажет, будет ли какой-либо из методов
создания цифровой подписи принят в качестве стандарта.
Однако вне зависимости от результата, важно другое:
действительно существует возможность совершенно
безопасно осуществлять цифровые торговые.