Цифровий підпис: принципи роботи
Контрольні суми, контроль 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) = 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 (на сервері за адресою 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, і якщо ви виконали з ним той же алгоритм хешування і ваш результат збігся з вихідним значенням, точно можна бути впевненим, що прийнятий вами файл не піддався спотворень.
Алгоритм MD5
Термінологія
У даному випадку "word" є 32-х бітної величиною, "byte" - 8-ми бітна величина. Послідовність біт повинна інтерпретуватися таким же способом що і послідовність байт, де кожна послідовна група з восьми біт інтерпретується як байт з старшим (найбільш значущим) бітом кожного байта наступним у послідовності першим. Подібно послідовності байт повинна інтерпретуватися і послідовність 32-бітних слів.
Запис x_i означає "x sub i" (тобто х з індексом i). Якщо деякий вираз використовується як індекс, то воно береться у фігурні дужки, наприклад x_ {i +1}. Символ "^" використовується для операцій зведення в ступінь, тобто x ^ i слід розуміти як х в ступені i.
Символ "+" означає операцію складання слів (тобто додавання по модулю 2 ^ 32). Далі 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) 0x67452301L;
mdContext-> buf [1] = (UINT4) 0xefcdab89L;
mdContext-> buf [2] = (UINT4) 0x98badcfeL;
mdContext-> buf [3] = (UINT4) 0x10325476L;
}
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 == 0x40)
{
for (i = 0, ii = 0; i <16; i + +, 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 (i = 0, ii = 0; i <14; i + +, 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 (i = 0, ii = 0; i <4; i + +, 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 ^ 64 * /
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 дозволяє сигнатурах бути Стандартний функцією невеликий фіксованої довжини, незалежно від розмірів дійсного повідомлення. Також дозволяє контролювати цілісність повідомлення автоматично, способом подібним використання контрольної суми, дозволяє сигнатурі зберігатися окремо від повідомлення, можливо в деякому публічному архіві, без викриття секретної інформації про дійсний повідомленні, тому що ніхто не зможе витягти повідомлення з його MessageDigest.
Схема. Система цифрового підпису.
1. Сем обробляє за спеціальним алгоритмом документ, який збирається відправити Тому, в результаті отримує певний параметр, розрахований на підставі вмісту документа. Зазвичай це займає значно менше місця, ніж вихідний документ - параметр 128 або 160 двійкових розрядів.
Потім Сем за допомогою свого особистого ключа шифрує отриманий параметр. Підсумкове значення служить цифровим підписом Сема.
Сем відправляє Тому документ і свою цифровий підпис.
Том пропускає документ, отриманий від Тома, через той же алгоритм, яким користувався Том.
Потім Том дешифрує цифровий підпис, отриману від Сема, користуючись наданим Семом ключем загального користування.
Том порівнює значення параметра, отриманого при виконанні операції 4, з розшифрованим значенням цифрового підпису. Якщо ці значення збігаються, значить, підпис справжня і документ "в дорозі" не зазнав змін. В іншому випадку, або документ спотворений, або підпис підроблений, або і те й інше.
Найімовірніше саме за такою, або подібною схемою будуть вестися справи через Internet або будь-яку іншу інформаційну службу. Цей алгоритм послужив основою проекту державного стандарту США - Digital Signature Standard (DSS). У ньому застосовуються: алгоритм Secure Hash Algorithm для розрахунку параметрів хешування і криптосистема з ключем загального користування, відома під назвою Digital Signature Algorithm (DSA) і призначена для отримання цифрового підпису за параметрами хешування. Ряд пунктів проекту DSS піддалися критиці, проте багато хто з зауважень виходили від груп, фінансово зацікавлених у відхиленні даного проекту.
Час покаже, чи буде який-небудь із методів створення цифрового підпису прийнятий як стандарт. Однак незалежно від результату, важливо інше: дійсно існує можливість абсолютно безпечно здійснювати цифрові торгові операції.