| ホームへ戻る｜Data Base 桐 User Board｜過去ログ一覧｜検索｜プロパティ ｜ほっ！ |
| ▼過去ログ No137 |
| 書き込み数 : 6850件 |
|
|
|
||||||||||||
|
> 以前は行の途中ではコピーした行数だけ > 上書きペーストされていたような・・・ 桐ver8 sp7 でも、#6849 で うにんさんが書かれたとおりの 動作でした。 複数行選択しているときにペーストするとコピーした行数を 最大として上書きされる。１行だけだと１行だけ上書き。 |
|
|
|
||||||||||||
|
行セレクタで行を選択すると、その選択されている分だけに上書きペースト 項目をクリックすると、その位置に挿入ペースト 終端行だと行セレクタでも項目クリックのような表示になり（先頭項目だけ反転）追加ペースト みたいです（基本状態で）。 |
|
|
|
||||||||||||
|
確かに私の記憶では 以前は行の途中ではコピーした行数だけ 上書きペーストされていたような・・・ それでペーストは必ず終端で実行するように 癖をつけていました。 今回確認したらこうなっているということです。 |
|
|
|
||||||||||||
|
>それは、1行目だけ選択されていた状態だからじゃないでしょうか。 >並べ替え状態には影響するみたい。 両方とも私の環境では 行の途中では >コピーした1行目のみ上書きされます。 終端行では コピーした行数分ペーストされます。 桐V9-2004 です 何で違うんだろう。 |
|
|
|
||||||||||||
|
なるほど、フォームも絞り込みも関係なくて索引状態だと貼り付けできないんですね。 絞込みだと行複写ができないのはHELPの「表の編集状態」のとこに書いてありますが。。。 |
|
|
|
||||||||||||
|
> テキストってのはタブ区切りじゃだめなのね。。。 HTML のテーブルからのコピペでも、この区切り文字が ブラウザによって異なり、コピペの可否が異なりました ね！ http://www2u.biglobe.ne.jp/~s_tanaka/bbs/kiri/srch.cgi?no=0&word=firefox&andor=and&logs=.%2Fcbbs.dat&PAGE=20 |
|
|
|
||||||||||||
|
> できる表とできない表がある。 並べ替え状態には影響するみたい。 解除すれば可能になる。 |
|
|
|
||||||||||||
|
Google の地図(サテライト)もすごいですが、 Yahoo!地図情報 - スクロール地図（ベータ版） って、航空写真については Google より上の ようです！ http://map.yahoo.co.jp/beta/index.html?m=aero 私の地域だと Google より Yahoo の方が圧倒的 に細かいです！ ただ、ベータ版だけにたまに遅くなったりするよう ですが・・・ |
|
|
|
||||||||||||
|
>コピーした1行目のみ上書きされます。 それは、1行目だけ選択されていた状態だからじゃないでしょうか。 「形式を選択して〜」のヘルプには「あらかじめ行選択してからこのメニューを選ぶと、選択範囲の行の値だけを置き換えます。」と書いてあるのですが。 フォームから切り換えたかどうかだけではなかったみたいです。できる表とできない表がある。謎。。。フォームの種類が関係あるのかな？グループがどうとか。 絞込みとは関係ありませんが、桐で行をコピーした場合、「形式を選択して貼り付け」が 有効になってますが、実際には「KD1029:データを変換できません」で貼り付けられません。 テキストとCSVから選択しますが,テキストってのはタブ区切りじゃだめなのね。。。 |
|
|
|
||||||||||||
|
私のインターネットの利用は、普通(暇なとき)は、Yahoo!にしています。 結構ここで暇つぶしができ、本当に便利に利用させていただいてます。が、 検索をするときは、殆どGoogleが多いです ところで、先日地図を探してみました。もちろんYahoo!にも、地図はありますが Google地図 http://maps.google.co.jp/maps これはいいと感じました。操作性や拡大・縮小等いいですね 画面の大きさも判断してくれるようです 他にも、ライブドア等「出発地・目的地」等を登録し、ルート検索などが できるものまでありますね。 http://map.livedoor.com/ 便利になりましたね そしてGoogleには http://news.google.co.jp/nwshp などもあるのですね。しらなかったなー！！ |
|
|
|
||||||||||||
|
ちなみにこれは行複写･行退避など桐のコマンドとは 無関係です。 アイコンにある通常のwindowsにある ctrl+c と ctrl+v と同義のふるまいです。 念のため |
|
|
|
||||||||||||
|
確認したら勘違いでした。 >コピーした行数分上書きされます。 コピーした1行目のみ上書きされます。 と訂正します。 不思議！！！ |
|
|
|
||||||||||||
|
ただ、この場合気をつけることは 行の途中でペーストすると挿入されずに コピーした行数分上書きされます。 必ず終端行で実行してください。 |
|
|
|
||||||||||||
|
>フォームから表編集に切り替えるとできない？ 行セレクターをクリックして、 １行まるまるのコピーだけが有効なのでは？ この場合でしたらＣＴＲＬキーを押しながら 選ぶとランダムな行でもコピー→ペーストできます。 |
|
|
|
||||||||||||
|
あれ〜？ コピーは確かにできるのですが、貼り付けできない場合（メニューがグレー）があります。 フォームから表編集に切り替えるとできない？ |
|
|
|
||||||||||||
|
プログラムで行の複製をしようとして、複製したい行で 「行退避」して、空の行を行追加し、その行に「行復旧」 しても(あるいは行待避した同じ行に行復旧しても)、 数値項目の#未定義な値が「0」になってしまうのは非常 に悲しい！ そのままでは「行復旧」にはなりゃしない。 |
|
|
|
||||||||||||
|
表(*.tbl)で、絞り込み中は「／メニュー」の「C:行複写」は利用できませんが 上段メニューの「編集(E)」では「コピー・貼り付け」が、可能です ちなみに、フォームには行複写メニュー自体がないのですね |
|
|
|
||||||||||||
|
桐って絞り込み状態で行複写ができませんね。行挿入しても行追加になってしまうのに できるんだから、複写先が自動的に終端になっていいから行複写もできればいいのに。 |
|
|
|
||||||||||||
|
> 鍵方式 そして PKI にまでなったら、単に鍵を使うとかだけでは無く、 その鍵の出所のところまで証明が必要になると・・・ |
|
|
|
||||||||||||
|
> PGP PGP って、公開鍵方式を採用した主にメール用の１つのアプリケーションに すぎませんよね(ちょっと語弊もある ^^;)。同じような公開鍵方式を用いた アプリケーションには SSL や SSH もあるわけですが、多くの場合は RSA 方式の公開鍵方式を使う場合が多いですよね。 もちろん、他の暗号化アルゴリズムやバリエーションもあるし、選べる場合 もあるのですが・・・ |
|
|
|
||||||||||||
|
パスワード長くして分割して保存しても、パスフレーズ使って別に保存しても 全てのパスワード持っていかれたら一貫の終わり。当たり前か^_^; hidetake さん、 PGPって例えば2048bitでも、パスワード(秘密鍵)が妙に長いですね？ 通常はハッシュかませてもそんなに変わらないですよね、つーか余り長くならないように効率よくハッシュする。 これって、 順番をカウントするのが不可能な素数の生成を使っているから、素数以外の冗長部分を 膨大に含んでいて長くなっちゃってるんですかね？ それとも故意に冗長を混入させて長くしているとか(^^) PGPは弄ったこともなくて解らん^_^; PGPでは2048bitとかいうのもアルゴリズムの暗号化キー長を呼んでいるのかも解らん。 |
|
|
|
||||||||||||
|
> 公開鍵方式の「秘密鍵」の最後の砦はパス > フレーズだけれど、その暗号化はどうする > のとか、どうなっているのとか、攻撃法は > とかはあるでしょう！・・・ もっと大げさに言えば、この秘密鍵から暗号化された 本当の解読鍵を取り出す部分が、ファイルを盗まれ 手元にファイルを持った「パスワード方式」のセキュ リティ強度も似たようなものでは無いかという・・・ |
|
|
|
||||||||||||
|
> その前に、鍵方式は「鍵」を盗まれたら > 終わりです。 公開鍵方式の場合は「秘密鍵」ね！ 公開鍵方式の「秘密鍵」の最後の砦はパス フレーズだけれど、その暗号化はどうする のとか、どうなっているのとか、攻撃法は とかはあるでしょう！・・・ |
|
|
|
||||||||||||
|
> 結局、パスワード(秘密鍵)のbit長＋パスフレーズのbit長 のパスワードになりますが、 > 始めから両者を足したbit長のパスワードよりも、暗号強度は弱くなります。 > 自明ですが、大昔にどこかで読んだ^_^; 何の bit長を気にされている事か？ ファイルの bit長ですか？ その前に、鍵方式は「鍵」を盗まれたら 終わりです。これはパスワード方式に 対しては弱点ですよ。 パスワード方式にも、鍵方式にもそれ ぞれのメリットとデメリットはありますよ。 |
|
|
|
||||||||||||
|
> 別に私が勝手に作った造語では無く、普通に使われている > 用語だと思いますが！？ 別にパスフレーズがどうのこうのでは無く 鍵をどこにおくかの問題です。 鍵という特別なものを用意しないと普通には 復号できないという意味でもあると思いますが、 それがパスワードによって生成されたり、 ファイルの中に含まれるようなものとは異に すると思います。 |
|
|
|
||||||||||||
|
その場合 結局、パスワード(秘密鍵)のbit長＋パスフレーズのbit長 のパスワードになりますが、 始めから両者を足したbit長のパスワードよりも、暗号強度は弱くなります。 自明ですが、大昔にどこかで読んだ^_^; |
|
|
|
||||||||||||
|
> hidetake さんが鍵方式って表現しているのは、 別に私が勝手に作った造語では無く、普通に使われている 用語だと思いますが！？ > 通常一定のハッシュ作業でパスワードを変換するのですが、 > パスフレーズをパラメーターにしたハッシュ作業ですから、 > 変換したパスワード(秘密鍵)とパスフレーズの両方保存が必要になりますね。 普通は秘密鍵(実際にファイル化され保存する)に一体化されて います。 パスワードと鍵を同等扱い(その長さやユニーク性からも)する のもよくわからん。 パスワード方式でも、実際の暗号化や復号に使う鍵は、何も パスワードと同一のものって言う事もなく、一番最初の段階で 何らかの鍵を作るのか、その都度、パスワードを元に生成する ものはわからんけれども、暗号化のための鍵と、単にパス ワードとして投げかける部分の違いをハッキリさせないと混乱 しそう？ |
|
|
|
||||||||||||
|
氷解した気がします。 【hidetake さんが鍵方式って表現しているのは、 パスワード(秘密鍵)をさらに暗号化してそのパスワードも使うとういうPGPの機能 パスフレーズのことですか？ で、その機能がないものをパスワード方式って表現している。】 当初よりの議論の辻褄が合います。 PGPはパスワード(秘密鍵)をユーザーが指定できないので、さらに暗号化してパスフレーズ を指定すると一見便利になりますね。 通常一定のハッシュ作業でパスワードを変換するのですが、 パスフレーズをパラメーターにしたハッシュ作業ですから、 変換したパスワード(秘密鍵)とパスフレーズの両方保存が必要になりますね。 |
|
|
|
||||||||||||
|
> 「メディア鍵版」 > ・認証をパスワードにより行うパスワード認証方式が「パスワード版」 > メディア鍵版の方が、 パスワード版のように偶然にパスワードが合致してしまう > 場合はありません メディアを作るところの信頼性が問題になりそうな... 車のキーが偶然一致したという事件がありましたよね。（これは元々bit長が短すぎる ＝車の数に対して作れるキーの種類が少な過ぎる ような話だったと思いますが） |
|
|
|
||||||||||||
|
> 非対象鍵方式(公開鍵・秘密鍵)はパスワードを２つ用います。 > 片方で暗号化したら、複合化には別のパスワードを用います。 なんか言葉の表現でも誤解を生みそう・・・ > hidetake さんが使っているのはPGPですか？ PGP もあれば SSL もあれば SSH もありますよ。 もちろん、その中ではどの暗号化アルゴリズムを 使うかの選択肢もあるわけですが・・・ > 一般の人でも使いやすく工夫されていて、パスフレーズという概念も利用します。 だから、この部分と暗号鍵には全くの関連性はありません。 自動生成された鍵を、そのうちの秘密鍵を盗まれても 直ぐに使えないように暗号化してあり、実際に使う段階で 復号するために「パスフレーズ」は用いられます。 そして、実際に復号に利用される鍵は、「パスフレーズ」 で復号された鍵です。 |
|
|
|
||||||||||||
|
対称鍵方式は同一のパスワードで暗号化・複合化します。 非対象鍵方式(公開鍵・秘密鍵)はパスワードを２つ用います。 片方で暗号化したら、複合化には別のパスワードを用います。 以上にハッシュをかませているものも、いないものもあります。 市販されている暗号プログラムは、さらに色々な工夫を加えてあります。 hidetake さんが使っているのはPGPですか？ PGPは詳しくないのですが、ご存知のようにアルゴリズム上、ランダムな素数を用います。 一般の人でも使いやすく工夫されていて、パスフレーズという概念も利用します。 |
|
|
|
||||||||||||
|
> 対称鍵方式でも非対象鍵方式(公開鍵・秘密鍵)でも、 > 暗号化鍵ってパスワードと同義なんです。 > しっかりしたアルゴリズム使うときは鍵とキーボード入力可能文字が一致しないので > ハッシュかます事が多いですが、bit長は通常同程度になります。 全然理解できないし聞いた事もない話の世界のようです。 # 鍵方式の場合、鍵作るところって人間の入力とは全く関係ない # いかにランダムな値を生成するかにかかっているのでは？ # そう言ういかにランダムな値を生成するかに、いろいろな # 手法のキーワードを入れ、人が最終的にキーボードから入力 # するパスフレーズは、公開鍵方式の場合は、暗号化された # 秘密キーを復号するためだけに使われると。 # パスワードの場合、人間が管理できる範囲いないの事だから # 実際的な強度は全く異なってくると思います。 |
|
|
|
||||||||||||
|
うーーん、 対称鍵方式でも非対象鍵方式(公開鍵・秘密鍵)でも、 暗号化鍵ってパスワードと同義なんです。 しっかりしたアルゴリズム使うときは鍵とキーボード入力可能文字が一致しないので ハッシュかます事が多いですが、bit長は通常同程度になります。 物理キーだと複製が極端に困難になるのでより安全なんです。 私は大事なデータを数年前まで、当時一般に入手可能な世界最強暗号RARで暗号化していました。 最新版RARでは公開アルゴリズムのAESに変更になって強度が落ちた^_^; |
|
|
|
||||||||||||
|
> パスワードよりも物理キー(メディア・USBキー)の方が強固なのは > 当たり前な訳で、、 鍵方式というのは、基本的にその対称と同じ場所に鍵を おくわけは無いので、どこかにおくわけでしょう。 サーバとクライアントだったり、ノートパソコンの盗難 のような事を考えた場合は、その鍵をリムーバブル メディア等に入れて、パソコンとは必ず他の場所におく とか・・・ > 鍵長 公開鍵方式だと、かけるための鍵と解くための鍵を 分割して保存するわけだから、単純に同一の鍵と鍵長を 比較するわけに行かないでしょう。 それと同時にアルゴリズム抜きで bit長だけで強度を 語れるわけでも無いと思いますが？ 対称鍵方式、公開鍵方式はそれぞれの利点・欠点ある わけで、それを考慮しつつセキュリティを保つためには どうしたら良いのか、自分の用途や利便性等で選択する では？ > hidetake さんお勧めの非対象鍵方式 誰でも、公開鍵方式をお勧めとは指定な訳で、よりセキュアな 鍵方式(など)では無く、結局はパスワード方式なんだねって、 書いたのでしょう。 > kthree の Webサイトの情報を見てみるかぎり、結局はパスワード方式であり > よりセキュアな鍵方式などでは無いのですよね・・・ 暗号化アルゴリズムとプロトコル http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/crypto.html http://search.luky.org/linux-users.9/msg02186.html 以下のスレッドとか・・・ |
|
|
|
||||||||||||
|
パスワードよりも物理キー(メディア・USBキー)の方が強固なのは 当たり前な訳で、、 以前に、対称鍵方式でも、hidetake さんお勧めの非対象鍵方式(公開鍵・秘密鍵)でも、 brute force method のパスワードの解析は同様と書きましたが、 (大抵はハッシュをかましてあるが) >また、公開鍵アルゴリズムの代表的な RAS方式などの場合、一般的な対称鍵方式 >(共通鍵方式)と同等なセキュリティを保つには、1024bit鍵が 80bitの対称鍵と >おおよそ同等だと言う事です。 と言うことは、対称鍵方式の方がかえって強固じゃん、これ如何に。 どういう計算で評価するんでしょう？ 公開鍵が解析手段に情報を与えるのでしょうかね？ |
|
|
|
||||||||||||
|
http://www.kthree.co.jp/new_top/kiri9-2006_secure.html 「利用者コードとセキュリティキーはどう違うの？」の項目は 削除されてしまいました。 見損じた方は Google のキャッシュからご覧下さい。 :-) # 桐9-2006 へのアップグレードは(2004/2005ユーザ)は SP対応で # 「無料」との事。あ〜一安心！ |
|
|
|
||||||||||||
|
> パスワード方式と鍵方式 たとえば、NEC のセキュリティソフト「InfoCage/モバイル防御」の資料には http://www.sw.nec.co.jp/cced/infocage/images/promo/mobairu_goshoukai.zip > 強度よりも簡便さを優先させる場合にはパスワードによる保護も可能強度よりも > 簡便さを優先させる場合にはパスワードによる保護も可能（注１） >（注1）パスワード方式の場合インシデント発生時に鍵強度が脆弱とみなされる > 可能性があります と記述されています。 で、FAQ を見ると http://www.sw.nec.co.jp/cced/MobileProtect/faq1.html > Q.「メディア鍵版」と「パスワード版」の違いはなんですか？ >「パスワード方式の場合インシデント発生時に鍵強度が 脆弱とみなされる可能性 > があります」と資料にありますが、具体的にどのように脆弱になるのですか？ > 基本的には、ＵＳＢ鍵と同様の鍵強度が必要と考えます。 > A.認証方式に違いがあります。 > ・認証をリムーバブルメディアを鍵として使用するメディア鍵認証方式が > 「メディア鍵版」 > ・認証をパスワードにより行うパスワード認証方式が「パスワード版」 > メディア鍵版の方が、 パスワード版のように偶然にパスワードが合致してしまう > 場合はありませんので、インシデント発生時に鍵強度が強固です。 と、書いてあります。 なお、InfoCage は暗号化アルゴリズムに米国政府標準暗号(AES)、鍵長に 128bit を採用しているそうです。(鍵版・パスワード版とも) また、公開鍵アルゴリズムの代表的な RAS方式などの場合、一般的な対称鍵方式 (共通鍵方式)と同等なセキュリティを保つには、1024bit鍵が 80bitの対称鍵と おおよそ同等だと言う事です。 InfoCage は対称鍵方式の AES 128bit ですので、もし公開鍵方式で対称鍵方式の 128bit 以上の強度を望むならば、せめて 2048bit の鍵長を用いないと強度的には 落ちる事になるようです。 |
|
|
|
||||||||||||
|
> Windows 版が出来たときにもう少し見直せば(作り直せば)良かったのにと、 更に書いておくと、Windows版では .CMD .KEV 等のコマンドを 記述したファイルのセキュリティ度は、更に一歩下がっています。 下記に書いてありますが http://www2u.biglobe.ne.jp/~s_tanaka/cgi-bin/bbs/bbs.cgi?function=logview_html&no=16#786 http://www2u.biglobe.ne.jp/~s_tanaka/cgi-bin/bbs/bbs.cgi?function=logview_html&no=26#1257 http://www2u.biglobe.ne.jp/~s_tanaka/cgi-bin/bbs/bbs.cgi?function=logview_html&no=67#3347 「定義利用者コード」の設定が Windows版で省略されました。 だから hogehoge すると、Windows版「桐」の中で利用者コード を解除する事も可能でした。 こんな事でよいのか？と、要望は出していましたが、その事に ついては、桐ver9 で改善され、DOS桐版と同等になったぐらい です。 こんな経緯もあって、私は「桐9-2006」には非常に興味がある のです。「桐9-2006」と言うだけで無く「セキュア桐」と命名 をするぐらいだから、すごいものなのだろうなぁ〜！って・・・ |
|
|
|
||||||||||||
|
> でも、利用者コードってハッシュされずにTBLに書き込まれていたのですか。 > 子供騙しのようなセキュリティを使わされていた事に愕然^_^; ただ、もう少し説明しておくと、利用者コードは再定義のところで 既に設定しているパスワードを再表示してくれるようになっています。 それと、利用者コードは単純なパスワードと違って ? や * を含む 事のできる高度な条件設定が可能なようになっています。 従って、パスワードのような単純なハッシュでは難しい面も持ってい ます。「桐」の最初の開発当時ならともかく(パソコンの性能やセキュ リティ重要度等の考慮からも)、Windows 版が出来たときにもう少し 見直せば(作り直せば)良かったのにと、何遍書いた事か・・・ |
|
|
|
||||||||||||
|
> 桐9-2006は、起動した直後はセキュア化されたファイルは扱えません。 > 一度桐9-2006として起動したのち、桐9-2006をセキュア桐に「モードを > 切り替える」必要があります。 > つまり、桐9-2006をセキュア桐に変えることができる人だけが、セキュア > 化されたデータを扱うことができるよう制限しています。 > 会社でも重要機密を扱っている部屋は施錠されており、「ドアのカギを > 開けることができる人だけが入れる」ようにしていると思います。 > 桐9-2006とセキュア桐の関係も、それと同じようなものです。 やっぱ、桐自体にセキュリティキーも？かけて、「モード切り替える」 段階で安全性を１段あげているのですかね？ それでも、パソコン内にパスワード(ハッシュ値)は持つのでしょうが？・・・ データの可搬性の問題で、あるいは、複数でのパソコンでの使用や 複数のセキュリティ化された個別のセキュリティキーを持つデータの 取り扱いを考えて、テーブル内に普通にパスワード処理していると、 最初は考えたのですが！・・・ やっぱ製品を見てみないとよくわからないや！？ (^^; > でも、利用者コードってハッシュされずにTBLに書き込まれていたのですか。 > 子供騙しのようなセキュリティを使わされていた事に愕然^_^; VBScript 程度でも復号できます。って言うか作ってあります。 :-) しかし、その前にファイルを解析すればわかりますが、パスワード リセット(無い状態にする)すれば、何もパスワードなど解析したり 復号しなくても済むのです。これも VBScript 程度でも作れます。 :-p # 折角！外部に一括処理の中身は見せずに実行だけできるような仕組み # を設けているのに、何の工夫もせずに一発で中身を取り出せるような # コマンドさえも「桐」は実装しているのですよね！？ だから・・・ :-( |
|
|
|
||||||||||||
|
いま戻りました。 まあ、桐の機能向上を喜んで製品が出るのを待ちましょうよ(^^) でも、利用者コードってハッシュされずにTBLに書き込まれていたのですか。 子供騙しのようなセキュリティを使わされていた事に愕然^_^; |
|
|
|
||||||||||||
|
> 論点がズレ始めてきていますが、 元々ズレていると私は感じていました。 > 殆ど解析されないようになった、つー事でしょう。 本当にそうであったら良いし、パソコンを落としたけれど 「セキュア桐」って言うのに桐のデータが漏洩しなれば良い です。 # でも、私はそのための条件が気になるし重要だと・・・ |
|
|
|
||||||||||||
|
うーーん、論点がズレ始めてきていますが、 要するに brute force (これなら一緒だし、実質的に不可能だし)じゃなく 殆ど解析されないようになった、つー事でしょう。 |
|
|
|
||||||||||||
|
> 少なくともデータファイル内に暗号化キーを持たないとは書いてありますね。(^^) 今までは復号できる利用者コードをテーブル内に持っているけれど 今回のは、セキュリティキーそのもの(復号できる形での)は持たない。 でも、ハッシュ化された復号できない形の結果は持っているのだろう と私は読みましたが・・・ いずれにせよ、「誕生日」や「電話番号」等やキーとなる文字列が わかったり、間違って一致すると開く事が可能という事で、外部に (たとえば桐のシステムに)キーを登録していそうでは無いのでは？ > 利用者コードと大きく異なるのは、「セキュリティキーデータそのものは、 > TBLファイルの中にはない」という点にあります。 そのものが重要では？ |
|
|
|
||||||||||||
|
言葉の綾とか揚げ足取り合戦になりそうなので、余り書きませんが >データを開く際に、まずはパスワードが一致するか調べ、それ >が一致したら、そのパスワードかハッシュ値か、はたまたそれ >をキーワードに作成したか鍵かわかりませんが、その鍵を元に >データ部分を復号するのですよね。 その方式だとセキュリティ強度は落ちるので、 セキュア桐では、どうなんでしょうか？ 少なくともデータファイル内に暗号化キーを持たないとは書いてありますね。(^^) >だから、最終的にはセキュリティ強度はパスワード長になる >のでは無いのですか？ 利用者コードもAccessも暗号化アルゴリズムが弱いから(正確には暗号化ですらないかも) 簡単に解析されちゃうのよ。 <6793> の RSA56bit って brute force で当たりが出たのですか？ アルゴリズムが解析されたって言う意味ではないですか？ |
|
|
|
||||||||||||
|
>> 桐について知らない人が、 >詳しくない人にとってはドッチモ無理でしょ(^^) 暗号化には詳しくても桐の過去の経緯など知れない人だって いるのでは？ だから、最終的にはセキュリティ強度はパスワード長になる のでは無いのですか？ > アルゴリズムが解らなければ、桐を介して、 桐のデータを正常な形で取り出すには、暗号化以前に桐自体 のデータ構造まで解析した人って、現在はいるのかな？ あと、暗号化・暗号化ってコルネさんは言っておられるけど パスワード(ハッシュした結果)の部分？ それともデータの 部分でしょうか？ パスワード(ハッシュ)の隠し方にはいろいろあるでしょうが・・・ データを開く際に、まずはパスワードが一致するか調べ、それ が一致したら、そのパスワードかハッシュ値か、はたまたそれ をキーワードに作成したか鍵かわかりませんが、その鍵を元に データ部分を復号するのですよね。 (公開)鍵方式も、パスフレーズは秘密鍵を復号するためだけに 使われるわけですが、秘密鍵を盗まれてしまっては、いくら パスフレーズがあっても、それは気休めにしかならないという のと一緒で、パスワード方式もファイルの現物がそこにあった ら、何の気休めにもならないのでは無いですか？ |
|
|
|
||||||||||||
|
> 桐について知らない人が、 詳しくない人にとってはドッチモ無理でしょ(^^) 悪意のある色々と詳しい人が、ファイルを入手した場合に、 ファイルが(チャント)暗号化されていれば覗けませんよね 暗号化されていなければ、Access と同様なのですが ><6780> ># >「利用者コードを解析され、解除してしまう」可能性がある ># なんて書いてあるけど、今までの利用者コードなんて解析する必要も無く ># 解除(無かったものに)する事さえも可能でしたよん！ 勿論、brute force したら、鍵長に依存しますね。 アルゴリズムが解らなければ、桐を介して、 パスを入力して、桐の反応を受信解釈して、次のパスを入力して、ってなりますね。 |
|
|
|
||||||||||||
|
> 従来の桐の利用者コードとかAccessのデーターベースパスワードとかの > 単に開けなくするパスワードから、 > 暗号化キーを使用してファイル自体を暗号化するようになった。 > 天と地の差です。 今までの「利用者コード」の8桁と、新しい桐のセキュリティキー を8桁のままで使った場合で、桐について知らない人が、普通に 辞書攻撃や総当たり攻撃で突破しようとしたときに、今までの 桐と新しい桐でセキュリティ強度的にはどう違うのですか？ > ファイル属性⇒暗号化 に毛が生えた程度かも^_^; この辺は実際に見てみないと何も言えないので、私は言及して いないのですが、それらをかけるための仕組みはパスワード 方式だという事で、そこの部分のセキュリティについては 気になっていますし、パスワード方式という事で、結局は パスワードの強度によって、暗号化の仕組みなんて関係ない ぐらいぶっ飛んでしまいそうです。 72文字もの長さのパスワード(パスフレーズ)を、現実的に 使いこなせれば良いのですが？・・・ orz # パスワード(パスフレーズ)方式で 128bit の鍵と同等の # 強度を保つためには 11word 程度のパスフレーズも必要 # だと意見もあるようですが、どう言う計算でそうなるか # わかりませんが、長いなぁ〜 |
|
|
|
||||||||||||
|
実物が発売される前にあれこれ言うのは楽しいですね。 発売された後は、なんだ、こんなもんか、とか セキュア桐ファイルの暗号化自体は高度なアルゴリズムではなく、 桐従来の、ファイル属性⇒暗号化 に毛が生えた程度かも^_^; 一応、ハッシュ操作を暗号化キーに依存するようにしたっていうだけって気もする。 データベースファイルを暗号化するとページング処理他が極度に遅くなり、 使い物にならないとういう古くて新しい問題がある。 PDAのパスワード管理プログラム程度なら 2048bit Blowish とかはザラにあるが、 巨大なデータを扱う桐で果たしてファイル自体の高度な暗号化が可能か？ そして、セキュア桐モードに変える操作時には暗号化キーを単なるパスワード として使用しているだけとか。 全ては発売迄のお楽しみ。 |
|
|
|
||||||||||||
|
> Access のデータベースパスワードは開けなくするだけで > ファイルの暗号化をしていないのです。2Bite書き換えれば開けちゃいます。 Access のセキュリティなんて詳しくもないし、それほど細かく 調べた事も無いのですが、中身は暗号化されていないのは読んだ 事があります。 しかし、2byte の書き換えで解除できるのですか！ (@_@; なんかセキュリティを強化する目的で、パスワードを入れて 設定としてはバスワードが存在しないような書き換えを行い どんなツールでも解除できないなんて、ツールやサービスを 出しているところもあったように思いますが、そうなんだぁ〜 って、読んだ事はあるけど実際はどうなのでしょうね？ あとは、桐の「セキュリティキー」の保存方法(ハッシュやその 管理方法)や強度さえしっかりしておけば良いわけですね！？ |
|
|
Copyright (C) 2000 CGI Arkadia All rights reserved. Script written by Shintaro Wakayama. BBS-TypeN Ver.2 Preview4 remodel advice by hidetake |