Хеші/крипто

AES Encrypt/Decrypt

Шифрування й розшифрування тексту через AES-GCM або AES-CBC із паролем (ключ похідний через PBKDF2).

AES — стандарт симетричного шифрування: той самий пароль використовується і для шифрування, і для розшифрування. Інструмент виводить ключ шифрування з пароля через PBKDF2 і шифрує текст режимом AES-GCM або AES-CBC — усе локально в браузері.

Як користуватися

Типові сценарії

Що варто памʼятати

IV (вектор ініціалізації) має бути унікальним для кожного шифрування з тим самим ключем — повторне використання пари ключ+IV в GCM повністю руйнує безпеку шифрування.

AES-CBC без окремої перевірки цілісності (MAC) вразливий до атак на модифікацію шифротексту — тому GCM, що поєднує шифрування й автентифікацію в одному режимі, є безпечнішим вибором за замовчуванням.

Стаття про цей інструмент: AES: як працює симетричне шифрування

Часті запитання

Які розміри ключів підтримує AES і який обрати?

AES підтримує ключі 128, 192 та 256 біт. AES-256 — типова рекомендація для нових застосунків: 128 біт вже вважається безпечним, але 256 дає додатковий запас практично без вартості.

Чим відрізняються режими шифрування (наприклад, CBC, GCM)?

GCM автентифікує шифротекст під час шифрування, тому також виявляє підробку — це рекомендований варіант за замовчуванням. CBC лише шифрує і потребує окремого MAC для цілісності, а також випадкового IV при кожному шифруванні.

Чи надсилається мій ключ або відкритий текст кудись?

Ні. Усе шифрування й розшифрування виконується локально у вашому браузері через Web Crypto API — нічого не надсилається на сервер.

Чому не варто використовувати режим ECB?

ECB шифрує кожен блок незалежно й однаково, тому однакові блоки відкритого тексту дають однакові блоки шифротексту — це видає структуру даних (наприклад, повторювані патерни в зображенні лишаються видимими навіть у зашифрованому вигляді). CBC чи GCM з унікальним IV усувають цю проблему.

Що станеться, якщо повторно використати той самий IV з тим самим ключем?

Для GCM це критична помилка — повторне використання пари ключ+IV повністю компрометує конфіденційність і автентичність шифрування. IV завжди повинен бути унікальним для кожного шифрування з тим самим ключем.

Статті: Хеші/крипто

Hash Generator: чим MD5, SHA-1 і SHA-256 відрізняються одна від одної

Чому MD5 досі використовують для перевірки цілісності файлів, але не для паролів.

Checksum Verifier: як перевірити, що файл не пошкоджено

Чому збіг контрольної суми підтверджує цілісність файлу, але не те, хто його створив.

HMAC: чим хеш з ключем відрізняється від звичайного хешу

Чому звичайний SHA-256 не захищає від підробки повідомлення, а HMAC — захищає.

Bcrypt: чому паролі хешують повільно, а не швидко

Чому швидкий SHA-256 — погана ідея для паролів, а повільний bcrypt — правильна.

UUID: як генерують ідентифікатори, що майже ніколи не повторюються

Чому UUID v4 можна генерувати незалежно на мільйонах машин без ризику колізій.

Генератор паролів: що насправді робить пароль стійким

Чому довгий пароль зі словника надійніший за короткий з символами й цифрами.

Argon2: чому цей алгоритм переміг конкурс на хешування паролів

Чим Argon2 краще захищає від атак на відеокартах, ніж старіші алгоритми хешування паролів.

Scrypt: навіщо алгоритму потрібно багато пам'яті

Чому scrypt навмисно вимагає багато пам'яті, щоб ускладнити перебір на ASIC-пристроях.

TOTP: як працюють одноразові коди в застосунках-автентифікаторах

Чому код у Google Authenticator працює без інтернету і синхронізується із сервером лише за часом.

PBKDF2: найстаріший стандарт розтягування ключів

Чому рекомендована кількість ітерацій PBKDF2 зростає з кожним роком.

X.509: що всередині SSL-сертифіката

Що саме браузер перевіряє в сертифікаті сайту, перш ніж показати зелений замочок.

PGP: як працює шифрування з відкритим і приватним ключем

Чому можна вільно ділитися публічним ключем PGP, але не приватним.