RSAってさあ、桁数が増えると、ほんとーに安全なの？

　つまりさ、RSA１０２４より、RSA２０４８のほうが、素因数分解しにくいので安全っていうじゃない？

　たしかに、カギにする素数をランダムに、一様につくっているなら、その通りだけど、

　常識的に考えて、桁数が多い素数ほど、（解読されにくいかもしれないけど）つくりにくいじゃない？

　ってことは、それを高速で作るってことは、なんらかの規則とかアルゴリズムに基づいて作っているか、素数のプールがあるってことじゃないの？
　じゃあ、その素数生成の規則、アルゴリズムがわかってしまった場合、そこから公開鍵と元となる素数を再現できないのかなあ？？

　さらに、素数のプールから２つ選んで作ってるとすると、桁数が多いほど、素数のプール中にある素数は（つくりにくくなるので）減るだろうから・・・

安全なのかなあ？

データとプロセスの一貫性の検証としてのCRUD図

　ちょっとおもいついたことなんで、メモメモ。

---

　システムを開発するには、まず、その目的から、ゴールを設定する。
　ゴールは成果物であり、出力となる。
　出力される帳票、画面などには、データがあるのがふつうで、それが出力データとなる。

　出力データから、プロセスを切りだし、入力データを割り出す方法としては、

　（１）出力データが、いつ生成、読み込み、変更、削除されるかを考える
　　　　→そのときがイベントになり、そのイベントにプロセスが対応してくる

　（２）出力データが生成される際、自動的に作り出すことができず、
　　　　　　　誰かが入力する必要があれば、それは入力データになる。
　　　　そのときのイベントは（１）でわかっているので、そこが入力画面になる

　（３）入力データ＋出力データ中、データを保存する必要があれば、
　　　　　それは保存項目となる→正規化→ER図→ファイル・DB(テーブル）

このとき、（１）で生成(C)、読み込み(R)、変更(U)、削除(D)のタイミングを表すのに、
データとプロセスを直行させて、そこにCRUDを入れていくのが、CRUD図。
　なので、データとプロセスの一貫性（データがあるということは、どこかで生成されているはずだが、その生成されているプロセスがあるかどうか）をCRUD図で、しめすことができる。

---

　一方、現実的には、すべての出力データを明確にすることはむずかしく（＝ゴールを明確化することは難しく）、玉虫色のゴールにして、システム開発を行う。
　この場合、プロセスをどんどん詳細にしていく。

この場合、逆に、
（１）そのプロセスで扱うデータをCRUDにまとめていくと、

（２）結果として、生成（C）されていて、削除（D）されてないデータを、
　　　出力出たとすることができる

（３）そこで、出力できるデータからゴールとなる、
　　　目的の成果物ができればいいんだけど・・

この場合でも、（１）の段階で、データとプロセスを直行させて、CRUD図を作成すれば、データとプロセスの一貫性ををCRUD図で、しめすことができる。

---

　ということで、データとプロセスの一貫性を示すには、CRUD図ってことになるけど、実はこの図、作成するのがめんどっちいので作成しない。
　このへんが、簡単に作成できるようになると、システム開発の精度は上がってくると思う。