Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
require 'aes'
message = "Super secret message"
key = "password"
encrypted = AES.encrypt(message, key) # RZhMg/RzyTXK4QKOJDhGJg==$BYAvRONIsfKjX+uYiZ8TCsW7C2Ug9fH7cfRG9mbvx9o=
decrypted = AES.decrypt(encrypted, key) # Super secret message
https://blog.elpassion.com/simple-and-terrifying-encryption-story-c1f1d6707c07#.lryae7h7b
Запостил: 
roman-kashitsyn,
(Updated )
С другой стороны автор поста открыл для себя хекс, и узнал что протоколы шифрования обычно оперируют байтами, а не буквами хуйпоймикакой кодировки, а это полезное знание для программиста.
Но ведь это протоколы, а не конкретные реализации.
А вообще, пример поучителен и полезен. Бесед о потенциальных дырах никогда не бывает много.
Просто в ЯП со стат типизацией никто не стал бы принимать ключ как String с hex-encoded.
А вот в жабе и .NET стопудово не так.
Кстати, во многих криптолибах есть фреймворк для криптографии, и там вообще отдельно работать с AES не нужно.
Ты говоришь примерно: ШифруйМеня(данные, ключ, провайдер=AES)
И пофиг там AES или 3DES
char * это указатель на чар. Например чтобы сделать строку или одномерный массив байт.
@Указатель на указатель
Так его ж два раза придётся разыменовывать?
Первым разыменованием получаем адрес второго указателя, а вторым разыменованием создаём ссылку на память. Так?
Просто хороший тон (и единственно правильно в некоторых случаях) память освобождать там же, где и выделял.
> Так все винапи работает
Попросить функцию оценить, сколько ей надо памяти, выделить память, позвать функцию ещё раз, обломаться, потому что условия изменились, реаллокнуть память. Плавали, знаем. Тьфублядь.
Некоторые либы позволяют. Но редко, да.
Твой способ, кстати, ещё рулит когда структура заранее известного и не плавающего размера - можно вообще кучу не лапать.
> На всё есть причины
+1. Оба способа имеют свои недостатки, достоинства и право на жизнь.
Да, но описанный мной приём этому правилу не противоречит. И позволяет вернуть что-то посложнее и поинкапсулированнее, чем просто буфер (какую-нибудь древовидную структуру, к примеру).
Мне кажется, приводить винапи как образец хорошего дизайна интерфейсов -- не самая удачная стратегия.
Когда я его удалять буду?
То как ты вообще сможешь им пользоваться? Он же в любой момент может сдохнуть.
В таком случае тебе какие-нибудь AddRef и Release дадут.
Вот ты сам и ответил -- как)
попользовался -- сказал Release.
А он остался жив, пока его в соседнем треде через полтора часа не релизнут, и тогда он окончательно даст дуба.
Ref Counting, короче.
А какая разница?
Отсюда вытекают их особенности:
* Ключ обычно имеет фиксированную длину, жестко прописанную в алгоритме, и обычно она слишком большая чтобы человек вводил ее с клавиатуры. А пароль таких ограничений не имеет и напротив: должен быть доступен для ввода с клавиатуры.
* Ключ может состоять из любых байт, а пароль это человекочитаемый текст, и в большинстве раскладок он не будет использовать, скажем, байт 0x1.
* Пароль имеет смысл брудфорсить, а ключ нет.
зы: полагаю что пароль можно превратить в некоторое подобие ключа, если сложить его со случайным числом и взять от этого хеш.
Возможно есть такая библиотека. Но AES не имеет понятия "пароль", и потому ожидает ключ.
Придираст!
> полагаю что пароль можно превратить в некоторое подобие ключа, если сложить его со случайным числом и взять от этого хеш.
Кстати, что обычно используют для выжимки пароля в ключ?
Случайное число все равно нужно.
Люди не смогу создать пароль длиннее чем 10 символов, и ни одна кодировка не даст тебе использовать все 255 символов для букв, а значит пароль у тебя даже не 10 байт, а меньше.
В ключ у AES, например, 192 байта. Это значит что десяти байт явно мало.
PBKDF2, bcrypt, scrypt и т.п. Пыхомакаки - одну итерацию первого попавшегося хеша.
З.Ы. Если как в PKCS #5 каждый раз делать новую соль - всё норм, ключ уже не long-term.
Если у разных юзеров пароли совпадут? Или о чем речь?
Если ты юзаешь PBKDF(salt, password) напрямую как ключ (не меняя соль на каждое сообщение), то ты, по сути, юзаешь один ключ для всех данных. Такая схема очень чувствительна к выбору IV, особенно если шифр потоковый (аля AES в режиме CTR). Повторился IV - одинаковая пара (ключ, IV) - кровь-кишки (можно узнать инфу о плейнтексте не зная ключа).
Ещё есть ограничения на объём и количество сообщений, которые допустимо шифровать одним ключом. Ты не сможешь этот объём контролировать при такой схеме.
Поэтому проще сгенерить/породить новый ключ и не лезть на поле с граблями (хоть и теоретическими).
З.Ы. Надо ещё аутентификацию добавить, чтобы знать, что никто не помял сообщение по дороге. Ибо шифрование не спасает от изменения данных.
Добавить к данным перед шифрованием их дайджест?
Нет. Это плохой, дырявый способ.
Много холиваров на эту тему было... Погугли на тему hash-than-encrypt, encrypt-than-mac и т.п.
:-/
Ещё можно прибегнуть к Indy, там наверняка есть.
@А у вас же там доступ к Win32Api нормальный, значит можно Crypto API
Далеко пойдёшь.
> психиатр
В параллельной вселенной у психиатра раздвоение личности, а клиент здоров.
P.S я не рубист
Ну да, чтобы всякие пробелы и т.п. убрать. Но посчитать то символы после этого можно было? 🙂
З.Ы. Т.е. пробелы не в самом ключе, пробелы в одном из его текстовых представлений.
Жиза. На собеседовании компьютерсайнс и паттерны проектирования, а на работе костыли и бойлерплейт на пхп.
Вот еще про side-channel атаки https://www.youtube.com/watch?v=fJCSYL9jc7Y
+1. Кого ебут эти side channel'ы, когда даже шифр цезаря с одним ключём на всех железках приносит профит:
http://cybergibbons.com/security-2/csl-dualcom-cs2300-signalling-unit-vulnerabilities/
Будешь это рассказывать своим клиентам, когда кулхацкеры похакают твой сайт (если он у тебя конечно есть) с ценной инфой из-за кривой самопальной криптографии
Какой же хипстер SQL использует? MongoDB, горизонтальное масштабирование, вот это всё.
Или padding oracle.
очень актуально когда твой сайт хостица на дижитал океане
Угу, там актуальней side channel через обращение к кешу 🙂