アカウント名:
パスワード:
PentiumIIIのプロセッサシリアルナンバーを思い出しますね
Cryptographic Randomness from Air Turbulence in Disk Drives, [std.com] Don Davis, Ross Ihaka and Philip Fenstermacher
あの～～そんな本物の乱数を使って暗号化したら、 使い道が限られてしまいますよ？
公開鍵暗号系であっても、メッセージ本体は古典的な暗号系で秘密鍵で暗号化しておいて、その秘密鍵を公開鍵暗号でencodeしていっしょに送るというのが普通ではありませんか。
そしてそのとき使われる秘密鍵は1回限りの使い捨てで、「真の乱数列」から生成されますよね。擬似乱数だと、一回前の秘密鍵から次の鍵を推測される怖れがありますから。
なお、100bit/分であっても、それをタネにしてより長い乱数列を得ることができるので(ただしあまり延ばすと危険)、実用上は十分のようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
組込み (スコア:1)
なってるようだけど、これもその一環かな。
この手の回路をCPUが持つのって組込みの方から
見るとどの程度、便利なんでしょうか。
なんか別個にその手のチップが乗っかってるの
しかみたことないんですけど。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:組込み (スコア:2, 参考になる)
>見るとどの程度、便利なんでしょうか。
同じ機能でチップが減れば、部品調達、コストダウンに有利。
配線引かなくて済むから手間も省けるし、設計ミスもしにくい。
チップにセキュリティというと、PentiumIIIの
プロセッサシリアルナンバーを思い出しますね、個人的には…。
生にシリアルナンバーを出さなければ、
それはそれでセキュリティ確保に使えるかなと思ってみたり。
アーキテクチャの柔軟性(Re:組込み) (スコア:2, 興味深い)
-----
[Transmeta、Centrino対策はCrusoeへのセキュリティ技術組み込み!?]
http://pcweb.mycom.co.jp/news/2003/01/15/50.html
-----
上記の記事で私が気になったのは「アーキテクチャの柔軟性」です。これってやっぱり Intel の Microcode のようなものを仕込んで、CPU 自体の機能 up でもする気なのかな、と。ただあの会社のことですから、この手の仕様は一般に公開しないだろうから、一般の開発者は、手軽にこれらの機能を使えないのではないかと危惧しています。
＃どうせなら算術で求めない良質な RGN (Random Number Generator) を CPU 自体に組み込んで欲しい、に一票。
Mc.N
Re:アーキテクチャの柔軟性(Re:組込み) (スコア:2, 参考になる)
> Microcode のようなものを仕込んで、CPU 自体の機能 up でもする気なのかな、と。
> ただあの会社のことですから、この手の仕様は一般に公開しないだろうから、一般の開発者は、
> 手軽にこれらの機能を使えないのではないかと危惧しています。
x86 系の石は、Intel の AMD も内部は RISC アーキです。
x86 命令列を RISC コアの解釈する命令(μOP とか RISC86)に変換している。
ただ、この変換ルーチンはハードウェア化されており変更不能。
Crusoe のコアは VLIW アーキテクチャです。
x86 命令列を VLIW コアが解釈できるものに変換している。
この部分が Code Morphing Software(CMS)。
これが変更可能になっている点が、前者と異なる柔軟性です。
CMS の仕様などは一般の開発者には提供しないでしょう。
CMS は、相応な技術(プロセッサ・コンパイラ)を持っている人
でも気軽に使えるようなものではないと思われます。
> ＃どうせなら算術で求めない良質な RGN (Random Number Generator) を CPU 自体に組み込んで欲しい、に一票。
御存知だと思うのですが、
インテルは 810E チップセット以来に半導体素子の熱雑音を利用した
再現性のない物理乱数発生器をすでに組み込んでいます。
でも、この機能を実現するには熱雑音で駆動する特殊な回路が必要に
なります。プロセッサ側にそういうハードがないと、CMS や Microcode
のようなソフトウェアの変更で対応するのは無理ですよ。
コンタミは発見の母
Re:アーキテクチャの柔軟性(Re:組込み) (スコア:0)
http://www.dj.st44.arena.ne.jp/xwin2/mainhtml/xwinii/startm200007b.html
それも部分的には出来ると考えてよいのかも?
第一の目的はErrataの修正らしいですが...
Reconfigurablity の差 (スコア:1)
パフォーマンス向上させるような機能変更を
microcode patching で実現する余地はない
でしょう。
ただ、マイクロコードで機能を修正・追加するという
考え方は汎用機の世界では一般的です。
マイクロコードを使って OS の機能の一部をプロセッサ
側で実現しているものもあります。
機種によっては無停止にマイクロコードを変更できる
ものもあります。
コンタミは発見の母
Re:アーキテクチャの柔軟性(Re:組込み) (スコア:0)
ホント、欲しいですよねえ、これ。
ちなみに、確か1、2年前に非常に高精度の乱数を発生出来る回路が開発されたように記憶していますが、
その価格は確か数千万円だったような…
Re:真の乱数 (スコア:2, 興味深い)
Re:真の乱数 (スコア:1)
計算機が稼動してる時間じゅう、裏でずっとbit生成をやり続け、
得た値を順次キャッシュしていったら、遅さはなんとかカバーできませんかね？
#キャッシュの置き場はもちろんハードディスク、ということで…
Re:真の乱数 (スコア:0)
>
>計算機が稼動してる時間じゅう、裏でずっとbit生成をやり続け、
>得た値を順次キャッシュしていったら、遅さはなんとかカバーできませんかね？
>
>#キャッシュの置き場はもちろんハードディスク、ということで…
するとお約束でHDDが乱数だらけ・・・と。
乱数マニアには堪りませんな。
Re:真の乱数 (スコア:1)
使い道が限られてしまいますよ？
これは共通キー暗号の素朴な形なので、あまり使われていません。
（政府の最高レベルの暗号に使われる程度）
何故使われないかというと、共通キーなのでキーの配布(送付)を
安全な別ルートで行う必要があるためです。
# 技術計算とかで使うなら話は別です。
# それをチップに組み込むか？は別の話ですが。
notice : I ignore an anonymous contribution.
Re:真の乱数 (スコア:1)
公開鍵暗号系であっても、メッセージ本体は古典的な暗号系で秘密鍵で暗号化しておいて、その秘密鍵を公開鍵暗号でencodeしていっしょに送るというのが普通ではありませんか。
そしてそのとき使われる秘密鍵は1回限りの使い捨てで、「真の乱数列」から生成されますよね。擬似乱数だと、一回前の秘密鍵から次の鍵を推測される怖れがありますから。
なお、100bit/分であっても、それをタネにしてより長い乱数列を得ることができるので(ただしあまり延ばすと危険)、実用上は十分のようです。
Re:真の乱数 (スコア:1)
普通は、この部分に疑似乱数を使用します。
で、その種となる「短い数列」を公開暗号で処理して送ります。
生の鍵を送らない理由は、
１．生の鍵を暗号化して送るくらいなら最初から全文を公開鍵で暗号化した方が楽。（乱数を使う意味がないでしょ？）
２．公開鍵暗号は計算量が結構多いため、長文を暗号化すると時間を食う。
３．非常に簡単な乗積合同法でも実用に耐える疑似乱数が得られます。
（ビット数256とか512で乱数生成した場合）
# PGPの実装を参照してください。
notice : I ignore an anonymous contribution.
Re:真の乱数 (スコア:0)
/dev/randomからあんまし取りすぎると、乱数が払底するから気を付けろ、という話もきいたことがあるけど。
Re:アーキテクチャの柔軟性(Re:組込み) (スコア:1)
東芝のランダムマスター [toshiba.co.jp]のことかな？