Шифрование на лету (paranoidal mode)

[pozitronik]

Идея: настраиваемое шифрование на лету. При копировании в облако файл предварительно шифруется, при извлечении - дешифруется. При работе через плагин всё прозрачно, при использовании других клиентов потребуется сторонний дешифратор.

[vmchaz]

Я думаю, можно это делать не для всего аккаунта, а только для определённого списка папок.
Да, шифрование можно сделать совместимым с некоторыми стандартными шифровальными утилитами в Linux.

[pozitronik]

Как удобно сделать некий список шифруемых каталогов - я не очень представляю, но тут можно подумать.
Со способом шифрования можно вот как поступить: не вшивать шифровалку в плагин, а просто пропускать поток копирования через какую-то шифровалку на лету. Таким образом, каждый параноик сможет использовать свою утилиту.

[stayathome]

Как удобно сделать некий список шифруемых каталогов - я не очень представляю, но тут можно подумать.

Например файл .encrypted в корне каталога, как признак необходимости шифрования? Чтобы не заморачиваться с настройкой в плагине.

[pozitronik]

Отличная идея!

[vmchaz]

Да, ещё. В свете того, что mail.ru, по некоторым сведениям, может удалять криптоконтейнеры, возможно, имеет смысл использовать стеганографию, делая из них .avi-файлы. Содержимое их не столь важно, главное, чтобы автоматический детектор выдавал тип "видео"

[ashumkin]

Например файл .encrypted в корне каталога, как признак необходимости шифрования? Чтобы не заморачиваться с настройкой в плагине.

причём этот файл и содержит, например, и используемый метод шифрования (для расширения поддерживаемых методов, а путь файла можно передавать "шифровалке"; и тогда его, вероятно, лучше назвать .encryption)

[pozitronik]

Есть информация (лично не проверял), что mail.ru удаляет шифрованные файлы из облака (вплоть до бана аккаунта). Судя по всему, шифрованным считается файл с неопознанной сигнатурой, т.о. нельзя применять только чистое шифрование, это должна быть какого-то рода стеганография.

[NewSky13]

А информация по блокировки шифрованных файлов актуальная или Вы это давно слышали? Больше года храню на 7 аккаунтах зашифрованные файлы, пока без последствий. Но очень не хочется их лишиться.

[pozitronik]

Пока я сам не проверил, будем считать, что это из разряда ОБС.

[pozitronik]

Понемногу оформляю задачу.

1. Добавляю в плагин поддержку какой-то симметричной криптосистемы (попробую начать с AES). Желательно найти реализацию с открытым кодом для Delphi, но допустимо через стороннюю библиотеку на другом языке, если её код открыт.
2. Не даём пользователю сохранить ключ в открытом виде. Либо спрашиваем его перед каждой сессией, либо храним в менеджере паролей TC.
3. Для каждого аккаунта задаётся свой ключ шифрования.
4. Для каждого аккаунта будет галка "Encrypt data". Если она отключена, содержимое Облака трактуется as is, если включена - файлы на лету шифруются/расшифруются. Делать атрибутирование шифрования через какие-то файловые метки - плохой вариант (это прямое указание на зашифрованность данных, плюс этот атрибут придётся связывать с данными и учитывать при файловых операциях, довольно геморно и ненадёжно).
5. Опционально включается шифрование имён файлов, в этом случае должен использоваться другой ключ шифрования.
6. Несколько раз встречал информацию, что криптоконтейнеры mail.ru отслеживает и аккаунты лочит. Криптоконтейнер, увы, отслеживается на раз: каждый файл имеет свой уникальный хеш-идентификатор в облаке, по хешу можно узнать количество копий файла во всех аккаунтах. Достаточно проанализировать уникальные файлы (криптоконтейнеры будут такими с вероятностью, близкой к единице), хотя бы на соответствие данных расширению (да в принципе это анализируется). Может ли тут помочь стеганография - вопрос открытый, но при возможности её стоит добавить.

[NewSky13]

Это прекрасная новость!

[ashumkin]

@pozitronik ,

Желательно найти реализацию с открытым кодом для Delphi,

DCPCrypt?

[pozitronik]

DCPCrypt?

Да, это единственное, что находится по теме, скорее всего оно и будет. Я пока не знаю, какой из форков выбрать, они все выглядят одинаково заброшенными.

[ashumkin]

видимо, там менять нечего ))) всё и так работает ))))
вот только в этом форке https://bitbucket.org/nijusss/dcpcrypt2010-sss_no_ansistring/commits/all
была добавлена поддержка под Android (которая лишь из-за того, что там нет типа AnsiString)

[pozitronik]

Я пока взял этот форк, но, думаю, они взаимозаменяемы.

[ashumkin]

ну, по коду - вероятно, да, только судя по коммиту https://sourceforge.net/p/dcpcrypt/code/12/, структура немного изменена
а я, при всём богатстве выбора, брал бы из Git-репозиториев (так удобнее держать у себя локальную копию, и которую потом легко синхронизировать с обновлёнными версиями) (впрочем, SVN-репозитории я тоже через git-svn засовываю в Git ;) )

[pozitronik]

Я не буду включать код в плагин. А для инсталляции компонентов в среду разработки структура значения не имеет.

[ashumkin]

выпуск релизов из IDE только на машине разработчика? ооок...

[pozitronik]

выпуск релизов из IDE только на машине разработчика? ооок...

Глупость. Зависимость будет указана в документации, желаешь свою сборку - ставь компонент, собирай.

[ashumkin]

поверьте мне - отнюдь, не глупость
я наелся (да и ем периодически) свистоплясок пол дня, а то и больше, лишь с тем, чтобы заставить проект хотя бы скомпилироваться, вместо того, чтобы его уже исправлять

про отсутствие тестов в новых проектах я вообще уж молчу ))

[pozitronik]

поверьте мне - отнюдь, не глупость

Ок, я подумаю над включением DCPCrypt подмодулем. Но вообще это именно что компонент, и нет никакой разницы из каких исходников собирать и ставить bpl. Вариант "форкнуть и юзать исходники" не рассматриваю.

я наелся (да и ем периодически) свистоплясок пол дня, а то и больше, лишь с тем, чтобы заставить проект хотя бы скомпилироваться

Это романтика опенсорса =). Интересно не потому что работает, а потому что не работает.

про отсутствие тестов в новых проектах я вообще уж молчу

Мне тесты писать неинтересно, да и не умею. Есть желание и возможности - жду пулл-реквестов, может и сам научусь. Библиотека в Delphi 10+ собирается без всяких свистоплясок, спулил-открыл-собрал.

[ashumkin]

Есть желание и возможности - жду пулл-реквестов, может и сам научусь.

диссонирует с

Мне тесты писать неинтересно

проверено не на одном проекте в продакшне )
пока не заставишь использовать тесты (а это можно сделать только путём сборки и прогона тестов на CI-сервере), их никто из тех, кому они неинтересны/не умеет, использовать не будет

я не навязываю... но лично я не испытываю ни толики уверенности при работе с кодом, не покрытым тестами, даже старым своим (без тестов), а уж с чужим...

[areht]

Ну, с одной стороны тесты - хорошо, но тесты писать тесты на glue code между интеграцией TC, сторонним шифровальщиком и загрузкой в облако... Удовольствие на троечку. Если знаешь и умеешь - еще можно попробовать, если нет - вряд ли толк выйдет.

[pozitronik]

Мы в оффтопик ушли. Порядка ради, всё, что не касается тикета напрямую обсуждаем в новых тикетах.

[ashumkin]

Мы в оффтопик ушли

сорре, но я допишу
2 @areht:
писать тесты надо на то, что твой код делает/подразумевает делать ) а уж чем он там является - glue code или wrapper - дело десятое
удовольствие появляется там, где тесты ЕСТЬ, какие бы они ни были
там, где тестов нет, и удовольствия (лично у меня) нет

[areht]

Я тоже могу с умным видом рассказывать на что и как надо тесты писать, но на практике они пользу приносят не всегда.

Если не согласны - присылайте пулреквесты с полезными тестами, заодно ci настроите.

[ashumkin]

Это правда замечательно, но по условиям лицензии GPL вы обязаны выложить свой код в открытый доступ под той же лицензией.

Боюсь, что это не так

GPL не требует от вас, что бы опубликовывали модифицированную версию или любую ее часть. Вы свободны делать модификации и использовать их в частном порядке, никогда не выпуская их. Это так же применимо к организациям (включая компании); организации могут создавать модифицированные версии и использовать их внутри, никогда не публикуя вне своей структуры.

Но, если вы выпускаете модифицированную версию публично в любом виде, GPL требует от вас сделать исходные коды модифицированной версии доступными для пользователей программы под GPL.

(с) https://habrahabr.ru/post/284392/

[pozitronik]

Боюсь, что это не так

Спасибо, я упустил этот момент.

[SchwarzKopf-M]

Возможно сигнатура и засветит файл то он шифрованный. Но его ещё злодеям нужно расшифровать что проблематично. А класть в отдельную папку типа ".crypt" ещё хуже это засветит. А принципиально расшифровывать файл по настройкам, если файл не шифрованный это не есть хорошо. Я столкнулся с этим при попытке расшифровать имя файла неправильным паролем, имя файла получалось такое что шла ругань что невозможно создать файл с таким именем. Использование модуля AES было только из нежелания раздувать размеры дополнительной библиотеки. К тому-же в мой модуль AES встроил сжатие, поэтому получаемый файл зачастую меньше оригинала. В общем если плагин будет красиво переделан, то почему-бы и воспользоваться оригиналом. :) И кстати, в файл зашивается шифрованный пароль, если введённый пароль не совпадает или это не шифрованный файл, то операция прерывается.
Как говорил идея шифрования хорошая ибо считаю что положить свои какие-то личные данные на компьютер какого-то дяденьки, он делает с этим всё что хочет... Поэтому и не храню ничего в облаках. А так, можно и подумать об этом.

[pozitronik]

Но его ещё злодеям нужно расшифровать что проблематично.

Не в этом дело. Мы пытаемся скрыть факт шифрования непосредственно от mail.ru - в т.ч. из-за слухов из-за того, что аккаунты с шифрованными данными блочатся.
Понятно, что это детские игры, и факт шифрования вычисляется на раз (а читающие это сотрудники mail.ru наверняка улыбаются. Привет, парни!), но я буду последователен, это раз. Два - наличие собственного заголовка практически убирает всю совместимость с любыми криптоутилитами, например для случая дешифровки файла без плагина (окей, не проблема откусывать несколько байт от каждого файла, но кому оно надо?).
В общем, не о том спорим. Никто никого не ограничивает в создании модификаций, если что.

К тому-же в мой модуль AES встроил сжатие, поэтому получаемый файл зачастую меньше оригинала

Если сжатие нестандартное, это потеря совместимости. Если это стандартные форматы - то конкретно в плагине они мне кажутся излишними, сжимать данные при копировании может и Total Commander.

[SchwarzKopf-M]

Доверюсь мыслям автора. :)

[areht]

Понятно, что это детские игры, и факт шифрования вычисляется на раз

Кстати... А идея с RAR не такая плохая.

Почему мейлру блочит зашифрованное? У них не работает дедупликация.
Как они находят зашифрованное? В первую очередь, должна быть незнакомая сигнатура.
Нешифрованный RAR - "легальный" контейнер, не позволяющий дедупликацию. То есть парсить подробно что там внутри него не очень интересно (они же не поддерживают предпросмотр файлов из архивов?).

То есть раз уж тут Security through obscurity, то логично было бы класть шифрованный файл в такой вот легальный контейнер (хотя, может и стоит выбрать что-то не столь популярное). Там и метаданные можно прихранить (вплоть до создания "саморасшифровывающегося" sfx архива!), и совместимость с криптоутилитами не теряется. А что бы понять, что в архиве что-то шифрованное - надо не просто распарсить заголовок, но и разархивировать.

[pozitronik]

areht,
это уже стеганография (ну, не совсем, но sort of), и если делать её - то после шифрования.

[areht]

Ну как стеганография, не больше, чем липовую сигнатуру прилепить.

Я бы сразу в шифровании прикручивал поддержку pipeline(всё равно пригодится), а там уж на одном из этапов дернуть за архиватор (до и/или после шифрования) - 3 строчки.

[areht]

Кстати, это issue #103 с другого конца

[ashumkin]

я тут вспомнил про gzip, к слову )
шифрованый даже по AES файл без всяких magic-заголовков - это просто поток байт, пулять поток в gzip, вот вам и ещё один набор байтов. выяснять что его содержимое - какой-то зашифрованный набор байтов - КМК, дорогое удовольствие (в масштабах и объёмах сервиса)

[pozitronik]

Переделал поддержку шифрования, теперь им управляет непосредственно класс CloudMailRu, плюс где это возможно, обработка происходит через TStream. Избавиться от временного файла при аплоаде не удалось, но код стал чище и проще.

В целом, остаются нерешёнными следующие проблемы:

• Нужна какая-то проверка корректности пароля, хотя, насколько я понимаю, для симметричного шифрования это принципиально нереализуемо без дополнительных уловок.
• Нужен новый диалог для запроса паролей, TAskPasswordForm уже не годится. Что от него требуется:
• Новый диалог должен запрашивать сразу оба пароля (для файлов/имён файлов).
• Должна быть возможность сохранить введённые пароли навсегда (в менеджер паролей) или временно (до конца сессии).
• Нужно предусмотреть отказ от шифрования файла/имени файла - в этом случае проводить операцию без шифрования.
• Надо научить плагин удалять сохранённые пароли.

[pozitronik]

Текущее состояние шифрования имен файлов:
Довольно просто удалось отказаться от создания каталогов. Шифрованное имя файла - это просто пачка байтов, которая, для сохранения в виде имени файла кодируется в представление Base64. Base64 допускает содержание символа "/", который трактуется, как разделитель каталогов. Простое преобразование избавляет от этого разделителя; теперь больше не требуется вычислять имя файла из пути.

Из-за кодирования в Base64 шифрованное имя файла в Облаке становится вдвое длиннее + удвоение из-за того, что работаем с юникодом - итого каждый символ исходного имени превращается в 4 символа имени в Облаке. Это нужно учитывать, чтобы вписаться а) в ограничения WFX API б) ограничения облака (и там и там лимит пути - 1024 символа) - т.е. нужно добавлять проверки.

Также нужно проверять существование удалённого и локального файла при шифровании дешифровке имени соответственно: поскольку шифрование для TC невидимо, он проконтролировать эти операции не может.

[ashumkin]

Избавиться от временного файла при аплоаде не удалось,

для этого пилится class helper с нужной функциональностью, скопированной из AddFile, но без использования файла
разве TIdMultiPartFormDataStream.AddFormField не делает то же, что и AddFile, но без файла?

[pozitronik]

Имхо, усложнение кода не оправдает избавления от временного файлика, но я подумаю.

[SchwarzKopf-M]

Оправдывает. Если посчитать сколько времени будет потрачено на лишний цикл сохранения и загрузки файла если файл боооооольшой и их несколько.

[ashumkin]

усложнение кода

не уверен, что это усложнение... особенно, помня о SOLID

[pozitronik]

• Плагин должен уметь показывать расшифрованные имена файлов сразу - опционально, и только при известном пароле. Этакая виртуальная шифрованная файловая система.

[pozitronik]

• Пофиксить конфликт с опцией CheckCRC
  CRC для слитого файла после расшифровки сравнивается с CRC шифрованного файла в облаке => всегда будут различаться.

[ashumkin]

offtopic:
мне вот любопытно:
а что отслеживать галки в комментах удобнее, чем отдельные issue + labels?

[pozitronik]

По удобству - без разницы. Галка - подзадача внутри большого тикета, мне кажется логичным делать так.

[ashumkin]

не хотелось бы "учительствовать"
но мне кажется это неэффективным

например, вы не сможете быстро посмотреть всё ли вы доделали/исправили (получить список открытых багов/задач по данной фиче)

З.Ы. предлагаю посмотреть в как задумано

[pozitronik]

Спасибо, я подумаю над этим.

[lessnik]

Еще раз попробую склонить вас в сторону EncFS..
Преимущества:

• Не нужно "изобретать велосипед" с шифрованием имен файлов и содержимого, все уже придумано. Ни один год храню на облаке архив (порядка 600 гигов уже) зашифрованный данным алгоритмом, бана все еще не словил.
• Кроссплатформенность. Есть реализации этого стандарта для всех популярных осей, включая Андроид.
• Независимость от плагина. В случае если админы мыйл.ру "закрутят гайки" с возможностью стороннего доступа к облаку все зашифрованное собственным форматом плагина можно будет попросту слить в унитаз! В случае же шифрования с помощью EncFS свои файлы всегда можно будет достать, пусть даже и не через ТоталКомандер.

Пы.Сы. Кстати, тут же на Гитхабе есть неплохая реализация под виндовс: https://github.com/jetwhiz/encfs4win
Если не удастся напрямую прикрутить их библиотеки, доступны исходники.

[pozitronik]

А я с удовольствием склонюсь, на самом деле, - успел пощупать encfs в бою, и мне ок. Там тоже есть вопросы, но плюсы перевешивают.
Но что, как и когда - пока вопрос, времени на пет-проекты по нулям.

[commensal]

Подскажите есть подвижку в этой области?

Держу весь архив 2Tb на двух аках в мейле. Шифрую encFs только содержимое, чтобы самому же можно было разобраться и скачать только то что нужно и локально дешифрануть.

Плагин дешифрующий на лету был бы очень очень кстати. Пока приходится загружать (и в него же обратно) из виртуальной папки с параметром --reverse. Сами файлы локально нешифрованы. Очень нравится encFs в этом плане.

[pozitronik]

Подвижек нет, причины - сообщением выше.

[pozitronik]

• При вводе неправильного сессионного пароля шифрования (определяется по сохраняемому хешу предыдущего пароля) плагин предлагает действия на выбор.