FireGPG は UTF-8 にしか対応してないっぽい
コンテキストメニューから FireGPG 選んで、「わーい署名できたー。」ぐらいしか試してなかったので気づいていませんでした。
試してみたところ、文字エンコーディングが ISO-2022-JP では文字化けするようです。(たぶん、Shift_JIS と EUC-JP もダメだと思うけど) 文字コードを UTF-8 に変えて Thunderbird with Enigmail で送ってみたところ、見事に表示されました。
FireGPG がバージョンアップして、日本語が文字化けしないように
前*1試したときは、日本語が化けてしまっていましたが、
Bugs :
- The problem with encoding is solved ! (You can sign Japanese for sample now !)
FireGPG - Welcome to the official website of FireGPG!
ということで、修正されてました。
Gmail との統合機能も強力なので、是非お試しを。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 test テスト© -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iFcDBQFGZ+D+3J4zq/D1/c4RCLnGAPwLYwqYK1+0vjnk56XQCSB8W/Uw+O5Wdvx9 n8Kp9wM/1AD/SqFSRwQdFKB6+qyiqX9Bs/k7i5MmMT64ogRppuhW6As= =Ii3/ -----END PGP SIGNATURE-----
*1:[http://d.hatena.ne.jp/f99aq/20070415/1176635092:title]
FireGPG - Firefox 用 GPG フロントエンド
FireGPG - Welcome to the official website of FireGPG!
Firefox から GPG を便利に使う拡張らしい。日本語は文字化けしてしまった。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 test entry for FireGPG. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFGIgXf7ud9FToS3gERAn/fAJoD+QTdVhXInw0IwINm3rjFjyOmNgCgh+pz F9j0uWbIG/m2sxMgLmmwf0M= =0sFD -----END PGP SIGNATURE-----
FeliCa の security
(さらに追記)
薄っぺらいのは、俺の知識のほうですね。ということで、以下本文を読むよりリンク先をご覧になってください。
[鏡] しっぽのさきっちょ 2006年08月 -- Spiegel's Trunk
(追記)
[鏡] しっぽのさきっちょ 2006年08月 -- Spiegel's Trunk
やはり、問題は鍵管理ですかね。しかし、あんな薄っぺらいカードに、受信機(カードリーダー)側の鍵が正当か判断させるのは難しい気がする。(下の方の CRL とかの話に続く)
結局、電波を受信されないように漏電波防止用の何かでくるむとか、FeliCa 搭載携帯だったらロックする(できるんだよね?持ってないから知らないけど)とかで対策するしかないんじゃないでしょうか。財布だって落としたら終わりですよね。問題は非接触なところだけ(多分)なんだから。
(ここまで追記)
ケータイクレジットに致命的な弱点:FACTA online
本当に? ということで、少し調べてみた。
国内では、JICSAP ICカード仕様V2.0 「第4部 高速処理用ICカード」、サイバネティクス協議会でのICカード規定として規格化されている。 暗号処理としては、相互認証にトリプルDES、通信路にDESを利用している。公開鍵系の処理を行う規格はない。Dualカードタイプのもの(接触/非接触)があるが、公開鍵系の処理は接触型のみである。
相互認証時に、縮退鍵という、利用するサービスに関するDES鍵を演算したものを利用し、他のICカードのように1つのサービス毎に認証を行わないため、高速に処理が可能であるが、セキュリティ面では劣っている。
弱そうですね。
しかし、たとえ公開鍵で認証、DH で鍵交換して通信経路の暗号化 (これはやってるかもしれませんが) を行ったとして、カードに乗ってる小さいチップで CRL なんて取って来れないだろうから、あんまり意味ないような? CRL の反映が定期的でいいとしても、どうするんだろ? どこかで鍵が漏れたら全回収で書き換え? それじゃあ、今と変わらないし。 それに、消費電力・計算量ともに激増するかと。
いや待てよ。(対称) 共通鍵暗号方式ということで早合点している人も多いような気がするけど、Kerberos みたいにちゃんと作れば authentication, nonrepudiation は実現できる。ただ、
最大のアキレス腱は「フェリカ」の共通鍵暗号方式にある。この方式を簡単に説明すれば「一つの鍵をシステム全体で共有する仕組み」。ケータイクレジットは、鍵情報をすべての加盟店決済端末に格納して共有する。全端末をあけるマスターキーが一つだけあって、それでカード情報が読めると思えばいい。
が、鍵が1つで全端末、全カードで共有されてるということを示しているとすれば、おそまつな security しか無いんでしょうね。
結局、「電波受信された時点で負け。」ということになるんじゃないでしょうか。
Greasemonkey で JSON をごにょごにょに踏み切れない理由
DNS ポイゾニングとか何らかの方法で JSON だと思っていたデータが
GM_xmlhttpRequest({ method: "POST", url: "", data: document.cookie });
に置き換えられてしまったら…。
考えすぎですか。そうですよねぇ。
var dom = new XML(xml);
みたいに、
var obj = new JSON(json);
が使える将来は来ますか?
Windows XP home でフォルダ・ファイルのオプションにセキュリティータブを表示させるソフト
rt-sw.de
これを応用して…。(リンク先注意)
訪問済みリンク情報?が漏洩する件
JavaScript で抜き取るものは Not Found でいいとして、
こんなソリューション。
Not Found
ついでにNot Found