CloudMailRu
CloudMailRu copied to clipboard
pozitronik
Шифрование на лету (paranoidal mode)
Идея: настраиваемое шифрование на лету. При копировании в облако файл предварительно шифруется, при извлечении - дешифруется. При работе через плагин всё прозрачно, при использовании других клиентов потребуется сторонний дешифратор.
Я думаю, можно это делать не для всего аккаунта, а только для определённого списка папок. Да, шифрование можно сделать совместимым с некоторыми стандартными шифровальными утилитами в Linux.
Как удобно сделать некий список шифруемых каталогов - я не очень представляю, но тут можно подумать. Со способом шифрования можно вот как поступить: не вшивать шифровалку в плагин, а просто пропускать поток копирования через какую-то шифровалку на лету. Таким образом, каждый параноик сможет использовать свою утилиту.
Как удобно сделать некий список шифруемых каталогов - я не очень представляю, но тут можно подумать.
Например файл .encrypted в корне каталога, как признак необходимости шифрования? Чтобы не заморачиваться с настройкой в плагине.
Да, ещё. В свете того, что mail.ru, по некоторым сведениям, может удалять криптоконтейнеры, возможно, имеет смысл использовать стеганографию, делая из них .avi-файлы. Содержимое их не столь важно, главное, чтобы автоматический детектор выдавал тип "видео"
Например файл .encrypted в корне каталога, как признак необходимости шифрования? Чтобы не заморачиваться с настройкой в плагине.
причём этот файл и содержит, например, и используемый метод шифрования (для расширения поддерживаемых методов, а путь файла можно передавать "шифровалке"; и тогда его, вероятно, лучше назвать .encryption)
Есть информация (лично не проверял), что mail.ru удаляет шифрованные файлы из облака (вплоть до бана аккаунта). Судя по всему, шифрованным считается файл с неопознанной сигнатурой, т.о. нельзя применять только чистое шифрование, это должна быть какого-то рода стеганография.
А информация по блокировки шифрованных файлов актуальная или Вы это давно слышали? Больше года храню на 7 аккаунтах зашифрованные файлы, пока без последствий. Но очень не хочется их лишиться.
Понемногу оформляю задачу.
- Добавляю в плагин поддержку какой-то симметричной криптосистемы (попробую начать с AES). Желательно найти реализацию с открытым кодом для Delphi, но допустимо через стороннюю библиотеку на другом языке, если её код открыт.
- Не даём пользователю сохранить ключ в открытом виде. Либо спрашиваем его перед каждой сессией, либо храним в менеджере паролей TC.
- Для каждого аккаунта задаётся свой ключ шифрования.
- Для каждого аккаунта будет галка "Encrypt data". Если она отключена, содержимое Облака трактуется as is, если включена - файлы на лету шифруются/расшифруются. Делать атрибутирование шифрования через какие-то файловые метки - плохой вариант (это прямое указание на зашифрованность данных, плюс этот атрибут придётся связывать с данными и учитывать при файловых операциях, довольно геморно и ненадёжно).
- Опционально включается шифрование имён файлов, в этом случае должен использоваться другой ключ шифрования.
- Несколько раз встречал информацию, что криптоконтейнеры mail.ru отслеживает и аккаунты лочит. Криптоконтейнер, увы, отслеживается на раз: каждый файл имеет свой уникальный хеш-идентификатор в облаке, по хешу можно узнать количество копий файла во всех аккаунтах. Достаточно проанализировать уникальные файлы (криптоконтейнеры будут такими с вероятностью, близкой к единице), хотя бы на соответствие данных расширению (да в принципе это анализируется). Может ли тут помочь стеганография - вопрос открытый, но при возможности её стоит добавить.
@pozitronik ,
Желательно найти реализацию с открытым кодом для Delphi,
DCPCrypt?
DCPCrypt?
Да, это единственное, что находится по теме, скорее всего оно и будет. Я пока не знаю, какой из форков выбрать, они все выглядят одинаково заброшенными.
видимо, там менять нечего ))) всё и так работает )))) вот только в этом форке https://bitbucket.org/nijusss/dcpcrypt2010-sss_no_ansistring/commits/all была добавлена поддержка под Android (которая лишь из-за того, что там нет типа AnsiString)
ну, по коду - вероятно, да, только судя по коммиту https://sourceforge.net/p/dcpcrypt/code/12/, структура немного изменена а я, при всём богатстве выбора, брал бы из Git-репозиториев (так удобнее держать у себя локальную копию, и которую потом легко синхронизировать с обновлёнными версиями) (впрочем, SVN-репозитории я тоже через git-svn засовываю в Git ;) )
Я не буду включать код в плагин. А для инсталляции компонентов в среду разработки структура значения не имеет.
выпуск релизов из IDE только на машине разработчика? ооок...
Глупость. Зависимость будет указана в документации, желаешь свою сборку - ставь компонент, собирай.
поверьте мне - отнюдь, не глупость я наелся (да и ем периодически) свистоплясок пол дня, а то и больше, лишь с тем, чтобы заставить проект хотя бы скомпилироваться, вместо того, чтобы его уже исправлять
про отсутствие тестов в новых проектах я вообще уж молчу ))
поверьте мне - отнюдь, не глупость
Ок, я подумаю над включением DCPCrypt подмодулем. Но вообще это именно что компонент, и нет никакой разницы из каких исходников собирать и ставить bpl. Вариант "форкнуть и юзать исходники" не рассматриваю.
я наелся (да и ем периодически) свистоплясок пол дня, а то и больше, лишь с тем, чтобы заставить проект хотя бы скомпилироваться
Это романтика опенсорса =). Интересно не потому что работает, а потому что не работает.
про отсутствие тестов в новых проектах я вообще уж молчу
Мне тесты писать неинтересно, да и не умею. Есть желание и возможности - жду пулл-реквестов, может и сам научусь. Библиотека в Delphi 10+ собирается без всяких свистоплясок, спулил-открыл-собрал.
Есть желание и возможности - жду пулл-реквестов, может и сам научусь.
диссонирует с
Мне тесты писать неинтересно
проверено не на одном проекте в продакшне ) пока не заставишь использовать тесты (а это можно сделать только путём сборки и прогона тестов на CI-сервере), их никто из тех, кому они неинтересны/не умеет, использовать не будет
я не навязываю... но лично я не испытываю ни толики уверенности при работе с кодом, не покрытым тестами, даже старым своим (без тестов), а уж с чужим...
Ну, с одной стороны тесты - хорошо, но тесты писать тесты на glue code между интеграцией TC, сторонним шифровальщиком и загрузкой в облако... Удовольствие на троечку. Если знаешь и умеешь - еще можно попробовать, если нет - вряд ли толк выйдет.
Мы в оффтопик ушли. Порядка ради, всё, что не касается тикета напрямую обсуждаем в новых тикетах.
Мы в оффтопик ушли
сорре, но я допишу 2 @areht: писать тесты надо на то, что твой код делает/подразумевает делать ) а уж чем он там является - glue code или wrapper - дело десятое удовольствие появляется там, где тесты ЕСТЬ, какие бы они ни были там, где тестов нет, и удовольствия (лично у меня) нет
Я тоже могу с умным видом рассказывать на что и как надо тесты писать, но на практике они пользу приносят не всегда.
Если не согласны - присылайте пулреквесты с полезными тестами, заодно ci настроите.
- [x] Для аккаунтов с включённым шифрованием имён файлов отключать поддержку файловых описаний (трекинг).
- [ ] В случае, когда включено шифрование имён файлов, возможна следующая ситуация: по пути файла, полученному при шифровании имени, уже находится другой файл (например, предыдущая версия с этим же именем, шифрованная тем же ключом). Поскольку для API облака это выглядит, как попытка записать данные по пути с ключом CLOUD_CONFLICT_STRICT, вернётся ошибка. Решение: проверять существование файла по шифрованному пути, возвращать FS_COPYFLAGS_EXISTS_SAMECASE для запроса действия пользователя, и дальше действовать по его выбору.