2048 ビットの RSA 秘密鍵を保護しようとしています (機密性と可用性)。私はそれを行う方法についてより多くの情報を探しており、秘密共有スキームを使用することを考えています (シャミールの秘密共有は問題ありません)。

それは最良の選択肢ですか？これを達成するための GNU/GPL ソフトウェア実装を知っている人はいますか?

「ssss」 ( http://point-at-infinity.org/ssss/ ) を見ましたが、シークレットは最大 128 ASCII 文字である必要があり、2048 ビットの RSA 秘密鍵には短すぎます。

ご協力いただきありがとうございます。

iOS は ECC ベースの暗号化をサポートしていないという 2013 年の回答と、OpenSSL の使用を推奨する回答を見つけることができました。Security Framework ReferenceにTLS_ECDH の定義がいくつかありますが、ECC ベースが完全にサポートされているかどうかはわかりません。secp256r1 に基づいてキー ペアを生成し、相手の 64 バイトの公開キーを使用して、ECDH を使用して共有シークレットを生成できるようにする必要があります。また、署名の署名と検証に ECDSA を使用できる必要もあります。

CommonCrypto で、ECDH (楕円曲線 Diffie-Hellman) に基づいて共有シークレットを生成する方法を探しています。このhttps://github.com/surespot/surespot-ios/blob/master/surespot/encryption/EncryptionController.mmのような独自の実装を見つけることができますが、これは CommonCrypto を使用していません。共有秘密を計算する方法は、鍵交換と呼ばれることがあり、共有秘密の計算が含まれます。適切なドキュメントへのリンク、または CommonCrypto を使用して楕円曲線 Diffie–Hellman に基づいて共有シークレットを生成する例へのリンクを送信できますか?

OAuth 1.0A 共有シークレットの利点は何ですか?

私が理解していることから、クライアントは、クライアント ID と共有シークレットの両方を受け取る保護されたリソース サーバーに登録できます。OAuth 1.0A 仕様を何度も読んだことがありますが、次の2 つの質問を理解するのに苦労しています。

• なぜ共有シークレットが必要なのですか?
• サーバーがクライアントを検証するのにクライアント識別子が十分でないのはなぜですか? 共有シークレットが提供する追加のセキュリティ上の利点は何ですか?

仕様を引用するためにあなたを探しているわけではありません - 仕様が何を言っているのか理解するのに苦労しているので、この時点でもっと簡単な説明が必要です（とにかく共有秘密の詳細には触れていません） .

Java の WritableRaster クラスの仕組みがわかりません。ドキュメントを見てみましたが、ピクセルの配列から値を取得する方法がわかりません。さらに、ピクセルの配列が何で構成されているかわかりません。

ここで説明します。

私がやりたいことは: 画像に関する Shamir の秘密の共有です。そのためには、BuferedImage イメージでイメージをフェッチする必要があります。秘密の画像を撮ります。画像の各ピクセルで「関数」を実行して共有を作成します。（基本的にはピクセル値を何かで変更します）

スニペット:

// これらの RGB 値を取得します。関数を使用してそれらを変更し、int 値を返します。このようなもの：

// この 2 次元配列のピクセルには新しい色の値がすべて含まれていますよね? しかし今、この新しい値を使用してイメージを構築したいと考えています。だから私がしたことはです。最初に、このピクセル配列をリストに変換しました。このリストには、新しい画像のピクセル値が含まれています。しかし、RasterObj.setPixels() メソッドを使用して画像を作成するには、RGB 値の配列が必要です [私はここで間違っている可能性があります!] リストの個々の値を取得し、rgb 値を見つけて、新しい 1D 配列 pixelvector に連続して配置します..このようなもの（r1、g1、b1、r2、g2、b2、r3、g3、b3 ...）

各ピクセルの単一のピクセル値が含まれているため、リストのサイズは w h です。ただし、各ピクセルの r、g、b 値が含まれているため、新しい配列 pixelvector のサイズは w h*3 になります。

次に、画像を形成するためにこれを行います：スニペット

setPixels() メソッドに単一のピクセル値を持つ配列を配置すると、その関数から返されません! しかし、個別のr、g、b値を持つ配列を配置すると、関数から返されます。しかし、 share1 、 share 2 などに対して同じことを行っています。青の色合いしか得られません。そのため、画像を再構築できるかどうかさえわかりません..

PS - これは私が知っている非常にばかげたコードのように見えるかもしれません。しかし、これを行い、Java で画像について学ぶのに 1 日しかありませんでした。だから私はできる限りのことをしています。

ありがとう..

互いの API エンドポイントを使用する 2 つの Docker コンテナーをリンクしました。これらの API エンドポイントはシークレットによって保護され、コンテナーの起動時に生成されます。これらのサービス間でこれらの秘密を静的なもの (ハードコーディングなど) を行わずに安全に共有する方法を探しています。これらのサービスは を使用して作成およびリンクされ、環境変数を使用してシークレットをオーバーライドすることができます。ただし、この動作は本番環境では推奨されません。docker-compose

私の場合、これらの秘密を配布する最も安全な方法は何ですか?

私が検討したこと：

• これらのシークレットをファイルとして保存する中央データ コンテナーを使用します。その後、クライアントはこのコンテナーにリンクし、ファイル内のシークレットを検索できます。

このアプローチの大きな欠点は、コンテナーが同じノードで実行されるように制限されることです。

• docker-composeコンテナーをデプロイする前に、これらのランダムなシークレットがハードコーディングされたファイルを生成し ます。

このアプローチの欠点は、単純にdocker-composeファイルを使用することはできず、bash スクリプトに限定して、これらのシークレットと同じくらいミッション クリティカルなものを生成することです。これは、ソリューションが秘密の変更に動的に適応できる必要があるという私の付記にも従わないでしょう。

サイドノート

最終的には、ソリューションが秘密の変更にも動的に適応できるようになることを望みます。たとえば、コンテナに障害が発生すると、コンテナは自動的に再起動し、新しいシークレットも生成されます。

crypto++ shamir の秘密共有クラスを使用して、ランダムに生成されたn 個の長いパスワードをk人のパーティ間で共有するためのプロトコルを構築しています。問題は、cryptop の sss についてインターネットで見つけたすべての例がファイル共有に基づいていることですが、これらのパスワードを保存するためにファイルを使用していません。それらはむしろメモリに保持され、後でネットワーク経由で送信されます。

この質問はcrypto++ フォーラムで見つけましたが、関連する質問と同じ問題に悩まされていました。誤って復元された ls-byte の問題を解決する方法がわかりません。

この作業を行う方法をいくつか提案してください。ありがとうございました