[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Новый менеджер паролей



03.11.2011 17:16, Artem Chuprina пишет:
 > /*      Для шифрования AES требуется 128,192,256-битный ключ
 > для этого возьмем инвертированные байты пароля и повторим
 > его если он меньше 16 символов и получим 128 бит
 > */

	Во-первых, предполагая, что пароль состоит из кодов ASCII,
	пространство ключей при таком подходе значительно ограничено (по
	сравнению с предельными для алгоритмов AES 2¹²⁸ … 2²⁵⁶.)
	Во-вторых, значимыми оказываются только первые 16 октетов
	пароля.

	Общепринятое решение — использовать в качестве ключа криптохэш
	от пароля.  E. g., SHA-256.
Там, надо сказать, значимых битов будет не больше, потому что хэширование не
добавляет энтропии.  Может быть, правда, перебор дороже, но учитывая, что
такие пароли и перебирают соответственно - а именно, составляя таблицы этих
хэшей заранее...  А AES к степени, гм, взбитости энтропии в ключе должен
относиться иррелевантно.  В смысле, ему должно быть пофиг, открытым текстом
там пароль или хэшированный.  Хэшируют для того, чтобы всосать побольше бит из
длинной пассфразы.  Более длинной, чем ключ AES.  Вот тут простые средства
наложения, типа xor, могут ухудшить показатели (типа, в x xor x меньше
энтропии, чем просто в x), а хэш себя ведет хорошо, он для этого
разрабатывался.

учитывая все доводы решил сделать так:
1.считываем в password[16]
2.берем salt[16] из /dev/random
3.складываем с паролем побайтно, с переносом разряда
4.получаем md5-хеш из всей этой лабуды (и это будет ключ)
  итак AES_set_encrypt_key(key, 128, &aeskey); получит таки модный ключ,
5.сохраняем сальт в том же файле чтобы впоследствии с помощью пароля получить ключ для расшифровки.

а нафига iv нужен в AES_cbc_encrypt(in, out, len, &aeskey, iv, mode); ?
который я обозвал вторым ключом
можно предположить что это что-то типа сальта и его нужно сделать подобным способом как и ключ

Reply to: