Облачные бэкапы

С переездами с ноутбука на ноутбук снова посетила мысля о том, что неплохо было бы все хозяйство зааплоадить куда-нибудь в интернет (и даже возможно разделить офисный бук и домашний, сохранив общую среду). Структурировано оно уже неплохо (я когда-то писал уже про это) и весь переезд заключается в копировании одной папки и запуске пары скриптов для создания junction points (симлинков, типа).
В простейшем случае можно было бы купить подписку на несколько десятков гигабайт от dropbox/msft/google, но есть две проблемки:
1. ключи и пароли. какой-нибудь дропбокс традиционно хранит свою аутентификацию на кучке девайсов, потеря одного автоматически компромайзит все, что совсем не круто
2. синхронизировать нужно проектные файлы тоже, а всякие там студии при сборке рядом раскладывают гигабайты сборочных файлов. которые в принципе нужны, но бэкапить их совершенно незачем
Я года два-три назад писал про гуглодрайв, когда он только вышел, что удивлен, что они как и дропбокс не сделали возможность синхронизировать файлы по маске (или хотя бы эксклюдить по маске). С тех пор, если я правильно понимаю, ничего не изменилось.
В итоге имеем два реквайрмента:
1. выбор файлов для синхронизации по маске
2. шифрование
С локальными бэкапами все просто. Сервачок, шара, раз в сутки умный скриптик по маске жмет файлики из нужных подразделов в зашифрованный архив и кладет на шару.
С облаками как-то непросто все получается.
Я пока вижу два одинаково странных варианта:
1. заюзать утилиту CryptSync, которая умеет миррорить каталоги сжимая каждый файл отдельно в запароленный 7zip архив (результирующий каталог - синхронизируется в интернет)
2. rcync'аться по маске в отдельный TrueCrypt раздел, а уже его в виде огромного блоба синхронизировать в интернет
Оба варианта в виде фичи имеют необходимость во второй копии файлов. Первый при этом шифрует каждый файл отдельно, что с точки зрения криптографии не очень гуд (хотя я не от NSA защищаюсь). Второй - сильно зависит от способности клиента конкретного сервиса детектить изменения по блокам, а не тупо аплоадить файл при каждом изменении.
А еще, говорят, что у Amazon AWS есть вполне удобное API, к нему можно написать велосипедклиента, который будет делать выборку по маске и шифровать самостоятельно.

Mega

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

Однако ж, решил проверить. Скачал прогу синхронизации, зарегился с простым паролем. Прожка попросила валидировать имейл, в письме была ссылочка, по которой открылась страничка с арканойдом и блоками в форме букв NSA :) Типа, так они энтропию собирают для создания RSA ключа. Окей, сгенерили ключик.
Далее забавно. Я пошел на сайт и сменил пароль на более крутой. По-идее, подключенный клиент должен был тут же возмутиться и спросить новый пароль. Однако ж, я добавил в сторадж новый файл через клиент и тот успешно его зааплоадил, файл потом открылся через браузер (скачался и декодировался локально жабаскриптом). Опа. Обратный трюк тоже работает, если зааплоадить файл через сайт (в браузере вбит новый пароль), то тот успешно скачивается клиентом и открывается.
Собственно, выходит что кодируется файл нифига не паролем, а каким-то ключиком полученным с сайта. Или я чего-то не понимаю в криптографии, или заявление что никто кроме юзера не может раскодировать данные - просто маркетинговый булшит.
UPD: Я тут еще немного подумал, скорее всего они с введением возможности менять пароль изменили саму схему шифрования:
Логично предположить что теперь у них паролем защищены сами сгерененные ключи (как с ssh ключами, например) и чтобы декодировать данные нужно с начала декодировать ключик.
Тогда понятно, что ключ сам не меняется, а при смене пароля они его тупо декодируют старым и заново защищают новым паролем.
И тогда понятно почему на локальном клиенте все декодируется, потому что ключ де-факто не менялся.
Т.е. фактически на серваке меги лежит пара - публичный (для шифрования) и приватный (для дешифрования) ключики, приватный при этом защищен паролем юзера. Но все равно как-то неуютно, при такой схеме вполне незаметно для юзера можно вообще не защищать ключи.