天気のいい日には、ソフトウェアのレジストコードを作りたくなる……などという人はいない。レジストコードを作るというのは、割とアタマの痛い問題だ。
一種の「暗号」なので、短ければ解析される危険性が増すし、長すぎれば入力しづらくなる。
この中に入れたい情報はどのようなものになるだろうか？
製品種別、バージョン、有効期限といったものを入れておき、そうした情報を文字列と数列のマッピングをずらしつつ、いろいろとローケーションを変えてみるということになるだろう。
たとえば、01234567890という情報を入れたい場合、「0」という情報を「0」で表現せずに「9」で表現するといったようにデータをそのまま表現しない。さらに、文字位置についても「4628907351」といったように、そのままの位置に出さない。
あとは、「ノイズ」をどの程度どの位置に入れるかということになる。単なる文字列と見ると分かりにくいが、これを２次元的にとらえると……
■□□□□■□□
□□□□□□■□
□□□■□□□□
□□■□□□□■
□■□□□■□□
□□□□□■□□
□□■□□□□□
□□□■■□□□
■が情報、□がノイズであった場合、このように「まだら」に混入させることになるだろう。
２次元情報としてとらえることには意味はあるが、これを３次元まで上げてみても、結局は１次元の文字列に展開されるので（あまり）意味はない。
情報やノイズのほかに、検証用のチェックサムデータも入れておく必要がある。このチェックサムの算出方式が肝心な部分ということになる。
だいたい方針が決まったら、とりあえず生成用のプログラムを組んで、一定の数まで生成させてみる。必要か不必要かはさておき、10万レコード程度は生成させてみて、それをリバースエンジニアリングで破れるかどうかをひととおり試してみることになるだろう。
だいたい、どの程度のデータが集まると規則性を抽出できてしまうか、ということを考慮しながら、レジストコードの「強度」を計ることになる。
だが、レジストコード自体が「共有」あるいは「流失」されてしまった場合には困る。ある程度、ユーザーのモラルに訴えていくということにはなるが、いくつかの方策も必要にはなる。
とりあえず、LAN内で同一のコードが使われてしまうことは割けたい。そのために、何らかのテクノロジーを用いてクライアント間の通信を行い、同一のコードが用いられていれば起動を許可しないといったところになるだろう。
まあそんなわけで……RendezvousによってLAN内のマシン検出を行いたいところであり、特定のポートを指定して通信してみたいところでもある。特定のリクエストに応えるサーバー（ローカル起動）なども必要になるわけで、単にアプリケーションを作りたいだけなのに幅広い知識を必要とされたりするのであった。なんまんだぶ。