CSI XII: Криптографія та шифрування даних
Ну, в останніх публікаціях Речей, які трапляються в обчислювальній техніці, ми розглядали (і багато) з проблемою кодування, що є не що інше, як використання іншого подання даних з якихось причин. Сьогодні я збираюся посадити себе і представляю останній пост, присвячений цій темі: тоді ми перейдемо до чогось зовсім іншого. Але це те, що, говорячи про кодування інформації, я не хотів залишити одну з найцікавіших та актуальних тем незайманою: шифрування даних.
ефективно, зашифрувати інформація складається з перетворення її відповідно до правил або алгоритму. Коли ми робимо це, в загальному, тому що нам все одно, що кожен може зрозуміти наше повідомлення. Перший підхід для досягнення цього - той, який здається нам найбільш очевидним: лише одержувач повідомлення буде знати, якими правилами чи алгоритмом розшифровується інформація, яку я надсилаю. Це відомо як секретне шифрування алгоритму і правда в тому, що сьогодні це трохи застаріло. Давайте подивимось чому.
Той, хто в дитинстві був частиною секретного клубу, напевно, зрозуміє, що я маю на увазі. Найпростіше - це встановити правила кодування інформації, яку ми знаємо лише в клубі. Таким чином, майже неможливо, якщо правила ускладнюються, що хтось іззовні може розшифрувати повідомлення. Візьмемо натомість приклад простих правил.
Викликається найдавніше відоме шифрування Шифр Цезаря і складається з додавання суми до кожної літери для перетворення її в іншу з того самого алфавіту. Якщо ми хочемо закодувати 'a', а ключ - 5, ми додаємо 5 символів до 'a' (b, c, d, e,F) і ми змінюємо його на "f". Дійшовши до останніх букв, звичайно, замінюємо першими. Таким чином, повідомлення "abcdez" буде закодовано як "fghije". Простий.
Звичайно, занадто просто. Але тут з’явилася важлива концепція, яка полягає в код ключа. Наш пароль був 5, і, в принципі, не знаючи цього, ми не могли розшифрувати повідомлення. все ще знаючи правила кодування. Ну, в цьому випадку так, оскільки алгоритм дуже простий: знаючи, що правило складається з додавання певного числа, для розбиття ключа вам потрібно буде лише спробувати додати 1, потім 2, потім 3. до кожного символу, поки не знайдете що при читанні змістовного повідомлення ключовим фактором є 5: це відоме як атака грубою силою
Але оскільки алгоритм ускладнюється, а ключі довгі та складні, можна з певною жорсткістю переконатися, що атака грубої сили знайде ключ, у гіршому випадку, коли надіслана інформація перестане бути актуальною. Ось чому сьогодні тенденція полягає у використанні загальнодоступні алгоритми -правила - для кодування інформації. Крім того, з Інтернетом для секретних алгоритмів виникла дуже важлива проблема: у нашому дитячому клубі ми можемо домовитись про секретні правила на таємній зустрічі в (таємному) будинку на дереві. Але в Інтернеті такої можливості немає: вона вам потрібна захищений канал поширювати таємні правила, і саме цього у нас немає 1 .
Перший 'стандарт де факто'загальнодоступних алгоритмів був DES (Стандарт шифрування даних). DES було затверджено в 1976 році, а в 1998 році пароль було зламано в результаті атаки грубої сили, яка тривала 56 годин 2. Якщо ми вважаємо, що потужність комп’ютерів зросла в геометричній прогресії за всі ці роки, ми можемо надати цьому алгоритму більше, ніж помітно. У будь-якому разі на той час DES вже був замінений на більш складний варіант Потрійний DES який у 2001 р. був «замінений» іншим алгоритмом, AES (Розширений стандарт шифрування). Були припущені деякі слабкі сторони AES, але на даний момент немає відомих атак грубої сили, які могли б спрацювати. Настільки, що уряд США, звикши до секретних алгоритмів, оголосив, що може використовувати цей публічний метод для шифрування своїх ТОП-СЕКРЕТНИХ документів. Тому ДУЖЕ ДУЖЕ ТВОРДО розбити ключ. Це НАБАГАТО, НАБАГАТО простіше вкрасти його.
Названий криптографія симетричного ключа до якого він використовує той самий ключ для шифрування та розшифрування. Це найочевидніше і те, про що ми всі думали до цього часу. Але тут проблема: як отримати секретний ключ? Якщо відправник та одержувач мають спільне місто чи країну, справа проста: вони залишаються один день, і якщо вони впевнені, що особа перед ними не самозванець, вони домовляються про захищений пароль. Але якщо двоє людей хочуть обмінюватися інформацією через Інтернет і не можуть зустрітись одне з одним, як вони домовляються про ключ щодо безпеки?.
Ще одна проблема: якщо я хочу поспілкуватися з Хуаном, я витрачаю секретний пароль. І з Марією ще один ключ (щоб Хуан не дізнався), а з Антоніо ще один, Хуан проводить інший, щоб поспілкуватися з Антонією. словом, що для спілкування n люди, які мені потрібні n різні ключі, і таких багато: мені краще записати їх у POST-IT, так?.
Щоб вирішити ці проблеми, криптографія асиметричного ключа який в основному витрачає ключ для шифрування та пару для дешифрування. І це дає багато гри. Припустимо, що я генерую пару ключів вдома і зберігаю один для дешифрування: це мій секретний ключ. Але інший ключ я публікую на сервері: мій відкритий ключ. Тож якщо Хуан хоче надіслати мені щось зашифроване, він бере мій відкритий ключ, зашифровує разом із ним інформацію і надсилає мені. Благодать полягає в тому, що лише за допомогою мого приватного ключа можна розшифрувати це повідомлення, а я його приховую: кожен, хто прочитає повідомлення, знайде лише безглуздя. І те саме може Марія, Антоніо.
Але, зі смертю, тут проблема в іншому: коли я отримую повідомлення, зашифроване моїм відкритим ключем і підписане Хуаном. Звідки я знаю, що це Хуан прислав мені? Я не можу: Хуан повинен автентифікація. Але. Що, якщо ми зробимо це навпаки?: Хуан публікує свій пароль розшифровувати. Зашифруйте повідомлення за допомогою мого відкритого ключа, щоб зашифрувати, і зашифруйте результат своїм приватним ключем для шифрування. Тоді я (і будь-хто) зможу прочитати зашифроване повідомлення Хуана, не більше, ніж взявши відкритий ключ Хуана. Текст міститиме безглуздя: лише я можу зрозуміти це, витративши свій приватний ключ. Викликається повідомлення, зашифроване приватним ключем для автентифікації цифровий підпис. Цифровий підпис автентифікує, запобігає змінам (додавання вмісту до повідомлення) і не підлягає відсутності: Хуан не може стверджувати, що це повідомлення не було його.
Це робиться?. Ніколи. Припустимо, що Антоніо хоче видавати себе за Хуана і зашифровує повідомлення: "Привіт, я Хуан" своїм приватним ключем (Хуан цього не знає). І в той момент, коли я отримував доступ до сервера ключів, щоб дізнатися відкритий ключ Хуана (і розшифрувати повідомлення), Антоніо перехоплює спілкування і надсилає мені СВОЙ ключ партнера: тоді я думаю, що повідомлення підписав Хуан. Потрібно, щоб вони існували Органи, що посвідчують (Змінного струму). Вони служать для того, щоб гарантувати, що певний відкритий ключ відповідає ключу суб’єкта господарювання або особи. Для цього після перевірки особи заявника (а в найсерйозніших випадках потрібна фізична присутність) орган, що посвідчує, пов’язує особу особи з відкритим ключем у документі та цифровий знак з його паролем - AC - ця асоціація.
Я можу вимагати, щоб Хуан отримав його цифровий підпис у авторитетному центрі сертифікації. Наприклад, якщо я хочу скласти звіт про доходи в Інтернеті, мені потрібно буде мати цифровий підпис, виданий адміністрацією. Коли "Хуан" зв'яжеться зі мною, я розшифрую цифровий підпис за допомогою відкритого ключа ЦС (який повинен бути відомим), і я отримаю відкритий ключ Хуана разом з його особистими даними. І якщо хтось підробив відкритий ключ Хуана якимось зловмисним способом, це провина AC. Легко право?.
Правда полягає в тому, що я багато виступив на цій посаді і багато речей залишив у стадії розробки. Це дуже цікава тема, яка піддається думці змова. І полягає в тому, що будь-яке спілкування через Інтернет, в якийсь момент в ньому, буде небезпечним. Але це те, що стосується змови: ви ніколи не можете закінчити це: ви завжди можете піти на крок далі і включити когось іншого в сюжет. Звичайно, що деякі з цих теорій настільки успішні, так?