問題タブ [encryption-symmetric]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
perl - 対称暗号化を使用したPerlの安全な改ざん不可能なURLコンポーネント?
OK、たぶん月曜日が悪いのですが、次のニーズがあり、部分的な解決策がたくさん見られますが、これを必要とするのは私が初めてではないはずです。明らかなことを見逃しています。
$client には 50 ~ 500 バイト相当のバイナリ データがあり、これを URL の途中に挿入し、顧客のブラウザに往復させる必要があります。これは URL の一部であるため、GET URL の 1K の「理論上の」制限に直面しています。また、$client は、顧客がデータをデコードしたり、検出されずに改ざんしたりすることを望んでいません。$client もサーバー側に何も保存しないことを好むため、これは完全にスタンドアロンである必要があります。エンコーディングとデコーディングの両方で、Perl コードで高速でなければなりません。
最後のステップは base64 にできると思います。しかし、最も理にかなった暗号化とハッシュ化の手順は何ですか?
aes - AES / Rijndael テスト ベクトル: どのパディング モード?
そこで、CBC モードの AES / Rijndael (128 ビット ブロックを使用) の既知の回答テストの これらのテスト ベクトルを調べてきました。 PKCS7?
algorithm - 整数の対称全単射アルゴリズム
32ビットの符号付き整数を別の32ビットの符号付き整数に1対1でマッピング(つまり、衝突なし)できるアルゴリズムが必要です。
私の本当の懸念は、関数の出力がランダムに見えるように十分なエントロピーです。基本的に私はXOR暗号に似た暗号を探していますが、それはより任意に見える出力を生成することができます。あいまいさはありますが、セキュリティは私の本当の関心事ではありません。
明確にするために編集します。
- キーペアなしで操作を元に戻すことができるように、アルゴリズムは対称である必要があります。
- アルゴリズムは全単射である必要があり、32ビットの入力番号ごとに32ビットの一意の番号を生成する必要があります。
- 関数の出力は十分にあいまいである必要があります。入力に1つだけ追加すると、出力に大きな影響を与えるはずです。
期待される結果の例:
F(100)= 98456
F(101)= -758
F(102)= 10875498
F(103)= 986541
F(104)= 945451245
F(105)= -488554
MD5と同じように、1つのものを変更すると、多くのことが変更される可能性があります。
私は数学関数を探しているので、整数を手動でマッピングすることは私にとって解決策ではありません。質問している人にとって、アルゴリズムの速度はそれほど重要ではありません。
security - 対称鍵の所有に基づいてクライアントを認証する方法は?
クライアントは SSL 経由で Web サービスを呼び出し、ユーザー名とパスワードで認証します。次に、サーバーが対称キーを生成し、それをクライアントに送り返します。
次に、クライアントはサーバーへの TCP 接続を確立し、ログイン メッセージを送信します。この時点で、クライアントを認証したいと思います。
私の考えは、クライアントによく知られた/静的なテキストを対称キーで暗号化し、これをキーを所有していることの証明として使用することです。
対称鍵はランダムに生成されるため、ここで静的なテキストを使用しても問題ありませんか?
任意の入力をいただければ幸いです。
python - AES+CTRを使用したPyCryptoの問題
対称暗号化を使用してテキストを暗号化するコードを書いています。しかし、それは正しい結果で戻ってこない...
ここで、復号化されたテキストは元のテキストとは異なります。
暗号についてはあまりよくわかりませんので、ご容赦ください。CTRモードでは、毎回ランダムなカウンターを提供するために「カウンター」機能が必要であることを理解していますが、キーが32バイトで、メッセージも16バイトの倍数であると主張するのに、なぜ16バイトである必要があるのでしょうか。これは正常ですか?
暗号化と復号化の間でカウンターが変わったため、元のメッセージに戻らないと思います。しかし、それでは、とにかく理論的にはどのように機能するのでしょうか?私は何が間違っているのですか?とにかく、私はこれを理解するまでECBに頼ることを余儀なくされています:(
java - AES/CBC/PKCS5Padding で「BadPaddingException: パッド ブロックが壊れています」を取得する
私の定数
暗号化
別のクラスでは、復号化を行います
これを実行すると、復号化時に doFinal で BadPaddingException が発生します。何が間違っていますか? CBC/PKCS5Padding と IV を削除して、AES だけを使用すると、機能します。
encryption - ライセンス ファイルの静的またはランダム IV
暗号化された形式でライセンスをユーザーに送信できる小さなプログラムを作成しました。
現時点で私が持っている
- AES キーを暗号化する RSA 秘密キー
- データを暗号化する単一の AES/CBC キー
- RSA 公開鍵
AES と公開キーの両方がデバイスにハード コードされています。
ライセンスが要求された場合、IV をどのように処理すればよいですか? デバイス上に静的なライセンスを作成するか、新しいライセンスを作成するたびに新しいライセンスを送信する必要がありますか?
key - 暗号化されたプレーンテキストデータからのAESキーの検出
プレーンテキストメッセージMとそれに相当する暗号化されたEがあり、256ビットのAESキーで暗号化されていることがわかっている場合、キーを計算する方法はありますか?Mが十分に長い場合、それを行う方法はありますか?
c# - CAPICOM TripleDES と System.Security.Cryptography TripleDES の違い
CAPICOM を使用できなくなったため、使用をやめようとしています (64 ビット Windows 7 マシン)。
TripleDES を使用するための既存のコードは次のようになります。
暗号化のために提供される唯一の情報は、secretKey です。そして、secretKey は約 10 バイトであることがわかります。.NET クラスを使用して同じ暗号化を行う方法はありますか。注: これは、引き続き CAPICOM を使用する Web サービスへの接続を確認するために使用されます。どんな助けやアイデアも大歓迎です。
c# - 大きなファイルにRijndael暗号化を使用する
私は、理想的にはRijndaelを使用して、nの長さのファイルを安全に暗号化/復号化する必要がある状況にありますが、間違いなく256ビット暗号化です。
私は以前に暗号化をいじってみましたが、文字列とバイト配列を暗号化/復号化して非常に満足しています。ただし、ファイルのサイズがわからないため(そして、問題のファイルが非常に大きくなる可能性が非常に高い(〜2.5gb))、それらをバイト配列にロードして、暗号化/復号化することはできません。以前と同じようにシングルバウンド。
そこで、Googleで少し読んだ後、答えはファイルをチャンクで暗号化および復号化することであることがわかったので、次のコードを作成しました。
それはすべて私には「よく見える」が、悲しいことに、見た目はだまされているように見える!
暗号化はエラーなしで機能しますが、復号化中に「cryptoStream.Close()」メソッドは次の例外をスローします。
System.Security.Cryptography.CryptographicExceptionは未処理でしたMessage="パディングは無効であり、削除できません。"
Source = "mscorlib" StackTrace:at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte [] inputBuffer、Int32 inputOffset、Int32 inputCount、Byte []&outputBuffer、Int32 outputOffset、PaddingMode paddingMode、Boolean fLast)at System.Security.Cryptography .RijndaelManagedTransform.TransformFinalBlock(Byte [] inputBuffer、Int32 inputOffset、Int32 inputCount)at System.Security.Cryptography.CryptoStream.FlushFinalBlock()at System.Security.Cryptography.CryptoStream.Dispose(Boolean disposed)at System.IO.Stream.Close ()
また、暗号化されていないファイルサイズが予想されるファイルサイズと一致していないようです(約8バイトから約60バイトの範囲)
以下のように、RijndaelManagedオブジェクトの作成行を変更して、パディングタイプを含めることにより、例外を「修正」しました。
しかし、ファイルサイズはまだ一致しておらず、予想通り、暗号化されていないばかりのファイルはバロニーです!
私は今、暗号化/復号化で自分の快適ゾーンの外にいることを認めます、そしてそれはおそらく新人の間違いです-しかし私はそれを見つけることができません!
これを解決するための助けをいただければ幸いです。