問題タブ [rdrand]
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.
c++ - アセンブラを使用して Intel のプロセッサから乱数を取得するにはどうすればよいですか?
プロセッサ (Intel Core i3) の Intel の乱数発生器から乱数を取得する必要があります。私はライブラリを使用したくありません。C++ でアセンブラ ペーストを使用したいのですが、どのレジスタと命令を使用すればよいかわかりません。
c# - c++ を呼び出すたびに c# で int の配列を構築するか、c++ で構築して c# に渡しますか?
C++ で関数を作成し、組み込み関数を介して新しい Intel RdRand デジタル乱数ジェネレーターを利用できるようにしました。
PInvoke を介して C# で使用できるようにラップしましたが、次のように正常に動作しています。
私の使用例では、複数の乱数を要求することがよくありますが、おそらく一度に (要求元ごとに) 数百のオーダーにすぎません。私の質問は、とにかく C++ を使用しているため、乱数の動的配列 (またはベクトル) を返すことができる別の関数をまとめることは理にかなっているでしょうか。つまり、C++ DLL を複数回呼び出すだけでパフォーマンスが大幅に向上しますか? ? これは、最大 200 の乱数を多くのクライアントに同時に送信する可能性のあるサーバー アプリケーション上で行われるため、パフォーマンスが懸念されます。
やる価値があるとすれば、どうすればいいのでしょうか? 私は次のように考えていましたが、ベクトルを C# に取り込む方法を見つけることは簡単にパフォーマンスの問題になる可能性がありますか?
最後に、Marshal.Copy は後者のアプローチよりも優れているでしょうか。
assembly - Ivy BridgeのRDRANDの消耗特性は何ですか?
インテルデジタル乱数ジェネレーター(DRNG)ソフトウェア実装ガイドを確認した後、RDRAND
が呼び出されたときにジェネレーターの内部状態がどうなるかについて、いくつか質問があります。残念ながら、答えはガイドに載っていないようです。
ガイドによると、DRNGの内部には、ドレイン用のランダムビットを提供する4つの128ビットバッファがあります
RDRAND
。RDRAND
それ自体は、デスティネーションレジスタの幅に応じて、16、32、または64ビットのランダムデータを提供します。より大きなデスティネーションレジスタを使用すると、それらの128ビットバッファがより早く空になりますか?たとえば、2ビットのランダム性のみが必要な場合、64ビットレジスタではなく16ビットレジスタを使用するという問題を解決する必要がありますか?それはDRNGのスループットに何か違いがありますか?必要以上にランダム性を消費することは避けたいと思います。
RDRAND
ガイドによると、実行後にキャリーフラグが設定されます。「利用不可」とはどういう意味ですか?
RDRAND
呼び出しによってこれらの128ビットバッファがすぐに使い果たされたために、ランダムデータを使用できなくなる可能性がありますか?または、使用不可とは、DRNGがヘルスチェックに失敗し、新しいデータを生成できないことを意味しますか?RDRAND
基本的に、が呼び出されたときにバッファが(一時的に)空であるという理由だけでCF=0が発生する可能性があるかどうかを理解しようとしています。
注:RDRANDのスループットとレイテンシーに関するこの質問への回答を確認しましたが、別の情報を探しています。
ありがとう!
c# - C# から Intel の新しい DRNG (RDRAND 命令) に接続する方法は?
C# アセンブリから Intel の Digital Random Number Generator (Ivy Bridge の RDRAND 命令) を使用しようとしています。私は cpp libs を見てきましたが、より「管理された」ソリューションがあることを望んでいました。何か案は?
security - Intel DRBG パラメータの読み取り
新しい Intel プロセッサには、RDRAND 命令で読み取ることができる乱数を生成する DRBG が含まれています。これには、準安定発振器のノイズに依存するハードウェア エントロピー ソースから生成された 256 ビットのシード S が含まれます。数値に到達するために使用されるアルゴリズムは事実上AES(K,V)
です。ここで、K は S の半分から派生した一時的なキーであり、V は S の残りの半分から派生した IV です。これは、それを監査した一部の人々によって、よりよく説明されています。
さまざまな理由から、このメカニズムのパフォーマンスをその場でプログラムによって監査したいと考えています。これには、次の 2 つのことを読み取ったり導出したりする能力が必要です。
- Sの値
- K または V のいずれかの値
これと RDRAND の出力を数回繰り返して使用すると、この決定を行うために必要なテスト データが得られます。
ただし、ソフトウェア開発者のマニュアルや他の場所のどこにも、これらのタスクのいずれかを達成するための文書化された方法を見つけることができません。
これを達成するために Linux カーネル モジュールを作成する意思があり、そのために RDMSR を使用するか、MEI などのオンダイ デバイスへの呼び出しを含む他の手段を使用する意思があると仮定すると、このデータを取得することは可能ですか?
assembly - FLAGS/EFLAGS は clobber リストの「CC」(条件制御) の一部ですか?
拡張アセンブラの「=qm」とはの続きです。
を使用するRDRAND
と、キャリー フラグ ( CF
) が設定 (または設定解除) されます。
FLAGS
およびEFLAGS
レジスターは、適切な情報をコンパイラーに伝えるための条件制御の一部と見なされますか? 上記は次のように記述します。
それとも、"cc"
スプリアスの使用ですか?
必要がなければ使用しても無害であることはわかっています。拡張 ASMから:
アセンブラー命令が条件コード・レジスターを変更できる場合は、破壊されたレジスターのリストに「cc」を追加してください。一部のマシンの GCC は、条件コードを特定のハードウェア レジスタとして表します。'cc' は、このレジスタに名前を付ける役割を果たします。他のマシンでは、条件コードの処理が異なり、'cc' を指定しても効果はありません。しかし、それはどんなマシンでも有効です。
偽の場合、どのアーキテクチャに適用されますか? (ARMとCPSR
レジスタを推測しますが、間違っている可能性があります)。
python - Python のハードウェア rng を使用する
intel ハードウェア prng (rdrand) を numpy プログラムで使用して乱数のバッファを埋めることができる既製のライブラリはありますか?
これに失敗すると、誰かが私が適応または使用できるいくつかのCコードの正しい方向に私を向けることができます(私はnumpyでCPythonとCythonを使用しているため、最低限のラッパーshdで十分です)。
私が望む乱数発生器は、[0,1) の間の一様乱数です。
random - Intel の RDRAND の正当な使用法はありますか?
今日、私は次のように考えました: まあ、NIST SP 800-90Aの RDRAND 実装に大きな疑いがあるとしても、それは依然として疑似乱数発生器 (PRNG) のハードウェア実装であり、機密性の低いアプリケーションには十分であるに違いありません。それで、メルセンヌ ツイスターの代わりに自分のゲームで使用することを考えました。
したがって、この命令を使用することでパフォーマンスが向上するかどうかを確認するために、次の 2 つのコードの時間を比較しました。
と
2つを実行すると、次のようになります。
したがって、Mersenne Twister は、私の CPU では RDRAND よりもはるかに高速です。まあ、私はがっかりしました、私のゲームから除外されました. しかし、RDRAND は暗号的に安全な PRNG (CSPRNG) であるため、舞台裏で多くのことを行います...他の CSPRNG と比較すると、より公正になります。そこで、Rabbitの実装 (RFC を C に単純に変換したもので、パフォーマンスのための巧妙なトリックはありません) を使用して、次のテストを作成しました。
そして驚いたことに、最初の 2 つの疑似乱数データの 2 倍を生成し、RDRAND よりも良い時間を得ることができました。
3 つすべてが、最適化を有効にしてコンパイルされました。
そのため、RDRAND が NSA バックドアをすべてのソフトウェア暗号化に埋め込むために作成されたという偏執狂が広まっています。また、RDRAND よりも高速なソフトウェア CSPRNG が少なくとも 1 つあり、最も広く使用されている適切な PRNG である Mersenne Twister は、RDRAND よりもはるかに高速です。最後に、 RDRAND のように、AES の 2 つのスクランブラー層の背後に隠れていないオープンソースの監査可能なソフトウェア エントロピー プール (/dev/random
や など) があります。/dev/urandom
では、質問: RDRAND を使用する必要がありますか? 合法的な使用法はありますか?それとも、使用を完全に停止する必要がありますか?