 Re: 愚痴に二発突っ込め的な ( No.69 ) |
- 日時： 2003/07/12 23:37
- 名前： というか
- >バイナリデータより信頼性が落ちるわけではありません。
良くて同等程度ではないのかと。んで同等程度ならするだけ無駄ですね、と。
|
| Re: No.69 ( No.70 ) |
- 日時： 2003/07/13 08:53
- 名前： りん <ryne@nifty.com>
- 欲しいのは
1. ユーザに改変されない
2. プライバシーの侵害をしていないことをユーザーに証明できる
データフォーマットです。
1だけならバイナリで十分です。2だけならテキストが良いです。
両方を満たすならテキストに署名を付けるのが適当でしょう。
|
| Re: 愚痴に二発突っ込め的な ( No.71 ) |
- 日時： 2003/07/14 04:06
- 名前： というか
- >両方を満たすならテキストに署名を付けるのが適当でしょう。
が目的であれば秘密鍵を配布する愚なんて犯さず、普通に公開鍵で電子署名すれば良いだけ
ですね。
>気になる人は検証してくれと公開鍵を出しておけば変な憶測もされないだろうし。
という言い回しがあまりに妙で引っかかったもので。
|
| Re: 愚痴に二発突っ込め的な ( No.72 ) |
- 日時： 2003/07/15 00:27
- 名前： りん <ryne@nifty.com>
- > が目的であれば秘密鍵を配布する愚なんて犯さず、普通に公開鍵で電子署名すれば良いだけ
> ですね。
公開鍵で署名? データはプログラムで作られるわけで、これに署名するには
プログラムに秘密鍵を埋め込んでないとできませんけど。
重要なのは、署名が真に署名であって暗号化されたプライバシー情報でない
ことをユーザーが検証できることです。
ユーザーは公開鍵を使って、署名が真に署名であることを確認できる。でも
秘密鍵が分からない限り改変したデータの署名を偽造することはできない。
そういうこと。
|
| Re: 愚痴に二発突っ込め的な ( No.73 ) |
- 日時： 2003/07/16 00:40
- 名前： というか
- とりあえず結論から先に;
署名というのは事後的な情報の改竄を防ぐためのものであって、事前的な情報が真であると
いう前提の元に成り立つものです。事前的な情報の信用性が疑われるなら署名は無力ですし
無意味です。事前的な情報の提供者、この場合はユーザを全面的に信用するという前提が必
要です。
>秘密鍵が分からない限り改変したデータの署名を偽造することはできない。
署名するルーチンに割り込んで、偽のハッシュを渡すというクラッキングの可能性があ
ります。「ユーザに改変されない」を満たせるとは限りません。
企業がユーザを「全面的に信用」し、ユーザが企業を疑うのなら秘密鍵を埋め込んで署名
というのは良いのかもしれません。しかしユーザを「全面的に信用」するのであれば最初
からプレーンテキストでやれば済むことではないでしょうか。
無駄な手間を掛けるメリットがありません。
>重要なのは、署名が真に署名であって暗号化されたプライバシー情報でない
>ことをユーザーが検証できることです。
企業はユーザを疑い、ユーザは署名を疑っているという想定下では何も成り立ちません。
ですから、お互いに信用性に余地を残せる公開鍵による署名が痛み分けって感じで
どうかなと。PGPのようにユーザ自身の手で署名するようにすれば少なくともユーザは
安心できますけども。
>これに署名するにはプログラムに秘密鍵を埋め込んでないとできませんけど。
一般的な意味での署名と呼べるかはともかく、公開鍵でも署名は可能ですが。
署名とは平たく言えばハッシュの暗号化とその検証なわけですから。
|
| Re: 愚痴に二発突っ込め的な ( No.74 ) |
- 日時： 2003/07/16 01:40
- 名前： りん <ryne@nifty.com>
- > 署名というのは事後的な情報の改竄を防ぐためのものであって、事前的な情報が真であると
> いう前提の元に成り立つものです。事前的な情報の信用性が疑われるなら署名は無力ですし
> 無意味です。事前的な情報の提供者、この場合はユーザを全面的に信用するという前提が必
> 要です。
事前的な情報の提供者はプログラムです。プログラムが収集した情報がユーザーにより
改ざんされていないか確認するために署名するわけです。
まあ、そもそもユーザーが信用できないからプログラムに情報収集させるんですけどね。
# 悪意が無くとも人間は間違えるんで、それ(信用できない)は間違っていないけど
# データのバイナリ化も改変を嫌ってでなく単なる圧縮かもしれないわな。不用意だが
> 署名するルーチンに割り込んで、偽のハッシュを渡すというクラッキングの可能性があ
> ります。「ユーザに改変されない」を満たせるとは限りません。
それはプログラムを解析して改造できる技術があればね。ただ解析困難なプログラムの
作成技術もありますし、十分な信頼性は確保できると思いますよ。
# 解析困難化技術はAlphaROMのチェックルーチンでも使われているらしい!?
> 一般的な意味での署名と呼べるかはともかく、公開鍵でも署名は可能ですが。
> 署名とは平たく言えばハッシュの暗号化とその検証なわけですから。
No.69の要件を満たすものが作れるなら公開鍵でも構わないんですけど……でも誰でも
作れる署名じゃ無意味でしょ?
|
| Alpha-ROMとASPIのバージョン ( No.75 ) |
- 日時： 2003/08/03 14:24
- 名前： chord
- はじめまして。
少し前にAlpha-ROMが特定のASPIのバージョンで誤爆するという話が有りましたが、
ASPIは特定のバージョンにおいて、デフォルトではATAPIドライブが見えないと言う
問題が有る用です。レジストリを修正すれば見えるようになるそうですが。
参考として、CD2WAVのもろぼしらむさんのFAQに次のようなのがありました。
http://homepage2.nifty.com/~maid/cd2wavfaq.html
CD2WAV FAQ集
｢Ｑ２−１４．Windows95のASPIを最新版にしたらATAPIドライブが見えなくなってしまいました(;_;) どうすれば直るのでしょうか？ ｣
これが原因の場合、ASPIがらみでAlphaで誤爆する環境においては、CDDAリッパーや
DVDプレイヤー等、ASPI経由でドライブを制御するソフト全てにおいてATAPIドライブが
見えないと言う問題が生じていると思われます。
この場合、ASPIがデフォルトでATAPIドライブを無視している(仕様を変えている)のが
そもそもの問題なので、Alpha-ROMに全ての責任を負わせるのは酷かなと思います。
なお、私の環境では、次の条件下では誤爆は発生しませんでした。
OS: Windows98SE
Drive: TOSHIBA SD-M1712
ASPI: Adaptec 4.71 (レジストリ修正済み)
サンプル: こころナビ
|
| Re: 愚痴に二発突っ込め的な ( No.76 ) |
- 日時： 2003/08/03 22:54
- 名前： 凧 <tako@sky.biglobe.ne.jp>
- ご指摘ありがとうございます ＞ chord さん
取敢えず、愚痴の方でお返事させて頂きました(^^;)。
|
| メディアチェック ( No.77 ) |
- 日時： 2003/08/09 22:15
- 名前： 合歓
- 私も鬱陶しく思ってる口なんで
ユーザー登録はがきのアンケートには
「メディアチェックが煩わしい」とか「ディスクレスプレイが出来て快適」と
書くようにしてます
ちっちゃくても意見を表明することが大事だと思うんで
|
| プロテクト ( No.78 ) |
- 日時： 2003/08/09 22:30
- 名前： 水野 たかひろ <t-mizuno@pp.iij4u.or.jp>
- 参照： http://to-ho-huhai.homeip.net
- 購入の時点で採用してないとこに対しては利便性を下げるなどの理由で今後も導入
しないよう意見。
既に導入してるとこには起動ごとのチェックは不便と書いて送ること多々。
我慢できるのはインストール時のみ、おおまけにまけて初回起動時かな。
|
このスレッドはロックされています。記事の閲覧のみとなります。
愚痴に二発突っ込め的な