Разница в том что ни сервер ни клиент не могут предсказуемо повлиять на итоговое значение и значит выбрать что-то уязвимое.
Если речь идет об индивидуальном ключе файла, то это все-таки соль (если сервер принимает участие), а сам ключ получается из мастер-ключа filekey = kdf(masterkey, randomsalt) или hmac(masterkey, randomsalt).
Точно также можно стереть симметричный ключ. Лично мне важнее возможность держать ключ (в виде пароля) в голове, чем возможность его разбить молотком (в случае токена). Если асимметричная криптография используется без аппаратных средств шифрования, то разницы с симметричной нет.
Даже с аппаратным шифрованием, если сравнивать по пунктам, то преимуществ у асимметричной схемы очень мало, тк большая их часть обходится «некриптографическими» атаками, типа затроянивания.
Только, если вы файл один раз зашифровали и никогда больше не использовали, то ассиметриный случай выигрывает. Но это настолько нетипичный случай использования, что строить дизайн хранилища ориентируясь на него бессмысленно. Гораздо проще навесить еще один уровень шифрования сверху, а не на уровне облачного хранилища.
Т.к. случайное число (соль) разделяется между сервером и клиентом, лучше его генерировать на сервере из заведомо надежного источника ГСЧ.
с
занимаюсь профессионально шифрованием
Т.к. даже дилетанту очевидно, что если очень хочется, то можно по-XOR-ть случайное число клиента (неизвестное серверу на данном этапе) с тем что вернет сервер. Но заменять его это, извините, полный бред. Если совсем правильно, то сначала обмениваются хешами солей, а потом самими солями и итоговая соль это «соль1^соль2».
Мда, давайте зашифруем всё публичным ключом, а приватный сотрём. Безопасности будет через край, а полезности ноль.
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
У каждого файла свой уникальный ключ, проблем с расшариванием нет. Есть проблема передачи ключа, которая перекладывается на пользователя.
Во-первых это сервис онлайн хранения данных, дизайн на основе токенов и асимметричных ключей будет настолько неудобен, что никто таким сервисом пользоваться не будет.
Во-вторых если данными вы пользуетесь хоть иногда, то независимо какой у вас там супер приватный ключ в суперсекретном токене, вам еще нужен софт который этот токен использует и проблема нечестности сервиса возвращается.
Трояны и социальные виды атак относятся к другой области.
Наконец-то мы пришли к очевидному. Большая часть ваших претензий не относится к дизайну криптографической системы. Если кто-то может поменять код отдаваемый index.html, он также может просунуть закладку в очередной апдейт LastPass и никакой токен от этого не спасет.
Если их трех производных ключей один скомпрометирован это никак не поможет угадать другие два. Так что это все-таки три разных ключа.
С какого бока вообще нужна асимметричная криптография в облачном хранилище? Она нужна когда есть необходимость обмена сообщениями между различными сущностями.
а) Что такое «симметричная криптография на внешних сервисах»?
б) Не вижу проблемы. Если есть риск компрометации одного пароля, то также есть риск компрометации обоих.
Я не знаю как оно на самом деле, но если их заявления имеют какое-то отношение к реальности, то схема должна быть примерно такой (упрощенно):
Регистрация:
— Пользователь вводит пароль, который преобразуется в симметричный ключ П1 через KDF (key derivation function). Этот пароль и ключ никуда и никогда не передаются! (но могут для удобства храниться локально).
— Генерируется случайный мастер-ключ М1 (или несколько). Все они шифруются ключом П1 и отсылаются на сервер.
Загружаем файл:
— Запрашиваем мастер ключ М1 и расшифровываем их нашим секретным ключом П1.
— Шифруем файл Ф1 случайным ключом К1. Ключ К1 шифруем мастер-ключом М1. Файл и его уникальный ключ отсылаем на сервер.
Итого на сервере хранится:
— Файл Ф1 (зашифрованный К1)
— Ключ К1 (зашифрованный М1)
— Мастер ключ М1 (зашифрованный П1)
Скачиваем:
— Запрашиваем М1, расшифровываем его нашим П1
— Запрашиваем К1, расшифровываем его полученным М1
— Запрашиваем файл, расшифровываем его К1
Т.е. пользователю достаточно только знать свой пароль, который однозначно преобразуется в его секретный ключ П1. Сервер этот ключ никогда в глаза не видит.
Бонус: смена пароля
1. Качаем М1, расшифровываем его П1
2. Зашифровываем новым паролем П2 и закачиваем обратно на сервер
Если они сейчас ничего не сохраняют, то даже когда им паяльник куда надо вставят они ваш пароль никому не скажут если вы перестанете пользоваться недоверенными клиентами.
А сохраняют/отправляют ли сейчас, кто вам лично мешает каждый раз проверять загруженный javascript на предмет закладок. Возможность есть? Есть! Какие проблемы?
Как вы вообще понимаете гарантированную безопасность? Всегда будет кем-то написанный код и его надо смотреть, а не кричать на каждом углу «ваш пароль могут стырить»
Документацию на API пока не выложили, вы действительно отреверсили протокол или гадаете? «Сервер присылающий случайное число» это конечно сильно, такого не бывает нигде и никогда (если МЕГА напишет «ключи только из наших случайных чисел» то тут конечно вопросов уже не будет).
Единственное что можно уверенно заявить сейчас, это что официальный javascript клиент (без аудита кода и средств контроля целостности проверенного кода) не безопасен, с параноидальной криптографической точки зрения. Заявлять что весь сервис небезопасен, пока рановато. Ну и если потом появятся вменяемые сторонние клиенты, естественно аккаунт и пароль нужны будут новые.
Тут скорее всего приватный ключ шифруется симметричным ключом выведенным из пароля (pbkdf2 например) и в таком виде хранится на сервере. Это сделано для удобства доступа с других машин, и вообще-то в любом zero-knowledge хранилище (кроме Tarsnap) реализовано что-то подобное.
В FAQ кстати есть вопрос «а что если в будущем вы тайком измените свои скрипты чтобы получить пароль/ключ?». Ответ — пользуйтесь другими интерфейсами, которым вы доверяете (opensource?) и которые появятся когда опубликуют API.
В общем, пока API не опубликовано рано безоговорочно заявлять что сервис не безопасен в принципе. Текущая javascript реализация действительно выглядит сомнительно, но это не исключает возможности написать безопасный клиент.
В Берлине на городском транспорте проверяльщики билетов никогда не ходят в униформе. Они прикидываются шлангами и шифруются пока не закроются двери, и тогда вдруг «немытый панк с собакой» вдруг достает удостоверение и объявляет «Fahrscheine zur Kontrolle bitte».
Самое забавное, что в Дании кондукторы совершенно не маскируются и при этом всё равно почти всегда кого-то ловят) По сравнению с Берлином где заяц играющий в «угадай кондуктора» обречен на провал.
Ага, это то что я называю «датский кондиционер» — если температура больше 25 можно с работы уйти пораньше и заглянуть на пляж. Экономика сильно не страдает, тк случается это далеко не каждый год)
Если речь идет об индивидуальном ключе файла, то это все-таки соль (если сервер принимает участие), а сам ключ получается из мастер-ключа filekey = kdf(masterkey, randomsalt) или hmac(masterkey, randomsalt).
Даже с аппаратным шифрованием, если сравнивать по пунктам, то преимуществ у асимметричной схемы очень мало, тк большая их часть обходится «некриптографическими» атаками, типа затроянивания.
Только, если вы файл один раз зашифровали и никогда больше не использовали, то ассиметриный случай выигрывает. Но это настолько нетипичный случай использования, что строить дизайн хранилища ориентируясь на него бессмысленно. Гораздо проще навесить еще один уровень шифрования сверху, а не на уровне облачного хранилища.
с
Т.к. даже дилетанту очевидно, что если очень хочется, то можно по-XOR-ть случайное число клиента (неизвестное серверу на данном этапе) с тем что вернет сервер. Но заменять его это, извините, полный бред. Если совсем правильно, то сначала обмениваются хешами солей, а потом самими солями и итоговая соль это «соль1^соль2».
Для генерации случайных паролей нужна не «асимметричная криптография», а (сюрприз) генератор случайных чисел.
У каждого файла свой уникальный ключ, проблем с расшариванием нет. Есть проблема передачи ключа, которая перекладывается на пользователя.
Во-первых это сервис онлайн хранения данных, дизайн на основе токенов и асимметричных ключей будет настолько неудобен, что никто таким сервисом пользоваться не будет.
Во-вторых если данными вы пользуетесь хоть иногда, то независимо какой у вас там супер приватный ключ в суперсекретном токене, вам еще нужен софт который этот токен использует и проблема нечестности сервиса возвращается.
Если их трех производных ключей один скомпрометирован это никак не поможет угадать другие два. Так что это все-таки три разных ключа.
Ключи обязаны быть разными, пароль может быть один en.wikipedia.org/wiki/PBKDF2.
Не понимаю зачем клиенту спрашивать у сервера какие-то случайные числа?
а) Что такое «симметричная криптография на внешних сервисах»?
б) Не вижу проблемы. Если есть риск компрометации одного пароля, то также есть риск компрометации обоих.
Правильно один ключ и не используется, как минимум из пароля нужно получить три производных ключа: для аутентификации, шифрования и MAC.
В правильно реализованной описанной схеме что-то перехватывать бесполезно habrahabr.ru/post/166847/#comment_5766847
Регистрация:
— Пользователь вводит пароль, который преобразуется в симметричный ключ П1 через KDF (key derivation function). Этот пароль и ключ никуда и никогда не передаются! (но могут для удобства храниться локально).
— Генерируется случайный мастер-ключ М1 (или несколько). Все они шифруются ключом П1 и отсылаются на сервер.
Загружаем файл:
— Запрашиваем мастер ключ М1 и расшифровываем их нашим секретным ключом П1.
— Шифруем файл Ф1 случайным ключом К1. Ключ К1 шифруем мастер-ключом М1. Файл и его уникальный ключ отсылаем на сервер.
Итого на сервере хранится:
— Файл Ф1 (зашифрованный К1)
— Ключ К1 (зашифрованный М1)
— Мастер ключ М1 (зашифрованный П1)
Скачиваем:
— Запрашиваем М1, расшифровываем его нашим П1
— Запрашиваем К1, расшифровываем его полученным М1
— Запрашиваем файл, расшифровываем его К1
Т.е. пользователю достаточно только знать свой пароль, который однозначно преобразуется в его секретный ключ П1. Сервер этот ключ никогда в глаза не видит.
Бонус: смена пароля
1. Качаем М1, расшифровываем его П1
2. Зашифровываем новым паролем П2 и закачиваем обратно на сервер
А сохраняют/отправляют ли сейчас, кто вам лично мешает каждый раз проверять загруженный javascript на предмет закладок. Возможность есть? Есть! Какие проблемы?
Как вы вообще понимаете гарантированную безопасность? Всегда будет кем-то написанный код и его надо смотреть, а не кричать на каждом углу «ваш пароль могут стырить»
Единственное что можно уверенно заявить сейчас, это что официальный javascript клиент (без аудита кода и средств контроля целостности проверенного кода) не безопасен, с параноидальной криптографической точки зрения. Заявлять что весь сервис небезопасен, пока рановато. Ну и если потом появятся вменяемые сторонние клиенты, естественно аккаунт и пароль нужны будут новые.
В FAQ кстати есть вопрос «а что если в будущем вы тайком измените свои скрипты чтобы получить пароль/ключ?». Ответ — пользуйтесь другими интерфейсами, которым вы доверяете (opensource?) и которые появятся когда опубликуют API.
В общем, пока API не опубликовано рано безоговорочно заявлять что сервис не безопасен в принципе. Текущая javascript реализация действительно выглядит сомнительно, но это не исключает возможности написать безопасный клиент.
За одеждой по-моему лучше сгонять в Германию, навестить друзей и заодно закупиться)
Электроника и прочее: amazon.de и amazon.co.uk