ECIES — Когда подписывать и шифровать одними и теми же ключами плохо?

Предположим, у меня есть открытый ключ для конкретного пользователя (возможно, извлеченный при использовании нового формата восстановления открытого ключа, включенного в транзакции P2SH и BIP32).

  • Можно ли использовать один и тот же ключ как для подписи, так и для шифрования?

Поскольку я получаю открытый ключ из сообщения, сценария PS2H или кошелька BIP32, я хочу убедиться, что все секреты (биткойны, закрытые ключи и конфиденциальность, связанные с BIP32) сохраняются и не существует риска для конфиденциальности.

  • Какие известны безопасные (или небезопасные) сценарии использования одного и того же ключа для подписи и шифрования?

Ответы (1)

Поскольку я получаю открытый ключ из сообщения, сценария PS2H или кошелька BIP32, я хочу убедиться, что все секреты (биткойны, закрытые ключи и конфиденциальность, связанные с BIP32) сохраняются и не существует риска для конфиденциальности.

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

Вам понадобится кто-то, кто больше разбирается в EC, например, Грегори Максвелл, чтобы ответить на вопросы, связанные с шифрованием, в биткойнах мы только подписываем и никогда не шифруем, так что я никогда глубоко не исследовал это. Я полагаю, что в более поздних наборах шифров SSL EC используется только для согласования ключей, а остальное передается симметричному шифру для целей скорости.

Помните, что биткойн-адреса, как правило, не предназначены для того, чтобы оставаться с ними, и основывать любую форму шифрования на чем-то, что по своей сути является одноразовым, вероятно, не особенно мудрая идея. Единственное реальное применение, которое у нас есть для функций подписи сообщений, — это для таких систем, как Eligius, у которых уже есть статический адрес из-за их функции, и нам нужно доказать, что тот же пользователь авторизует изменение.