In article <470B853C.9050608 / sarion.co.jp>,
  "NAKAMURA, Hiroshi" <nakahiro / sarion.co.jp> writes:

> Randomクラスでは、Random#randになっていたものですね。こちらの命名は移行
> のし易さ優先で提案したものでした。
>
> rand()からSecureRandomへの移行を必要以上に促す必要はないですから、randと
> いう名称にこだわりはありません。移行を促す必要がない、という観点からする
> と、いっそのことrandom_numberも不要なのでは。

必要がある程度には促す必要があるので、不要とは思いません。

> OpenSSL::Random.random_bytesも、それほど考えられて作られたメソッドじゃな
> さそうですから、由来というほどのことはないと思います（ちなみにOpenSSLの
> 関数名はRAND_bytes()）。最初に実装したミカロコとしても、田中さんの指摘同
> 様、「bytesじゃ簡単すぎるかな」と思ったのかもしれません。

「ミカロコ」ってなんですか?

> ただ、個人的には、hex、base64があまりピンとこないので（後述）、
> SecureRandom.bytesという短い名称にして、こちらこそ推奨にしたいところで
> す。SecureRandom.random_bytes(256/8)とか、長くて悲しい。

バイナリの文字列を生成するのってそんなに使いますかねぇ?
あまり使われないと予想しているのですが。

>> binary_string, string は別名としてありうると思います。
>
> （ここで1.9のことを考えてもしょーがないですが）stringという名称は混乱を
> 招きそうな。

1.9 とどう関係するのでしょう?

バージョンはいずれあがっていくわけですから、懸念があれば教え
てください。

> 私としては、以下の理由から、hexとbase64にはあまりピンときてません。
>
> 1. hexやbase64がエンコードフォーマットであり、
>    「暗号学的に強度のある乱数」というクラスの本質との結び付きが弱い。

session id という用法において強い結び付きがあります。

使いやすいライブラリをデザインするには想定される用法を十分に
支援することが重要です。

> 2. 従来の乱数APIで、そのようなものを見たことがない。
>    知ってるのはJava、.NET、python、PKCS#11くらいですけど。
>
> ま、2はあまり重要視すべきことではないですし、「どうせ多くの人は、hexか
> base64するんだから」というのはわかるんですけど。欲しい人が要るのに反対は
> しませんが、推奨というのはなぁ。

なんで random_bytes を推奨したいんですか?
推奨すると hex や base64 よりも便利になりますか?
-- 
[田中 哲][たなか あきら][Tanaka Akira]