Цифровий підпис

Цифровая підпис.

Цифровая підпис: принципи роботи.

Контрольные суми, контроль CRC, хэширование і цифрова підпис — базові кошти аутентифікації при цифровій передачі даних. Уявіть собі ситуацію: вам відправили електронною поштою документ з конфіденційної інформацією з фінансуванням наступного року. Вам потрібна цілковита у тому, який отримав файл скоєно ідентичний оригіналу і що у ньому цифри були змінені «їсти дорогою ». Кілька скоригованих значень можуть коштувати вашої фірмі круглої суми. Підозра, що він «їсти дорогою «було фальсифіковано з’являється коли деякі цифри не сходяться, а електронна передача велася через зовнішню поштову систему. Як переконається у цьому, який отримав вами документ — абсолютна копія відправленого вам оригіналу?

Рассмотренная ситуація так штучна, як здається з першого погляд. У добу, коли цифрова комерція швидко стає реальністю, довіру користувачів до такого роду системам повністю залежить від безпеки таких транзакцій. Якщо відіслати електронної пошти або на гнучкому диску файл з електронною таблицею, хоч чином одержувач дізнається у тому, що ніхто, через кого цю інформацію пройшла, не вніс жодних змін? Якщо переслати через мережу 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) = 4×3 + x2 + 7.

Для виконання розрахунків контролю CRC поліном, що становить байт даних із значенням 85 (8-разрядный двоїчний еквівалент якого — 1 010 101) така:

0x7 + 1×6 + 0×5 + 1×4 + 0×3 + 1×2 + 0×1 + 1×0.

или просто.

x6 + x4 + x2 + 1.

Ключевым принципом обчислень для механізму CRC і те, що операції множення і розподілу цих полиномов виконуються точно як і, і з звичайними числами. Якщо певний «магічний «поліном (коефіцієнти якого одержані відповідність до що використовуються алгоритмом CRC) розділити на поліном, що становить якусь послідовність даних, то результаті виходить полином-частное і полином-остаток. Друга з цих значень є підставою до створення контрольного параметра CRC. Також, як й у контрольних сум, параметром CRC непотрібен велике місце (зазвичай їх довжина становить 16 чи 32 розряду); проте за порівнянню із нею, надійність виявлення невеликих змін вхідний інформації тепер значно вища. Якщо деякому величезному блоці даних лише одне розряд став інакшим, те й контрольний параметр CRC зі 100-відсоткової ймовірністю також мати інше значення. Якщо ж зміняться два розряду, то можливість виявлення помилки при довжині параметра CRC в 16-разрядов, становить понад 99, 99%. На відміну від контрольних сум метод CRC зможе розпізнати всякі фокуси з перестановкою двох байт або з додаванням 1 до жодного з неї і відніманням 1 з іншого.

Механизм CRC надзвичайно корисним для перевірки файлів, загружаемых із мережних інформаційних служб. Якщо хтось повідомляє мене, що передана йому через мережу ZD Net утиліта раптом без видимої причини перестає працювати, то відразу ж я прошу його створити її архівний файл з допомогою програми PKZIP і набрати команду PKZIPV для перегляду створеного. ZIP файла. Серед інших параметрів він побачить також 32-разрядное значення параметра CRC, розраховане програмою PKZIP для несжатого файла. Якщо розрахований значення параметра CRC для gjkextyyjq утиліти не збігається.

со значенням для вихідного варіанта файла, отже, за мінімального завантаження його відбулася необнаруженная помилка передачі (таке інколи трапляється).

Можно організувати власний контроль CRC для ідентифікації файлів; цього доведеться переписати через службу PC Magazine Online файл CRC. COM. (Він перебуває у бібліотеці Tutor форуму Utilities/Tips служби ZD Net/CompuServe й у файлі V15N07. ZIP (на сервері за адресою internet 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, і коли ви виконали з нею хоча б алгоритм хэширования і ваших результат припала на вихідним значенням, точно можна бути впевненим, що ухвалений вами файл не піддався спотворень.

Алгоритм MD5.

Терминология.

В тому випадку «word «є 32-х бітної величиною, «byte «- 8-місячного бітна величина. Послідовність біт повинна інтерпретуватися так само як і послідовність байт, де кожна послідовна група восьми біт інтерпретується як байт з старшим (найбільш значущою) битому кожного байта наступним в послідовності першим. Подібно послідовності байт повинна інтерпретуватися і послідовність 32-бітних слів.

Запись x_i означає «x sub і «(т. е. x з індексом і). Якщо деяке вираз використовують як індекс, воно береться в фігурні дужки, наприклад x_{i+1}. Символ «^ «використовується для операцій спорудження до рівня, т. е. x^i слід розуміти, як x певною мірою і.

Символ «+ «позначає операцію складання слів (т. е. складання по модулю 2³²). Далі x (32-(n)))).

Если n > 32, то результат нульовий.

Функции.

void MD5Init (MD5_CTX *mdContext).

Функция MD5Init (MD5_CTX *mdContext) виконує ініціалізацію деяких полів структури Message Digest MD5_CTX Як параметра функція отримує покажчик на структуру MD5_CTX.

{.

/* Обнуління полів, які утримувати довжину повідомлення */.

mdContext->i[0] = mdContext->i[1] = (UINT4)0;

/* Завантаження магічних констант ініціалізації. */.

mdContext->buf[0] = (UINT4)0×6 745 2301L;

mdContext->buf[1] = (UINT4)0xefcdab89L;

mdContext->buf[2] = (UINT4)0×98badcfeL;

mdContext->buf[3] = (UINT4)0×1 032 5476L;

}.

void MD5Update (register MD5_CTX *mdContext, unsigned char *inBuf, unsigned int inLen).

Данная функція обробляє вміст структури MD5_CTX.

В ролі параметрів функція отримує:

Покажчик mdContext на структуру MD5_CTX;

Cимвольный буфер inBuf[], який містить символи вихідного повідомлення, чий Message Digest ми підраховуємо; Довжину inLen переданого буфера.

Вначале підраховується целочисленная величина mdi:

mdi = (int)((mdContext->i[0] >> 3) & 0x3F);

Эта величина дорівнює довжині сполучення байтах по модулю 64. Довжина сполучення бітах зберігається у структурі MD5_CTX в буфері i[0.. 1].

Длина сполучення бітах заноситься в буфер i[0.. 1] так:

mdContext->i[0] += ((UINT4)inLen i[1] += ((UINT4)inLen >> 29);

Следующий ділянку коду виконує такі дії:

while (inLen—).

{.

/* додаємо новий символ в буфер, инкрементируя mdi */.

mdContext->in[mdi++] = *inBuf++;

/* Якщо потрібно виконуємо перетворення */.

if (mdi == 0×40).

{.

for (і = 0, ii = 0; і < 16; і++, ii += 4).

in[i] = (((UINT4)mdContext->in[ii+3]) in[ii+2]) in[ii+1]) in[ii]);

Transform (mdContext->buf, in);

mdi = 0;

}.

}.

Пока уменьшаемая на 1 довжина переданого до функцій повідомлення стане рівної нулю виконуємо такі дії:

Заносим новий символ з вхідного буфера функції в 64-х байтный буфер структури MD5_CTX, збільшуючи у своїй зміну mdi на 1. Якщо mdi дорівнює 64, то перетворимо.

однобайтные символи буфера in[] структури MD5_CTX в 4-х байтные величини типу UINT4, заносимо у проміжний буфер на 16 величин типу UINT4, і далі передаємо функції Transform (). Привласнюємо перемінної mdi 0.

void MD5Final (MD5_CTX *mdContext).

Функция завершує обчислення Message Digest і заносить отримане значення у структурі MD5_CTX в символьний буфер digest[0... 15].

Входным параметром функції є покажчик на структуру MD5_CTX.

Основные моменти:

Расширение повідомлення додатковими заполняющими символами з таблиці PADDING[].

/* Підрахунок довжини сполучення байтах по модулю 64 */.

mdi = (int)((mdContext->i[0] >> 3) & 0x3F);

/* Розширити до 56 по модулю 64 */.

padLen = (mdi < 56)? (56 — mdi): (120 — mdi);

MD5Update (mdContext, PADDING, padLen);

Присоединение бітов довжини і виклик функції Transform ().

in[14] = mdContext->i[0];

in[15] = mdContext->i[1];

for (і = 0, ii = 0; і < 14; і++, ii += 4).

in[i] = (((UINT4)mdContext->in[ii+3]) in[ii+2]) in[ii+1]) in[ii]);

Transform (mdContext->buf, in);

Сохранение буфера в digest (т. е. отримання остаточного Message Digest):

for (і = 0, ii = 0; і < 4; і++, ii += 4).

{.

mdContext->digest[ii] = (unsigned char)(mdContext->buf[i] & 0xFF);

mdContext->digest[ii+1] = (unsigned char)((mdContext->buf[i] >> 8) & 0xFF);

mdContext->digest[ii+2] = (unsigned char)((mdContext->buf[i] >> 16) & 0xFF);

mdContext->digest[ii+3] = (unsigned char)((mdContext->buf[i] >> 24) & 0xFF);

}.

void Transform (register UINT4 *buf, register UINT4 *in).

Данная функція є основним кроком у алгоритмі MD5.

Входными параметрами є покажчик на буфер buf[] зі структури MD5_CTX і покажчик на буфер in[], що зберігає значення типу UINT4. Функція виконує 4 циклу по 16 кроків у кожному. У кожному циклі використовується одне з функцій FF, GG, HH, II. Далі оцінку після 64-х преосвітніх ітерацій додається до буфера buf[].

Структура MD5_CTX.

Структура MD5_CTX є основним структурою на формування MessageDigest. Структура містить такі поля:

typedef struct.

{.

UINT4 i[2]; /* кількість біт у міжнародному сполученні по mod 2⁶⁴ */.

UINT4 buf[4]; /* тимчасовий буфер */.

unsigned char in[64]; /* вхідний буфер */.

unsigned char digest[16]; /* містить дійсний Message Digest.

після виклику MD5Final () */.

} MD5_CTX;

Цифровая підпис і криптосистемы з ключем загального користування.

Если використовувати алгоритми хэширования разом із криптосистемами з ключем загального користування, можна створити цифрову підпис, яка гарантуватиме справжність отриманого набору даних, аналогічна тій, як рукописна підпис, підтверджує автентичність надрукованого документа. Криптосистема з ключем загального користування — це метод, дозволяє здійснювати кодування і декодування інформації, з допомогою двох вихідних ключів: ключа загального користування, вільно переданого всім бажаючим, й особистого ключа, відомого лише його власника.

Смысл ключа і пароля приблизно однаковий. Припустимо, Том хоче, щоб Сем міг відправити йому зашифрований документ, і вони хотів б ризикувати, передаючи пароль чи ключ лініями зв’язку, позаяк у цьому випадку то, можливо кимось перехоплений. Тоді Том може передати Сему свій ключ загального користування (схема 1).

Используя цей ключ, Сем шифрує документ і посилає його Тому. Том дешифрує документ з допомогою свого особистого ключа. Це єдиний ключ, з допомогою якого відновити документ, зашифрований із застосуванням ключа загального користування, належить Тому. Факт, що ключ загального користування Тома може бути комусь відомий, немає особливого значення, оскільки він цілком непотрібний для розшифровки документа. А особистий ключ, відомий одному лише Тому, по відкритим лініях зв’язку не передавався; теоретично тому зберігає його лише у власної пам’яті і навпаки, робота інших криптосистем з ключем загального користування будується на зворотному принципі: Сем шифрує документ з допомогою свого особистого ключа і передає свій ключ загального користування Тому, з допомогою що його та міг би розшифрувати цей документ ще. Існуючі нині криптосистемы з ключем загального користування, такі, наприклад, як система RSA (скорочення, складене із перших літер прізвищ трьох творців цього алгоритму), широко використовуються.

Как ж здійснюється цифрова підпис? Розглянемо іще одна приклад. Припустимо, Сем збирається відправити Тому контракт чи номер своєї кредитної картки в цифровому вигляді. На підтвердження дійсності цих документів Тому необхідна цифрова підпис Сема. Спочатку Сем відправляє свій документ. Потім використовує алгоритм хэширования для обчислення ідентифікатора Основних напрямів, шифрує хэшированное значення з допомогою свого особистого ключа і посилає його Тому. Це і цифрова підпис Сема. Том з допомогою тієї самої алгоритму хэширования спочатку обчислює ідентифікатор прийнятого документа. Потім він розшифровує значення, яке дістав листа від Сема, використовуючи наданий Семом ключ загального користування. Якщо два значення хэширования збіглися, Том як дізнається, що це документ справжній, але те, що підпис Сема діє. Зрозуміло, проведення комерційних транзакцій за таким сценарієм значно безпечніше, ніж із використанням підписи рукою на папері, що можна підробити. Якщо ж відомості, передані Семом Тому, конфіденційні (наприклад, містять номер кредитної картки), те й їх можна зашифрувати те щоб прочитати їх змогла лише Том.

Message Digest і цифрові сигнатури.

При створенні цифровий сигнатури деякого повідомлення PGP необхідно зашифрувати його секретним ключем. Але PGP насправді не використовує секретний ключ для шифрування повністю всього повідомлення, т. до. цей процес б довгим. Натомість PGP шифрує MessageDigest.

MessageDigest є компактній (128 біт) «перегонкою «вашого повідомлення, подібно концепції контрольної суми. Ви також можете уявити MessageDigest як «відбиток «повідомлення. MessageDigest представляє ваше повідомлення в такий спосіб, що й це повідомлення змінюватиметься якимось чином, те з зміненого повідомлення буде підраховано не на початкового MessageDigest. Це дає можливість виявлення будь-яких змін, зроблених зломщиком. MessageDigest обчислюється, використовуючи криптографически стійку односпрямовану хэш-функцию повідомлення. Підбір повідомлення, що зробить ідентичне MessageDigest є з обчислювальної погляду нездійсненне для зломщика. У цьому плані МessageDigest набагато краще, ніж контрольна сума (т. до. легше підібрати різні повідомлення, котрі матимуть однакові контрольні суми). Неможливо отримати вихідне сполучення його MessageDigest. Лише MessageDigest недостатньо для аутентифікації повідомлення. Алгоритм MD опубліковано, і вимагає знання секретних ключів для обчислень. Якщо просто будемо прикріплювати MessageDigest до повідомлення, то зломщик зможе змінити повідомлення, обчислити його MessageDigest, прикріпити MessageDigest до зміненому повідомленню і збирається відправити далі. Задля більшої реальної аутентифікації відправник шифрує (підписує) MessageDigest своїм секретним ключем.

MessageDigest обчислюється з повідомлення відправником. Таємний ключ відправника використовується для зашифровки MessageDigest і деякого тимчасового відбитка (timestamp), формуючи цифрову сигнатуру, чи сертифікат сигнатури. Відправник посилає цифрову сигнатуру перед повідомленням. Одержувач отримує повідомлення цифрову сигнатуру, відновлює вихідне MessageDigest з цифровий сигнатури з допомогою розшифровки відкритим ключем відправника, наново обчислює MessageDigest повідомлення й виробляє порівнювати з отриманих від відправника MessageDigest. Якщо вони самі рівні, то над повідомленням був вироблено жодних змін.

Потенциальный зломщик повинен або зробити деяке повідомлення, яке породжує ідентичне MessageDigest (що нездійсненне), чи що вона повинен створити нову цифрову сигнатуру від зміненого MessageDigest (що також нездійсненне не повідомляючи секретного ключа відправника).

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

Использование MessageDigest на формування цифрових сигнатур має й інші переваги крім істотною швидкості, ніж безпосереднє підписування повного повідомлення секретним ключем. Message Digest дозволяє сигнатурам бути cтандартной функцією невеличкий фіксованою довжини, незалежно від розмірів дійсного повідомлення. Також дозволяє контролювати цілісність повідомлення автоматично, способом подібним використанню контрольної суми, дозволяє сигнатуре зберігатися окремо від повідомлення, можливе деякому публічному архіві, без викриття секретної інформації про дійсному повідомленні, т. до. не зможе витягти повідомлення з його MessageDigest.

Схема. Система цифрового електронного підпису.

1. Сем обробляє зі спеціального алгоритму документ, що збирається відправити Тому, внаслідок отримує певний параметр, розрахований підставі вмісту документа. Зазвичай це займає значно менше місця, ніж вихідний документ — параметр 128 чи 160 двійкових розрядів.

Затем Сем з допомогою свого особистого ключа шифрує отриманий параметр. Підсумкове значення служить цифровий підписом Сема.

Сэм відправляє Тому документ і свій цифрову підпис.

Том пропускає документ, отриманий Тома, через хоча б алгоритм, яким користувався Том.

Затем Том дешифрує цифрову підпис, отримані від Сема, користуючись наданим Семом ключем загального користування.

Том порівнює значення параметра, отриманого і під час операції 4, з розшифрованим значенням цифрового електронного підпису. Якщо такі значення збігаються, отже, підпис справжня і документ «їсти дорогою «не піддався змін. Інакше, або документ спотворений, або підпис фальсифікований, або й й інше.

Вероятнее всього саме з такий, чи такої схеми вестимуться справи через Internet чи будь-яку іншу інформаційну службу. Цей алгоритм послужив основою проекту державного стандарту США — Digital Signature Standard (DSS). У ньому застосовуються: алгоритм Secure Hash Algorithm до розрахунку параметрів хэширования і криптосистема з ключем загального користування, відома під назвою Digital Signature Algorithm (DSA) і призначена щоб одержати цифрового електронного підпису за параметрами хэширования. Ряд пунктів проекту DSS зазнали критиці, проте частина з зауважень виходили з груп, фінансово що у відхиленні цього проекту.

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