新生鳩丸掲示板♯

>ていうか私【誰】が言ってたのは教科書が読まれていたとき(昭和12～21年)にどう発音していたのかという話なので

　それに対して、私が言っていたのは「やうだ」を「yauda」と発音するのが一概に「間違い」といえるのかという話なので。

　昭和初期の一般的な発音については特に異論ありません。

あと「ようだ」は歴史的仮名遣いだと「やうだ」ですが、そもそも昔【何時】は「めり」とか「なり」だったわけで、じゃあ「やうだ」と書いて「yauda」と発音していた時期ってあるの? という質問も謎に包まれたままです【謎】。

> 昭和21年ですからこの間違いなく

編集ミスで生き残りやがった「この」はとりあえず無視してください。必要に応じて謎マークアップも【謎】。

ていうか私【誰】が言ってたのは教科書が読まれていたとき(昭和12～21年)にどう発音していたのかという話なので

> 少なくとも奈良時代までは

とか言われてもちょっと【謎】。現代かなづかいが告示されたのが昭和21年ですからこの間違いなく現代【何時】と同じような発音をしていたと思うのですが【謎無】。

うるせーyuu!

まったく。応援よろしこ

谷口

>「クローズド = ソースが公開されていない」という意味かも(嘘ですごめんなさい)。

　しかし実際、仕様が公開されていないことをもって「クローズド」と言っているようなニュアンスもあるのですよね……。

「クローズド = ソースが公開されていない」という意味かも(嘘ですごめんなさい)。

>> なぜ ISO-2022-JP を特に「JIS」と呼ぶのかイマイチ理解出来ません。

>ISO-2022-JPがIANAに登録される以前から、ていうかインターネットが普及【謎】する以前から使われていたなごりです【謎無】。いわゆる機種依存文字のようなものですね【謎】。ニフティでTTYならなおさらです【謎】。

ていうか、俗に「JISコード」「JISエンコーディング」などと

よばれているものは、ISO-2022-JPに限らず、JIS X 0201やJIS X 0208を「7ビットで」エンコードしているものの総称のような

気のせいがします。

> なぜ ISO-2022-JP を特に「JIS」と呼ぶのかイマイチ理解出来ません。

ISO-2022-JPがIANAに登録される以前から、ていうかインターネットが普及【謎】する以前から使われていたなごりです【謎無】。いわゆる機種依存文字のようなものですね【謎】。ニフティでTTYならなおさらです【謎】。

> Shift_JIS も EUC-JP も JIS X 0201 や JIS X 0208 を参照しているわけですし、

昔のJIS X 0202では複数バイト文字集合はG0にしか指示できず、G0はGLにしか呼び出せないのでJIS X 0202の符号拡張方式の下では他に選択の余地がなかったためだと思われます。

> 要するに、プライオリティを考えて仕事して欲しいという話なのですけれども。

　論理的にはタスクでも、マシン語レベルでの実装は割り込み。

　ということは、割り込みコントローラーの上等のものをインストールしてあげなければならないような。

なるほどー。

パスワードを平文としたら鍵はどこから沸いて出てくるんだという話になりますねぇ。

う～ん。修行が足りませんね・・・。失礼しました～。

crypyでパスワードから作られる57ビットは、DESの暗号鍵です。この暗号鍵を用いて8バイトの0を暗号化することで、あたかもハッシュ関数のようにDESを使っているというわけです。

なのでまあ、DESの罠というよりDESを用いたcryptアルゴリズムの罠というのが正確かと。

>優先順位というのが発生することが多く、どちらでもない、とも言えるのでは？

　や、全くその通りですね。

　先に頼んだプライオリティの高い (と頼んだ方は考えている) 仕事が中断されて、後に頼んだ仕事が無条件に実行されたりするのはちょっと勘弁してほしい、という感じなのです。

　要するに、プライオリティを考えて仕事して欲しいという話なのですけれども。

>SQLインジェクションはエコーしなくても発生するのでだいたいあんしんです【謎】。

　御意。ってむしろぜんぜん安心できませんけれども。

　そうですね。

　DES の仕様自体は 64 bit ずつに切って全部符号化できるので、頭 8 文字しか見ないのは DES の問題と言うより crypt(3) の問題なのでしょうね。

>「早口の限界」があるのでしたら逆に「遅口(?)の限界」もあるのでしょうか?

あります。その場合は「これ以上遅くしゃべれません」と言います。スピードは最高から最低まで10段階で変更できます。

こんにちわ～。初めまして。はると申します。

よく来させてもらってます。＾＾

あんまり詳しくないのでもしかしたら間違ってるかもしれませんが、気になったので～。（間違ってたら言ってください）

これって、DESの罠というよりか、仕様の罠のような気がします。

DESはブロック暗号を行うので、確かに64ビットしか見ないのですが、それは3-DESも同じだったかと思います（私の記憶が正しければ3-DESは3つの鍵からそれぞれ巡回鍵を作って3回DESをまわすって感じだったかと～）。なので、DESとかだと8文字単位になるように後ろを埋めて8文字毎にパスワードを暗号化するんじゃないですかね？（推測）平分攻撃が大丈夫なのかはよくわかりませんが～。

あと、

>もう少し厳密に言うと、頭の 8文字からそれぞれ下位 7ビットを抽出した 56 ビットしか見ていません。

ですが、DESでは、64ビットはそのまま必要だった気がします。32ビット毎に左右の要素に分けて、48ビットに拡張して・・・云々、って感じじゃなかったでしたっけ？

56ビットなのは鍵の話だったと思います。（8ビット目がチェックサムなので）

DESは一方向ハッシュ関数ではないので復号できなくてはいかんから、平分を削ったりはしないはづ！＞＜

間違ってたらごめんさい。

>>文字種を増やしたらSQLインジェクションやXSSが発現するとか【謎】。

>　それはパスワードをエコーしちゃう時点でちょっと……。

SQLインジェクションはエコーしなくても発生するのでだいたいあんしんです【謎】。そもそもパスワードを数字4桁にしちゃうくらいですからエコーバックくらいは当たり前です【謎】。

優先順位があるなら割り込み処理に近いですね。

後回しにすると忘れ去ってしまうということはエッジトリガですか【謎】。

「早口の限界」があるのでしたら逆に「遅口(?)の限界」もあるのでしょうか?