web-dev-qa-db-ja.com

デジタルテスタメント

私が読んだ典型的な解決策である、物理的な金庫を使用せずに「デジタル証」を保存する方法を考えていました。これが私の考えです。

  • GPG /その他の標準ツールを使用して強力なキーペアを生成します。
  • 前のキーを使用して機密情報を暗号化します。
  • 十分な冗長性を備えた公開鍵を保存します。
  • 秘密共有ツールを使用して秘密鍵を分割します。秘密を取り戻すために3株、2株としましょう。
  • 私の3人の証人に、彼らの共有の書き留めたコピーと暗号化されたペイロードを保管させます。

このようにして、共有を更新せずにペイロードを更新できます(より機密性の高い情報を後で保存する必要がある場合)。

私はほとんど暗号/セキュリティ愛好家ではありません、そして私は複雑さがセキュリティの敵であり、あなた自身のセキュリティスキームを考案することは問題を求めていることを知っています。

この方法の欠点は何ですか?

2
user72036

私の知る限り、すべてのプリミティブを正しく選択すれば、これは安全です。

そのようなシステムを使用したい場合(そして私はすでにそれについて考えました)、私は同様のアプローチを採用します。

ただし、1つの変更をお勧めします。

目撃者にペイロードを与えないでください。
彼らに共有を与えて、彼らが秘密鍵を再構築し、あなたの場所(あなたの家かもしれない?インターネットダウンロードサーバーかもしれない?)に行き、そこで鍵を再構築できるようにします。そうすれば、共有を配布した後でも、(必要に応じて)ペイロードを変更できます。

あなたのアイデアの素晴らしいところは、秘密鍵のコピーを自分で必要としないことです。公開鍵を使用してペイロードを暗号化するだけです。

ここで、プリミティブに関するいくつかの(標準)メモ:

  1. 必ず非常に長いキーを使用してください。私の計画は、次の2世紀に適切なセキュリティを提供する655536ビットのRSAキーを使用することでした。

50年以上データを保護したい場合は、次の3つのポイントが適用されます。

  1. ペイロードを保護するために使用する対称暗号が適切であることを確認してください。 (長いキーサイズ、複数のアルゴリズム構造、複数の暗号化。128ビットでは不十分です。512ビット以上+異なる暗号設計が必要です-> Feistel、SPN、ARXなど)
  2. 使用する認証が適切であることを確認してください。 (秘密鍵認証で十分ですが、構造と長い鍵サイズが異なります->スポンジ、Skeinのようなsth。、SHA-512のようなsth。..)
  3. PBKDFパラメーターを定期的に(おそらく年に1回?)更新するか、非常に積極的なパラメーター(今日の計算に数時間/日かかるもの)を使用するようにしてください。
1
SEJPM