続・邪悪なブックマークレット考(考えてるだけ)
- ryunosinfx
- 561
- 1
- 0
- 0
例えば今話題の画像共有に欧米のファイルシェアリングサービスを使うと暗号化せずにファイルをおいた場合、プラットフォーマーのポルノチェッカーがチェックして勝手に削除、もしくは垢バンという状況がある。この場合、チェッカーが実力行使をしているので、もしこれを逆手に取れば追跡を撒くことが可
2019-08-07 12:23:31ひと手間、暗号化をしたらOKなんだけど暗号化しなかったら共有スペースでの配布はできない。透かしで情報が乗っている場合、改変すると情報が失われる。秘匿している限り問題はないのだが、告発をしようとして公知情報にしたいという行動を抑止できる。まあ法の執行機関には無力なのだが。
2019-08-07 12:36:51これらをスマホで完結にしたい アプリは嫌だからブラウザで と言うのが当面の目標か。 とはいえ、webrtcのシグナリング鯖作成が先だなー。
2019-08-16 12:54:43どうせやるからには、流行りの巨人たちのグレードまで辿り着きたいという欲求はある。
2019-08-16 12:57:34今日は衝撃の事実を知ってしまったのだ・・・ ・imgのsrcにSVGのURLを指定は出来る ・しかしFirefoxでは上記作業は許可されていない? ・もしくは、imgからcanvasにsvgのデータを移すことが出来ない →SVGでデータを扱う件は破綻した! Firefoxで出来ないなら価値がない!わぁぁぁぁぁぁん
2019-08-20 22:39:30そこで、考えたのである。 textでデータを返信せねばならない。しかし、textといいつつ中身はバイナリでも良いのではないかと。 そう、BMPファイルフォーマットでBASE64+BMPファイルヘッダ+パッディングを送りつければ、サーバーはテキストを送っているつもりがクライアントはバイナリファイルという
2019-08-20 23:25:11良い知らせと悪い知らせが有る! ・悪い知らせ:imgタグでクロスドメインしたら今は普通に怒られるのね。canvasで読み込んだ瞬間にCORSではないError! ・良い知らせ:Google app scriptは普通にCORSの*許可で対応していた。 言いたいことは分かるかい? 画像にする意味が無くなった!にゃーん!
2019-08-21 20:22:23もう一回、おさらいだ。 ・SDP等WebRTCの情報と端末識別情報を用意 ・これを共通鍵暗号AES-GCMとかで暗号化 ・キーは合言葉 ・BASE64url化、SHA256でシグネチャ記録 ・ファイル一覧情報とJSON文字列を構成 ・Uint8ArrayにしてZip圧縮、Base64URL化 ・ファイル名とハッシュとZipを鯖に登録
2019-08-23 02:06:07間違えた、 ・暗号化前のデータのハッシュを取るのだ。 でないと、復号した時に正しいか確認が出来ない。
2019-08-23 02:10:55受信側は ・最初の1個をもらう ・ファイル名から自分の欲しいモノを再度GET ・ハッシュ値から作られるファイル名は正しいハッシュ化前の情報を知っている正当なクライアントだけが知っている。 ・パスフレーズを使って復号 ・ハッシュ値を見て復号情報が正しいか確認
2019-08-23 02:13:24もし、この間に誰かが入り込もうとした場合 ・パスフレーズを知っているか ・ファイル名の元を知っているか になる。 数が十分少ない場合はファイル名は割れる。 しかし、グループ名で掲示板が切り替わる想定なので、 グループ名がわからないと入れない。 でも、混入の可能性は排除できない。
2019-08-23 02:16:01本来は公開鍵暗号でやりたいのだが 事前に公開鍵を交換するフェイズがない。 仮にSDPにくっつけても良いのだが・・・ Offer時に自分の公開鍵を入れて、 Answer時にそれで暗号化してもらうと それでは誰でもなりすましが可能である。
2019-08-23 02:20:28TLSよろしく、事前のハンドシェイクフェーズを設けてをしたいわけだけど、する意味有るの?な問題は有る。 誰とハンドシェイクしたいかは、ハッシュ化されたグループ名とファイル名に含まれるデバイス名で識別は可能だが、誰でも作れるなら成りすましはできる。 うーん。
2019-08-23 13:43:12やっぱり、パスフレーズをストレッチングとソルト(※固定)でこねくり回して、n回目で2個、n+x回目で3個に分けてn回目の2個めをパスフレーズに、n+x回目の2個めをピンコード的な扱いにするしか無いかなー。xは1回目sha256のの128bit目から10bitの数字とするとか。 この時、成りすましはどうしたら?
2019-08-23 14:47:212つのマシンはローカルネットワーク内でWebRTCな通信がしたいだけなのでPINコード入れろやゴルァ ってやっても良い。 パスフレーズと違っていいし、できればWeb Authnでも良いのかなと。どうするかできるかは理解が出来てないけど。
2019-08-23 14:56:15こねくり回す説は まあシュッと改竄データを用意が出来ない。 ソースをコピペなり見ることを強要する程度の効果はあるな。スクリプトキディに対する防壁程度の意味合いか。 まあこれで攻撃難易度が桁二個ぐらい上がればいいのか? コーナンペイの残念顧客固定バーコードに近しい感はするが。
2019-08-23 15:15:12ユーザの認知しているパスフレーズと実際に使われているものは違うというのは意味が有るのかな。 理想ではあらゆるドメインからのリクエストに対して、このアクセスはこの人ですよが証明される機構、それもシームレスに!と思ったがそれって今話題のリクルートでもやっていたという広告ストーキングで
2019-08-23 15:21:44やはり、私のポリシー違反になるので却下と言うところか。己の意志で、パスフレーズをコピペして欲しい。 同一ネットワーク内、デバイス間連携をしたいので、1コネクション、1パスフレーズにはなるのか。 なので、鯖に相当するやつには同じパスフレーズを入れれば良い。まあ使いまわしたところで
2019-08-23 15:24:54デバイス名をsaltとして鋤き込んでやるので実際に暗号化される際には別物になる。鋤き込まれるのはオファー側というルールにしておけば問題は無さげ。 でコネクション確立後に、マジ通信する?ってユーザに聞いておけばいいか。 その際、デバイス名とユーザ名が表示されると。あとpinコードか。
2019-08-23 15:27:21PINコードをアンサーした方に出して、 WebRTCの確立したいなら、これをコピペしてオファー側に入れろと。入れたらOKとみなすと。 以後チャンネルを通じて自動化。 二回目からは上記の確認は無しとすると。 これでいいか。
2019-08-23 15:29:31成りすましはできる。できるがユーザーが二回ミスをしないと通信は確立されません的な。 まあこの時、公開鍵の交換もしておくべきかな。 二回目の接続に備えて。 ということは二回目以降は、暗号化エリア内に公開鍵暗号の署名が入るからかなり偽装はしにくくなるはず。
2019-08-23 15:32:31WebRTCって、NAT超え出来たなら、なんかパケット見て通信制御食らったりするの? 単にポートが空いてないとかそういうう問題じゃないの?
2019-08-24 22:20:17あとは ローカルマシン間のブラウザでファイル交換をできた方がいい。 そりゃsshとかで接続できるけどめんどくさい。 ブックマークからシュッと同期したい。 そうしたら作業用マシンと印刷用データをUSBメモリに出すマシンの接続を考慮しなくて良くなる。 やっぱり作らないといけないようだ。
2019-08-25 13:35:48ネーム作るツールも作らないとね。 写植とコマのライン引きまで終わっていればいい。 こうスマホでみて満足できるフォーマットが求められているんだろうな。
2019-08-25 17:48:39