【堅牢】トリップの新方式を考えてみませんか【互換性】
■ このスレッドは過去ログ倉庫に格納されています
現段階でのトリップの問題点などを考えつつ、
現行方式よりも堅牢なトリップの方式を考えてみませんか。
マルチバイト文字問題や互換性などの問題も出てくると思いますが、
そこは皆で妙案を出し合いつつ、新たな方式を頑張って考えてみましょう。
関係スレ
幸せサーバープロジェクト 「アイデア・技術のある人募集中」★3
http://qb5.2ch.net/test/read.cgi/operate/1241361889/ >>152
明らかなネタに食いつく暇人そうとう暇なんですねww
ママのおっぱいでも吸ってろチンカス >>176
おっと見逃してた、確認どもです。
しかしとりっぱー廻してる人結構いるんですねぇ、私一回しか使った事ないやぁ トリ屋(検索人)は一人見かけると20人はいるという・・・ ゴキブリかよ!
ゴキブリの親玉>>ID:hXQntv5t0
つーか、コレのキーはタコっぽいというかウジというか。wwwwww
#銷カ16\蛆 訳解らんのだけどB64なので文字種が一つ減って12桁切り出しなので実質9桁IDって理解でおk? >>161
さんきゅー
ほぼバッチリだZE!!!!!!!
これで、DESトリップキー空間がほぼ 2^68 にひろがったぜ!
0x80 問題はスクリプト側じゃどうしようもないんだよな。
>>189
現行仕様が廃止されたりしようものなら暴動
じゃなかった俺のライフワークがひとつ減るしな!
つーか検索人はトリップネタに食いつくものだ。
テストスレなんて入れ食い入れ食い。
>>194
ひとつ減ってひとつ増えるんじゃ? 実験だから!実験だから!と言ってるうちに誰かが新方式向けのとりっぱーを
ビルドして配布してしまう流れですかね。
>>194
従来: [0-9A-Za-z./]
B64: [0-9A-Za-z+/] # 上で書かれてるとおりひとつ減ってひとつ増える
12桁だから実質9桁というくだりは salt のことなのかな。 >>198
た。♪
sub Make_Trip{
# 仕様変更? @2009/06/16
my $key = shift;
if ($key =~ m|^#([[:xdigit:]]{16})([./0-9A-Za-z]{0,2})$|) {
$key = "◆" . substr crypt(pack('H*', $1), "$2.."), -10;
}
elsif (length $key >= 12) {
$key = "◆" . substr sha1_base64($key), 0, 12;
}
else
{
# 従来形式
($key) = $key =~ /^#(.+)/;
my $salt = substr($key, , 1) . "H";
# $salt =~ s/[^.-z]/./g;
# $salt =~ tr/:;<=>?@[]^_`/ABCDEFGabcdef/;
$salt =~ tr|x3A-x40x5B-x60x00-x2Dx7B-xFF|A-Ga-f.|; # 仕様変更 @2003/11/15
$key = "◆" . substr crypt($key, $salt), -10;
}
return $key;
}
なしくずし万歳!
それ用ツールもこっそり配布開始。wwwwww SHA1かMD5キー+saltが指定できるってことは、一般人には割られにくく、かつ
ネタトリップは作りやすくなったってこと? >>199
perl知らないけどsha1_base64($key), 0, 12だとDigest値の
先頭9byteしか関係ないって事ですよね? >>207
use Digest::SHA1 qw/sha1_base64/;
my @test = qw/0123456789abcdef qwertyasdfgzxcvb 3.14159265358979/;
printf "%s: %s\n", $_, sha1_base64($_) for @test;
printf "%s: %s\n", $_, substr(sha1_base64($_), 0, 12) for @test;
0123456789abcdef: /lVn6NdpVQhSGCzfaddLsW3/jik ←切り出し前
qwertyasdfgzxcvb: ia8gywvMZqbL9R546lCaVDRns+Y
3.14159265358979: 9BMQ/whYEVl14iN0sGxOvjKhSy0
0123456789abcdef: /lVn6NdpVQhS ←12桁切り出し後
qwertyasdfgzxcvb: ia8gywvMZqbL
3.14159265358979: 9BMQ/whYEVl1
いちおう10〜12桁めの文字も意味のない子ではないんです。 Digest値の先頭9byteをBase64で12文字にしてるという話ではないかと
MD5で十分かも そうそう、sha1のDigest値の先頭9byteしか、って意味です
だからどうしたって訳ではないです^^ 今北。今までって確かHMAC_MD5(salt付きmd5)だったと思うけど、HMAC_SHA1とかHMAC_SHA512とかにするって議論になってるの?
それとも全く別のにするって話になってる? 今まではDESです
あと、sports2以外で0x80でちょん切らない鯖一覧みたいなの
どこかにありますかね? >>209-210
すみません、B64にして増えた分の話だと気づいてませんでした。
どうなんでしょ、その辺りは substr で切り出す分を増やす…と長くなるんですよね。
まだsha1に決まったわけではないはずなので(たぶん)
その辺りはいろいろ意見を出すと詳しい人が考えてくれるんだと思います。
>>211
まだいろいろ迷走してるところのようです。 >>212-213
何となく分かった。CSSスクランブルしてからHMAC_MD5とかどうよ。個人的にお勧め。 Base8192 でもつくって、ひらがなとか漢字とか(r 文字数増やしても大して意味ないから、如何に複雑にするかが大事。 昨日寝る前に書きかけてたやつ、書き上げてここに貼ってみても良いのかしら。 うーん、エロ小説ですかね。
>>216
現状は、酉屋さんにとってやる気が出るもの && 一般の人にとって従来より少しは割られにくいものが
模索されているようです。かなり複雑化してもロジック公開なら酉屋さんは挑みそうな気が。 >>219
隠した鍵でAES掛けてからMD5でもいいが、完璧過ぎてそれじゃつまらん。
ロジック公開してトリ割れ競争に挑ませて、つまらなくなってきたら別のアルゴリズムに変えるでいいじゃん。
HMAC-MD5
http://www.ipa.go.jp/security/rfc/RFC2202JA.html
CSS暗号
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/hannum-pal.html なんか難しくて付いていけないけど、今のトリキーが割られる原因の大半は
入力者が単純なトリキーを使っているからと上の方にあったけど。
それは解決出来るのか? PHPですみません
http://happy.70.kg/trip/trip.php
>>69で考えていたものを実際に書いてみました。
AESじゃないですけど、遺伝子暗号で文字列をコネコネしてます。 >>222の仕組み
文字列
↓
各文字をASCII文字コードへ変換
↓
そのコードを連結して1つの数字とみなす
↓
その数字を3で割って小数点以下切捨て
↓
その数字を2進数に変換
↓
それを頭から2桁ずつ区切りながら遺伝子暗号へ
# 各桁には0 or 1が入る
# ので、2桁なら 2^2 = 4 パタンが判断できる
# その4パタンを塩基一文字表記(A or T or G or C)に置きなおす
↓
遺伝子暗号を元に翻訳
# トリプレットで頭から読んでいく
# 4種の文字で3桁なので、4^3 = 64
# [0-1a-zA-Z] で 62文字なので、そこに [./]を追加して64文字
# 各トリプレットに上記1文字を対応させることで、新規文字列へ変換
↓
新規文字列を今回はcrypt (多分、MD5)で処理
# とりっぷ = crypt(入力した文字列, 新規文字列);
↓
表示
---
汚らしい酷いソースを見たいという奇特な人がいらっしゃれば、
いつでも公開させてもらいます。 というか、tripsrc.txtとかして一緒に置いといてくれればいいのに まだ書き込みのソースってperlなんだっけ?
もしそうなら俺がD言語で書き換えてやるぜ
時間かかるかもだけど >>224-225
>>222のスクリプトのとこに、リンク貼っときました
センスの無さは責めないでね >>222 のは強度とか諸々の点について,その筋の方から見てどんな感じですかね?
あと,その他諸々のアルゴリズムについては,対応する Perl モジュールが
入っているか,あるいは入れられるか,というのもあるかなと思います.
一応,Digest::HMAC_MD5 と Digest::HMAC_SHA1 は元々入っているようです. >>228
salt側を可変にするとトリップの衝突が増えるです、多分・・・ ロジックが分ってれば、後はPCの処理能力次第の気も・・・今でも総当たりなんだし。
数倍程度の処理の複雑さだと将来的にすぐ吸収してしまうような。
あと、この場合今のトリップは捨てるの? >>227
専ブラのプレビュー作るのメンドイから変態チックなのは止めて下さいです。。。 dsoの新方式のやつは今のと互換性があるし実際に入れてみては?
さしあたって何か問題あるですかね? しかるべき人にプレゼンするとか,モリタポ等トリップを利用する
他のところでも対応してもらうとか.あと,SHA1 使ってる部分も
これでいいのかというのももうちょっと確定させてからにしたいかなぁ,と. >>223
なにがしたいのかわからん。
2bitを3個セットで処理するなら、最初から6bitごとに切りゃいいじゃん。
しかも結局肝心な本当の意味の暗号化はcrypt()するだけとか。 じゃあ暗号化煮詰めながら、パケモンの代理人であるどうやら1号さんに
新方式導入していいかパケモンに聞いてもらえばいいのかな?
誰か連絡出来る人かもーん♪ >>228
その筋の方のように詳しくないですが、ここでの強度≒ブルートフォース耐性なので
演算がめんどくさいかどうかの問題ですよね。
で、入力文字列を64種の文字に変えるまで可逆的(剰余除く)にこねくりまわして
crypt()というのは、その筋の方がわくわくするロジックではないように感じます。
bbs.cgi にこれ(を高速化したもの)が入る図はあまり考えたくないし
専ブラやとりっぱーを作る人は一旦 /[ATGC]+/ にもせず6bitずつで文字割り振って
crypt()するんですよね。うーん。 キーを長くできる新仕様トリップについて意見を。
・公開? 非公開?
アルゴリズムが非公開、もしくは秘密鍵を用いるような様式だったら
検索人のおもちゃとはなりえない。つか現仕様を残してくれればそれで十分。
以下、公開(手元で実施可能)を前提に話す。
・キー構成文字
現トリップは、エンコードする直前のキーがエスケープ( < とか & とか)
されていたり、果てにはNGワード置換まで行われてしまっている。
このままだと、BBS.CGI の置換処理がトリップ仕様に含まれてしまうことになる。
これ、分離できない?
フォームからデコードした時点ですぐ、名前欄を、トリップキーとそれ以外に
分離すればいい。もしキーに何らかのサニタイズ処理を入れるにしても、
名前欄の置換処理とは独立して行った方がいい。
現仕様トリップにおいては、生キーが導入されればこの問題を迂回できるから
もうどうでもいい。(置換処理を変更してもいい)
文字コード(Shift_JISがでんでん)についても言及したいところだけど
これ言い始めるとドツボ確実なので俺放置。 >>235
(´-`).。oO(連絡できますけど、あなたもできるでしょ?とか) >>239
仕様です。
従来キーを生キーへ変換したいことってある????
そんなことする意味がわからなーい。 >>238
いやー、どうやらさんが知らない人だと見ないんじゃないんですかねぇとおもて >>239
◆2jQDVuA2hQ ##61616161DADADADAaa
◆K0Gxko5y0Q ##DADA616161616161.a
っすね。Salt部を省略したら【..】扱い。
生キーに変換する人は、自分で何をやっているのかわかってる前提。 >>237
>・キー構成文字
> (ry
>これ、分離できない?
なるほど,言われてみれば確かに......ということで,分離する処理も入れてみました.
ついでに,トリップの処理もちょっと変更.
if (length $handle_pass >= 12)
{
if (substr($handle_pass, 0, 1) eq '$')
{
# 将来の拡張用
$GB->{TRIPSTRING} = '???';
}
elsif ($handle_pass =~ m|^#([[:xdigit:]]{16})([./0-9A-Za-z]{0,2})$|)
{
$GB->{TRIPSTRING} = substr(crypt(pack('H*', $1), "$2.."), -10);
}
else
{
use Digest::SHA1 qw(sha1_base64);
$GB->{TRIPSTRING} = substr(sha1_base64($handle_pass), 0, 12);
}
}
else
{
# 従来形式
}
12桁以上かつ「#$〜」の指定は,将来的な拡張に使えるようにとっておこうかと. ◆cZfSunOs.U さんカコイイ!
ああ、長年の夢が叶っていく!!!!! どうやらさんにメールしまして,
>全サーバで適用されるなら、
>いいと思いますー。
というお返事を頂いたので,SHA1 使ってる部分あたりの仕様が固まってきたら
全鯖配布ということにしようかと.
# >さてさて、sports2をどうしたものかな、、、と。
#
# ということも付記されてましたが...... 話が早すぎてこわいw
さて、なんかテストで検索してみたいけどシロートはトリッパーが対応するまで
また〜りとしますか。 従来トリップの 0x80 問題に対応する方法が見つかりました。
◆iUAaAAAAAA ##8BAEAEE49A9F8082
これはFreeBSDライブラリCRYPT(3)特有の問題。
CPANインストールして回るのがちょっとアレですが、ご検討お願いします。
1. Crypt::UnixCrypt_XS をインストール。
2. スクリプトのどこかに use Crypt::UnixCrypt_XS qw/crypt/; を入れておく。
これで組み込み関数 crypt(key, salt) が所望の動作のものに置き換わる…ハズ。 >>246
そういえばIPv6板のbbs.cgiは特殊な気がするけど個別対応になるのかな。
トリップ部分は変わらないはずだけど。 >>249 これは root 権限のある方にお願いするということになるかと......
>>250 bbs.cgi 自体は ipv6 でも共通のものですね.
内部的に特別な処理をしてる部分があるということで. >>251
おつです。
今は2chとBeのプロフは完全互換ではないですが
これは完全互換に出来るのでしょうか?? >>251
IDがいやに長くなってたりするから無理なんじゃないかと思ってたんだけど
自動更新可能なのかすごいなぁ。 よーし、おじさんプロフの鳥生成を変えようとしてぶっ壊すに100狐ぽかけちゃうぞー >>254
やはり、、、
何をされるかわからないから、頼めないですねw
Beプロフでは出せないトリップがあって、これをきっかけに
仕様変更出来ないかと思ったのですが。。。 あの時は・・ひろゆきがやっちゃって、鳥屋が涙目だってな。 少なくとも2ch鯖でのトリップは全鯖共通にしてね。 >>244
なぁる♪
substr(sha1_base64($handle_pass), 0, 12);
先頭の#が付いたまま突っ込まれてるのかぁ♪
http://qb5.2ch.net/test/read.cgi/operate/1212767905/970 >>260
Boo2008ばぁぢょん。
sub Make_Trip{
# 仕様変更? @2009/06/16
my $key = shift;
($key) = $key =~ /^#(.+)/;
if (length $key >= 12){
if (substr($key, 0, 1) eq '$'){
# 将来の拡張用
$key = '???';
}
elsif ($key =~ m|^#([[:xdigit:]]{16})([./0-9A-Za-z]{0,2})$|){
$key = substr crypt(pack('H*', $1), "$2.."), -10;
}
else {
$key = substr sha1_base64($key), 0, 12;
}
}
else {
# 従来形式
my $salt = substr($key, , 1) . "H";
$salt =~ tr|x3A-x40x5B-x60x00-x2Dx7B-xFF|A-Ga-f.|; # 仕様変更 @2003/11/15
$key = substr crypt($key, $salt), -10;
}
return "◆$key";
}
>>261
ちょと修正。
sub Make_Trip{
# 仕様変更? @2009/06/17
my $key = shift;
my $salt;
($key) = $key =~ /^#(.+)/;
# 12文字以上ある時に新式採用
if (length $key >= 12){
if (index($key, '$', 0) == 0){
# 将来の拡張用
$key = '???';
}
# 塩付きkey
elsif (($key, $salt) = $key =~ m|^([[:xdigit:]]{16})([./0-9A-Za-z]{0,2})$|){
$key = substr crypt(pack('H*', $key), "$salt.."), -10;
}
# そのままkey
else {
$key = substr sha1_base64($key), 0, 12;
# $key =~ tr/+/./;
}
}
else {
# 従来形式
$salt = substr($key, , 1) . "H";
$salt =~ tr|x3A-x40x5B-x60x00-x2Dx7B-xFF|A-Ga-f.|; # 仕様変更 @2003/11/15
$key = substr crypt($key, $salt), -10;
}
return "◆$key";
}
もすかして、、、
$key = substr sha1_base64($key), 0, 12;
先頭からだと何入れても変化無し? >>244
キー構成文字の痴漢処理が従来形式にも適応されてるのは。。。 >>263
なんだか bbs.cgi のほうはこっそり # を削ってから
sha1_base64() するようになってるみたいです。
http://dso.2ch.net/test/read.cgi/myanmar/1245105121/16
# substr(sha1_base64('また挑戦。@2ch掲示板'),0,12) → ZDzVO3Ph6oZ3
# substr(sha1_base64('#また挑戦。@2ch掲示板'),0,12) → p6iSjgdOqVeb 「痴漢処理が適応」って変か
分離する処理が従来形式にも適応されてトリップ変わっちゃうのはどうなのかな >>266
それってまずいですよね
今までの資産がいくらか電子のもずくになっちゃいます
置換処理を除外するのは新方式で、
現行方式の場合は生キーを使えるようにするって話じゃなかったかしらん? >>234
AESがインスコできなかったので
>6bitで区切れば(ry
本当は間にもう1つ入れる心算だったんですが、
何をする心算だったのかのメモをなくしたのであのままです。
>>236
>crypt()というのは、その筋の方がわくわくするロジックでは
私も自分で書いてて、そこで萎えました
---
まあ、私のは多分採用されないので(ry >>265 bbs.cgi 内部では $handle_pass というのは # を抜いたものになってます.
>>266-267 そのあたりを突き詰めると,結構難しいんですよね.
< や > の置換処理なんかはまず不変でしょうけど,例えば
$GB->{FORM}->{'FROM'} =~ s/山崎渉/fusianasan/g;
これは山崎渉事件以降追加された処理だと思いますが,
これによって完全な一貫性はすでに失われていますし,
そしてこのような NG ワードの追加は今後も起こりうることなので...... 「#山崎渉」は「#fusianasan」になってしまうのがデフォなのですか。 >>269
しかし今更だけど、コードを見ると笑えるなぁw どうにでもなるんじゃないかな?
($GB->{FORM}->{TRIP}, $GB->{FORM}->{FROM}) = $GB->{FORM}->{'FROM'} =~ /^(.+)#(#?.+)$/;
初っぱなにこうしておけば。。。
・・・って甘いのかしら? あと、、、
$key = substr sha1_base64($key), 0, 12;
$key =~ tr/+/./; ←これしちゃうのはいくないのかな? 新たなコードではトリップ部分の置換処理をスルーしていますが,
それによって(置換処理が行われていた)従来のものと一貫性が失われる
ということを >>266-267 では指摘しているのではないかと.
>>274 入れてみますか...... 過去の糞コードが足を引っ張る典型だな
作り直したい衝動に駆られるけど許されないという・・・
実際そんな仕事ばっかりやってるけどw < が &lt; に置き換わることなどを知ってれば
利用者側で対処可能です。
逆に、そこまでして残さないといけない仕様ですか?
今こそキレイにしておく箇所じゃないかと私は考えます。
2ちゃんねる文字化け対策
http://www.geocities.jp/trip_chaser/2ch_mojibake.html
2chトリップ仕様(私の書きかけ)
http://sourceforge.jp/projects/naniya/wiki/2chtrip
このへんは検索人が苦労してきた部分でもあるため、こだわりがあるんですよ… >>275
ふむふむ。逆のことかぁ。。。
それは大変ですねぇ。わははー
でも良いと思うです。10周年ですし(´ー`) tr/+/./ 入れますた.@Boo2008
トリップテスト広場になっている、、、Boo2008 書き忘れ。
置換に関する仕様変更については、
現トリップにおいては、生キー指定が実装されてれば
致命的な問題はなくなります。
しかし、
・現仕様の置換処理を残しつつ
・さらに置換文字列を追加する
ようなケースが発生しうることを鑑みると、
2chが死滅するまで禍根を残す問題となり得ます。 >>268
ついうっかりPerlにしてみました。
ttp://senji.xrea.jp/naotrip_pl.txt >>223通りに動くかどうかもわからないエンバグしてそうなもの
ttp://senji.xrea.jp/float_php.txt FreeBSD(64)とWin(32)で違うトリップが生成されて悲しくなったので
>>269
コード読み返せば # を抜いてあることぐらい気づきそうなものを、と自分で感じているところです。 なにもレスがないということは sha1_base64 でファイナルアンサー?
決定しだいトリッパーを対応させ(r ■ このスレッドは過去ログ倉庫に格納されています