自動ニュース作成G
[FT]中国研究者、量子コンピューターで「暗号解読」主張
https://www.nikkei.com/article/DGXZQOCB05B5N0V00C23A1000000/
2023-01-07 08:40:44
＞中国の研究者が現在の量子コンピューターを使って、最もよく使われているオンライン暗号化技術を破る方法を見つけたという驚くべき主張をした。これに対し、コンピューターセキュリティーの専門家たちは今週、どのように評価すべきかと苦悩している。暗号技術の脅威になるのは何年も先のことだと思われてきたからだ。
記事の全文を読むには登録（無料）が必要だけど、オリジナルのftの記事は英語だけど無料で読める。『Chinese researchers claim to find way to break encryption using quantum computers』
◇
そういえば俺の卒業研究は楕円曲線法による素因数分解プログラムだったわ。４０年くらい前にUBASICって多倍長整数演算が得意な処理系で書かれたプログラムをC言語に移植した。指導教官が作った多倍長整数演算パッケージを使って。
・ほんとにそんなのが開発出来てたら、中国政府が握って色々裏でするはずだから、これはデマ！
・#0 自分は仕事で多倍長演算のC用の関数をアセンブラで作ってRSAとか実装してたな。ただし固定長で。ビット数が決まってたのでサイズを可変にするより高速なはずだったのだけど、Mathematicaに負けてたのがくやしかった記憶。とかの話ができる人は少数派だと思うが
・#2なんとなくわかるわ（笑）。ちなみに俺が移植したC言語のプログラムも移植元のUBASICインタプリタ版の方がずっと高速で衝撃を受けてた（笑） Mathematicaは専門家がチューニングしてるだろうから早いのかなぁ。
・業界あるあるなんだろうか…。あの界隈、狭い割りに頭良すぎて会話できる相手が少ないからなのか、みんな仲良しなんだよな。SCISのナイトセッションの盛り上がりがすごかった思い出
・言語の実行速度差よりも、アルゴリズムの実行速度差が勝ってるてことかな
・楕円曲線法による素因数分解プログラムの話なら多倍長整数演算パッケージの最適化具合か、C言語処理系（lattice-Cだったかな？）が原因と考えてます。lattice-Cはコプロセッサ（8087）がある前提で浮動小数点演算ライブラリが作られてたんじゃないかと。コプロが無い環境だと非常に遅かったような。そして本来は多倍長整数演算には不要な筈の浮動小数演算を多用してたのかも。
・スカイネットは中国から生まれそう
・Lattice-C懐かしい。MS-CがOEMで使ってたやつ。多倍長演算はアセンブラで書いてたし、浮動小数点も(嫌いなので)無効化してたし、当時Cへのパラメータは基本レジスタ渡しでオーバーヘッドはさほど大きくなかったはず。単純計算でも試したのでアルゴリズムの影響も少ない範囲。なのに遅いってなんなん？ってなってた。あえてタイニーモデルで試したりもしてた (懐かしすぎる
・まあ自分が作った多倍長演算のアルゴリズムがダメだったんだろうけどね。演算は単純なので手最適化でもそう変わらんと思ってたけど、今から思うと自分の認識してなかった命令の組み合わせとかがあったのかも。お手本とかも無く全部自分で調べて考えて作ったってので、専門家には及ばなかったとかそんな気がしてる
・でも横にたぬきと眼鏡の絵が描いてあったのは見逃すんでしょ。
・みんな難しい仕事の話しててついていけない…俺は除算命令もFPUもない組み込みプロセッサ向けに対数の近似関数をアセンブラで自作したくらいしかない
・CPUも基本は加算しか無いし多倍長演算も組み合わせで作ってたので似たようなものだと思う。組み込み系は制約多いし独自の世界だしで尊敬するわ。自分はTIのTMS320系(ただのDSP)ちょっと触ったぐらいでしかお世話になってない(暗号系の次に動画コーデックの依頼が来た)
・#8 ああ、Lattice-CとMS-Cってなんか関連あったよね。OEMだったのか。
・#11 俺も80386の32bit命令用の32bit浮動小数点のsqrtやsin,cosを作ってたな。遊びだけど。386の整数命令を使った(IEEE754ではなく)MS形式浮動小数点の四則演算ルーチンがThe BASIC誌に載っててそれを打ち込んで数学事典に載ってた近似式を参考に超越関数をいくつか追加して使ってたわ。同クロックの80387の半分くらいの速度だったと思う。