アカウント名:
パスワード:
OpenBSD/LibReSSL は 互換性を維持して ports/packages と同時にリリースする戦略なのに対してGoogle/boringSSL は手元のソフトウェアで使えればいいから互換性無視なんですね。用途が違うから互換性を壊すタイミングが違うけど、OpenBSD も最終的には危険な API を obsolete にしていくつもりらしいので方向性は同じということでしょう。
それよりも Theo が our safetybelts と呼ぶ以下の関数について議論が深まり、POSIX かそれに準ずる標準環境になるということはあるのでしょうか。 arc4random strlcpy strlcat explicit_bzero reallocarray timingsafe_bcmp timingsafe_memcmpもう strl* については散々議論されてきましたが、他にもarc4random [blogspot.jp] やreallocarray [undeadly.org] のように一般人でも安全に書ける関数が標準で必要だと思いますが、どうでしょう。
timingsafe_* については OpenBSD の別の人が書いています [tedunangst.com]。
RC4なんかから派生したrandom number generatorがなぜ必要とされるのかがよく解らないいまどきは/dev/randomなどを生で使うのも推奨されなくなったんだろうか
/dev/randomはエントロピーが貯まるまでブロックするので大量の乱数を高速に生成する必要があるときには使えない。疑似乱数のシードにするのが一般的だから下手な使い方ができる。/dev/urandomについてはリンク先見ろよ。
/dev/urandomについてはリンク先見ろよ。
それ長いんだよね。
Attacking /dev/(u)random usage という部分の前半は
とかいう偏執狂っぽい話。でもユーザ権限で簡単確実に urandom を使う方法は存在しないというのはわかる。
後半、Linux にはエントロピーを確認できる ioctl(RNDGETENTCNT) があるけどread するまでの間の TOCTOU 対策はどうするの (だから OpenBSD ではその ioctl インターフェースを廃止した) とか、同時にエントロピーをクリアする ioctl インターフェース (RNDZAPENTCNT, RNDCLEARPOOL) もあるから信用できないとか。
とにかくそんなこと考えずにただポンと使える arc4random_buf みたいなのが欲しい。できれば POSIX で。という話らしい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
悪いAPIを消すタイミング (スコア:5, 興味深い)
OpenBSD/LibReSSL は 互換性を維持して ports/packages と同時にリリースする戦略なのに対して
Google/boringSSL は手元のソフトウェアで使えればいいから互換性無視なんですね。
用途が違うから互換性を壊すタイミングが違うけど、
OpenBSD も最終的には危険な API を obsolete にしていくつもりらしいので
方向性は同じということでしょう。
それよりも Theo が our safetybelts と呼ぶ以下の関数について議論が深まり、
POSIX かそれに準ずる標準環境になるということはあるのでしょうか。
arc4random strlcpy strlcat
explicit_bzero reallocarray
timingsafe_bcmp timingsafe_memcmp
もう strl* については散々議論されてきましたが、他にも
arc4random [blogspot.jp] や
reallocarray [undeadly.org] のように
一般人でも安全に書ける関数が標準で必要だと思いますが、どうでしょう。
timingsafe_* については OpenBSD の別の人が書いています [tedunangst.com]。
Re: (スコア:0)
RC4なんかから派生したrandom number generatorがなぜ必要とされるのかがよく解らない
いまどきは/dev/randomなどを生で使うのも推奨されなくなったんだろうか
Re: (スコア:0)
/dev/randomはエントロピーが貯まるまでブロックするので大量の乱数を高速に生成する必要があるときには使えない。疑似乱数のシードにするのが一般的だから下手な使い方ができる。/dev/urandomについてはリンク先見ろよ。
Re:悪いAPIを消すタイミング (スコア:3, 参考になる)
/dev/urandomについてはリンク先見ろよ。
それ長いんだよね。
Attacking /dev/(u)random usage という部分の前半は
とかいう偏執狂っぽい話。
でもユーザ権限で簡単確実に urandom を使う方法は存在しないというのはわかる。
後半、Linux にはエントロピーを確認できる ioctl(RNDGETENTCNT) があるけど
read するまでの間の TOCTOU 対策はどうするの (だから OpenBSD ではその ioctl インターフェースを廃止した) とか、
同時にエントロピーをクリアする ioctl インターフェース (RNDZAPENTCNT, RNDCLEARPOOL) もあるから信用できないとか。
とにかくそんなこと考えずにただポンと使える arc4random_buf みたいなのが欲しい。できれば POSIX で。
という話らしい。