id: Гость   вход   регистрация
текущее время 20:28 19/04/2024
Владелец: ressa (создано 23/01/2014 11:27), редакция от 23/01/2014 12:16 (автор: unknown) Печать
Категории: криптография, инфобезопасность, алгоритмы, ошибки и баги, исходные тексты, операционные системы
https://www.pgpru.com/Новости/2014/РезультатыАудитаБезопасностиECryptfs
создать
просмотр
редакции
ссылки

23.01 // Результаты аудита безопасности eCryptfs


Тейлор Хорнби (Taylor Hornby) продолжил исследование криптостойкости открытых систем дискового шифрования и опубликовал результаты аудита подсистемы eCryptfs, входящей в состав ядра Linux. По результатам проверки сделан вывод, что процесс шифрования в eCryptfs организован заметно лучше, чем в ранее проанализированном EncFS. Тем не менее, архитектура eCryptfs не избавлена от отдельных недочётов, свидетельствующих о том, что её проектированием занимался не профессиональный криптограф и, что код проекта не подвергался серьёзному аудиту безопасности. Всего выявлено три недочёта, которые отмечены как незначительные. В итоге, eCryptfs признан безопасным для использования, но разработчикам даны рекомендации по проведению более детального аудита.


Источник: http://www.opennet.ru/opennews/art.shtml?num=38911


 
— sentaus (23/01/2014 12:23, исправлен 23/01/2014 12:28)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

Мне вот это в отчёте понравилось:


The eCryptfs mailing list is discussing the option of using other
modes like GCM and CTR. There are already patches submitted...

"Семь раз отрежь, ошибся – отмерь"

— unknown (23/01/2014 12:25, исправлен 23/01/2014 12:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

"The enterprise cryptographic filesystem for Linux"

Originally authored by Michael Halcrow and the IBM LInux Technology Center, eCryptfs is derived from Erez Zadok's Cryptfs, and the FiST framework

А по описанию из аудита — очередное поделие. XTS или ESSIV внедрить не додумались, что-то наколенное поверх CBC в режимах наизобретали. Они бы и GCM с CTR внедрили, не вникая, что это такое и где это можно (а где никогда нельзя) использовать.


Шифрпанк во всей красе.


Кстати, в аудите не рассматривается ситуация, когда копия удалённого файла восстановлена. И у противника есть несколько копий файлов с одного ключа, причём у них там IV вырабатывается непонятно как. А при удалённом хранении файлов в облаке — и восстанавливать ничего не надо. Хостеру достаточно сравнивать бэкапы между обновлениями.

— Гость (23/01/2014 13:17)   <#>

Вот этот «злостный» коммент в коде именно от него:

There is a comment in the code that derives the IV...

/* TODO: It is probably secure to just cast the least
* significant bits of the root IV into an unsigned long and
* add the offset to that rather than go through all this
* hashing business. -Halcrow */

...which is wrong, and needs to be removed.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3