問題タブ [cryptography]

s-box に関するこの記事の余分なビットがどこから来ているのかわかりません。s-box が入力と出力に同じ数のビットを取り込まないのはなぜですか?

数か月前、私は Web アプリケーション用に一意でランダムなコードを実装する任務を負っていました。コードはユーザーフレンドリーでできるだけ小さくする必要がありますが、基本的にランダムである必要があります (ユーザーがシーケンスの次のコードを簡単に予測できないようにするため)。

最終的に、次のような値が生成されました。

残念ながら、私は実装に満足することはありませんでした。Guid は問題外でした。ユーザーが入力するには大きすぎて難しかったのです。4 桁または 5 桁の文字/数字の行に沿って何かを期待していましたが、特定の実装では、エンコードした場合、著しくパターン化されたシーケンスが生成されます。 9 文字未満。

最終的に行ったことは次のとおりです。

データベースから一意の連続した 32 ビット ID を取得しました。次に、それを 64 ビット RANDOM 整数の中央ビットに挿入しました。簡単に入力および認識できる文字 (L、l、1、O、0 などの混同しやすい文字をスキップする AZ、az、2-9 など) のルックアップ テーブルを作成しました。最後に、そのルックアップ テーブルを使用して、64 ビット整数を base-54 エンコードしました。上位ビットはランダムで、下位ビットはランダムでしたが、中央のビットは連続していました。

最終結果は、GUID よりもはるかに小さく、ランダムに見えるコードでしたが、まったくそうではありませんでした。

この特定の実装に満足したことはありません。あなたたちはどうしたでしょう？

正確に 2 つのキー (パスワードベースの可能性があります) を使用してデータ暗号化を実現し、データを復号化するには 2 つのキーのうちの 1 つ (いずれか 1 つ) のみを必要とするための基本は何ですか?

たとえば、データはユーザーのパスワードと会社のパスワードで暗号化され、ユーザーまたは会社はデータを復号化できます。どちらも他のパスワードを知りません。暗号化されたデータのコピーは 1 つだけ保存されます。

公開鍵/秘密鍵という意味ではありません。おそらく対称鍵暗号化を介しており、鍵を XOR して暗号化に使用するようなものかもしれません。

更新:キーの保存をまったく必要としないソリューションも見つけたいと思います。

.NETSystem.Security.Cryptography名前空間には、クレジット カードの詳細を暗号化するために使用できる、かなり当惑するようなアルゴリズムのコレクションがあります。どちらがベストか？

比較的短い文字列の場合、明らかに安全である必要があります。

編集: 私は英国にいますが、3 桁の CVV 番号が決して保存されない限り、暗号化されたクレジット カードの詳細を保存しても問題ないことを理解しています。そして、すばらしい回答をありがとうございました。

以前に抱えていた問題に直面しています。それを解決する方法についての私の参照が見つかりません。

これが問題です。以下のコードを使用して、クライアント アプリケーションの app.config の接続文字列セクションを暗号化します。

問題は、営業担当者が退職したことです。古いラップトップは新しい営業担当者に送られ、新しいユーザーのログインの下で、これを行おうとするとエラーが発生します。エラーは次のとおりです。

C ++forWindowsで記述された既存のアプリケーションがあります。このアプリケーションは、Win32 CryptoAPIを使用して、データを暗号化/復号化するためのTripleDESセッションキーを生成します。1つのトリックの指数を使用して、セッションキーをblobとしてエクスポートします。これにより、blobを復号化された形式でどこかに保存できます。

問題は、これを.NETアプリケーション（C＃）でどのように使用できるかということです。フレームワークは、CryptoAPIが実行していることの多くをカプセル化/ラップします。問題の一部は、 Microsoft Enhanced Cryptographic ProviderのTripleDESアルゴリズムが168ビット（56ビットの3キー）であるとCryptAPIが述べていることです。ただし、.NET Frameworkは、キーが192ビット（64ビットの3キー）であると述べています。どうやら、.NETフレームワークの3つの余分なバイトはパリティ用ですか？

とにかく、blobからキー部分を読み取り、それを.NETアプリケーションで使用できるようにする必要があります。現在、.NETでキーを使用しようとすると、期待した結果が得られません。復号化は惨めに失敗しています。どんな助けでも大歓迎です。

アップデート：

私はこれを解決する方法に取り組んでおり、時間内に投稿する解決策を考え出しました。ただし、それでも他の人からのフィードバックをいただければ幸いです。

少なくとも 128 ビット キーで暗号化して機密データを保存する必要があります。javax.crypto パッケージを調べたところ、PBEWithMD5AndDES や PBEWithSHA1AndDESede など、56 ビットと 80 ビットまでの暗号化を提供する特定の暗号名があることがわかりました ( http://en.wikipedia.org/wiki/DESede )。

私は他の人の投稿を参照しましたが、それらは主にRSAを使用しており、私の理解では、RSAは一般に通信データの暗号化に適しています（秘密鍵と公開鍵のペアを使用）。私のニーズは異なります。データを保存し、復号化して元に戻したいだけです。したがって、秘密鍵と公開鍵のペアは必要ありません。

これについて何か考えがあれば教えてください。

Bouncy Castle APIはスレッドセーフですか? 特に、

アプリで基本レベルの暗号化をサポートするために、シングルトン Spring Bean を作成する予定です。これは Web アプリケーションであるため、一度に複数のスレッドがこのコンポーネントにアクセスする可能性が高くなります。したがって、ここではトレッドの安全性が不可欠です。

Bouncy Castle を使用してこのような状況に遭遇した場合はお知らせください。

データ ファイルを暗号化し、パスワードで保護できる小さなデスクトップ アプリを作成しています (つまり、解読するには正しいパスワードを入力する必要があります)。暗号化されたデータ ファイルを自己完結型で移植可能にしたいので、認証をファイルに埋め込む必要があります (またはそう思います)。

私が知っていることに基づいて、実行可能で論理的に見える戦略があります (これはおそらく危険であるには十分です) が、それが実際に優れた設計であるかどうかはわかりません。だから教えてください：これはクレイジーですか？それを行うためのより良い/最良の方法はありますか?

• ステップ 1: ユーザーは、「MyDifficultPassword」などの平文のパスワードを入力します。
• ステップ 2: アプリはユーザー パスワードをハッシュし、その値を対称キーとして使用してデータ ファイルを暗号化/復号化します。例: "MyDifficultPassword" --> "HashedUserPwdAndKey"。
• ステップ 3: アプリはステップ 2 のハッシュ値をハッシュし、新しい値をデータ ファイル ヘッダー (つまり、データ ファイルの暗号化されていない部分) に保存し、その値を使用してユーザーのパスワードを検証します。例: "HashedUserPwdAndKey" --> "HashedValueForAuthentication"

基本的に、Web サイトのパスワードを実装する一般的な方法 (つまり、OpenID を使用していない場合) から推測しています。これは、ユーザーのパスワードの (ソルト化された) ハッシュを DB に保存し、実際のパスワードを決して保存しないことです。 . しかし、対称暗号化キーにハッシュ化されたユーザー パスワードを使用しているため、認証に同じ値を使用することはできません。したがって、もう一度ハッシュして、基本的に別のパスワードと同じように扱い、二重にハッシュされた値をデータ ファイルに保存します。そうすれば、ファイルを別の PC に持っていき、パスワードを入力するだけで復号化できます。

では、この設計は合理的に安全なのか、それともどうしようもなくナイーブなのか、あるいはその中間なのか? ありがとう！

編集: 明確化とフォローアップの質問: ソルト。
ソルトは有用であるためには秘密にしておく必要があると思いましたが、あなたの回答とリンクはそうではないことを示唆しています. たとえば、 erickson によってリンクされたこの仕様(以下) は次のように述べています。

したがって、ここで定義されているパスワードベースの鍵導出は、パスワード、ソルト、および反復回数の関数であり、後者の 2 つの量を秘密にしておく必要はありません。

これは、ハッシュ化されたキーと同じ場所/ファイルにソルト値を保存でき、ハッシュ時にソルトをまったく使用しない場合よりも安全であることを意味しますか? それはどのように機能しますか？

もう少しコンテキスト: 暗号化されたファイルは、他のユーザーと共有したり復号化したりすることを意図したものではなく、実際にはシングル ユーザー データです。しかし、完全に制御していないコンピューター (職場など) の共有環境に展開し、ファイルをコピーするだけでデータを移行/移動できるようにしたい (自宅や別の場所で使用できるようにするため)ワークステーションなど）。

非対称暗号化キーは、主要なキー コンテナー形式間で基本的に相互変換可能ですか? たとえば、X.509 キー ファイルを PGP または OpenGPG キー ファイルに変換できますか?

そして、答えが「はい」であると仮定すると、1 つの鍵ペアをどのような形式でも保持し、その機会に必要なコンテナー ファイル形式に変換することは「セキュリティ ニュートラル」でしょうか?

X.509、OpenGPG、SSH のキー ペアがすべて RSA であるのに、非常に多くのキー ペアを維持することに少しうんざりしています。