Безопасно ли использовать приватный ключ в качестве пароля для шифрования?

Прошу подсказать спецов по криптографии. Суть вопроса. Я делаю систему на основе web cryptography API, и мне надо хранить в общедоступном хранилище зашифрованные данные пользователей. Каждый пользователь уже имеет пару ключей ECDSA, но использовать эти ключи непосредственно для шифровки не получается. Я думаю шифровать ключом AES-GCM, который обычно генерируется из пароля, и которым можно шифровать. Но я хочу вместо пароля использовать уже имеющийся приватный ECDSA ключ пользователя для создания AES-GCM ключа, чтобы не заставлять пользователя помнить и вводить ещё один пароль. Вопрос: безопасно ли это? Или это создаёт угрозу по зашифрованным сообщениям (а их будет много, при этом небольших по объёму, скажем, 10000 по 1 КБ) хакнуть приватный ECDSA ключ пользователя?

Возможно, есть более прямой способ решить мою проблему? Например, можно зашифровать ассиметричным шифрованием симметричный ключ, которым уже шифровать сообщение, но в web cryptography API с этим проблемы, т.к. ассиметричный ключ для шифрования ECDSA она использовать не даёт. Это можно сделать с ассиметричным ключом RSA-OAEP, но это надо заводить ещё один ключ на каждого пользователя. А зачем, если можно этого избежать. И потом, ассиметричное шифрование, судя по моим экспериментам, работает существенно дольше, чем генерация ARS-GCM с приватного ключа ECDSA.

Если нужна ещё какая-то конкретика по моему вопросу -- дайте знать, я поясню.

0

d3fine,
Не желательно такими хаками пользоваться. Это создаст вместо двух разных векторов нападения (на AES и ECDSA ключи) два связанных между собой вектора, что есть уже уязвимость или помощь взломщику (тут уже как посмотреть). Суть атаки будет сводиться к "встрече на середине" (meet in the middle), когда злоумышленник с одной стороны будет перебирать ключ шифрования со стороны AES, а с другой стороны ключ ECDSA, параллельно создавая таблицу ключей. В итоге, из-за атаки парадокса дней рождения (на которой и базируется собственно встреча на середине) ключ фактического шифрования для AES снизится с 2^128 до +- 2^(128/2)=2^64 (для 128-битного ключа) если стойкость ключа ECDSA примерно сопоставима с ключом AES. Получившаяся длина ключа в текущих реалиях будет являться небезопасной. Плюс к этому, может немалую роль сыграть и сам ключ AES, который генерируется из пароля. Т.к. пароли представляют собой невысокую энтропию, то и сам конечный метод описанного взлома может быть ещё более эффективным.
Криптография - консервативная наука и чаще всего чем проще решение (даже если оно кажется избыточным или деревянным), тем оно надёжнее. В вашем решении действительно будет лучше использовать два ключа - один со стороны ECDSA, отвечающий за целостность и аутентификацию хранимых/передаваемых данных, другой со стороны AES, отвечающий за их конфиденциальность.

0

UseMuse, спасибо за ответ.

Расширю тогда секрет пользователя дополнительным случайным ключом AES-GCM, который не получается из приватного ключа ECDSA. И буду использовать этот другой ключ для шифрования.

0